Disk space monitoring is an important system administration task because disk space shortage can impact system stability and application functionality.

I wrote a PowerShell script that allows you to query the disk space details of any drive connected to a remote Windows computer. Moreover, the script can get the disk space details of multiple computers in a single shot. You can also use it with other cmdlets, such as Get-QADComputer and Get-ADComputer, and pass the output of these commands to the script.

Using the parameters ValueFromPipelineByPropertyName and ValueFromPipeline, the script reads the inputs from the pipeline (output of the previous command). You can learn more details about these parameters by executing the command below in a PowerShell console.

Get-help about_functions_advanced_parameters

The -ComputerName parameter accepts a single computer name or a list of computers. The script then verifies the reachability of each computer before executing a WMI query. If the computer is not reachable, it proceeds to the next computer account.

I used the Win32_Volume WMI class to fetch the disk space details. A computer can have different drive types, such as local disks, removable disks, CD drives, or network drives. I am only interested in knowing the disk space details of local disks and removable disks, so I am tuning the command to return only the drive types 2 and 3. The PowerShell code below shows the WMI query and filtering I used in the script.

Get-WmiObject -ComputerName $Computer -Class Win32_Volume | ? {$_.DriveType -eq 2 
  -or $_.DriveType -eq 3 }

Once I get the list of drives, I go through each volume and read the total capacity and free space attributes. These attributes provide the disk information in bytes. I then divide the value by 1GB (PowerShell supports this) to convert the bytes to GBs. The Round method in the System.Math class adjusts the value to two decimals. Based on these two values, I then calculate the total percentage free space.

$Capacity = [System.Math]::Round(($Volume.Capacity/1GB),2)

$FreeSpace = [System.Math]::Round(($Volume.FreeSpace/1GB),2)

$PctFreeSpace = [System.Math]::Round(($Volume.FreeSpace/$Volume.Capacity)
 *100,2)

The next step is to format the output in a way that it can be passed to other scripts as input and can be used in filters to get the data we need. For this purpose, I am using PSObject to output the values.

$OutputObj = New-Object -TypeName PSobject

$OutputObj | Add-Member -MemberType NoteProperty -Name ComputerName 
 -Value $Computer

$OutputObj | Add-Member -MemberType NoteProperty -Name DriveName 
 -Value $Volume.Caption

$OutputObj | Add-Member -MemberType NoteProperty -Name DriveType 
 -Value $Volume.DriveType

$OutputObj | Add-Member -MemberType NoteProperty -Name "Capacity `(GB`)" 
 -Value $Capacity

$OutputObj | Add-Member -MemberType NoteProperty -Name "FreeSpace `(GB`)" 
 -Value $FreeSpace

$OutputObj | Add-Member -MemberType NoteProperty -Name "`%FreeSpace `(GB`)" 
 -Value $PctFreeSpace

$OutputObj# | Select ComputerName, DriveName, DriveType, Capacity, FreeSpace, 
 PctFreespace | ft -auto

A few tips for using the script:

• Use “Get-Help .\Get-DiskSpaceDetails.ps1” if you want to display usage information.
• Use “Get-Content c:\comps.txt | .\Get-DiskSpaceDetails.ps1” to get the disk space details of computers listed in comps.txt.
• Use the “-Verbose” switch if the output is not displayed for a computer.
• Use “Get-DiskSpaceDetails.ps1 -ComputerName Comp1, Comp2, Comp3” if you want to pass the computer names as parameters.
• Execute the script without any parameters (.\Get-DiskSpaceDetails.ps1) to return the disk space details of the local computer.
• Use “Get-DiskspaceDetails.ps1 -ComputerName Comp1 | ? {$_.”`%FreeSpace `(GB`)” -lt 5}” if you want to get a list of drives that have less than 5% free space.

You can download the script here. Feel free to adjust it to your liking.

• Raffle: SolarWinds DameWare NT Utilities – Remote administration tools (3)
• Windows-to-Mac remote management with VNC and SSH (1)
• FREE: PAExec – Run programs on remote Windows servers (0)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)

I still remember the days (way back in 2003-2004) when we were asked to change the local administrator password manually on all 2000+ computers in a weekend. Back then, system administrators in my region were pretty far removed from automation. But things evolved greatly after that, and system administrators started using programming languages (like VBScript) to automate tasks. Automation tasks have become much easier these days with the introduction of PowerShell.

So, let us see how we can change the local administrator password for a given list of computers using a PowerShell script.

Changing the administrator password with PowerShell

$password = Read-Host "Enter the password" -AsSecureString
$confirmpassword = Read-Host "Confirm the password" -AsSecureString
$pwd1_text = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($password))
$pwd2_text = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($confirmpassword))
if($pwd1_text -ne $pwd2_text) {
    Write-Error "Entered passwords are not same. Script is exiting"
    exit
}

As you will notice in the above code, I am prompting to confirm the password twice so that it won’t be entered wrong and cause the script to run again. I am also reading the password in a secure manner so that no one else can see it when it is being typed. Once the password is confirmed, the next two lines of dotnet code convert the password into plain text for comparison. If the comparison fails, the script exits; otherwise, it continues.

Now that we have the password, it is time to read the list of computers from a text file.

Reading list of computers

if(!(Test-Path $InputFile)) {
    Write-Error "File ($InputFile) not found. Script is exiting"
    exit
}

$Computers = Get-Content -Path $InputFile

Before reading the text file, I am doing a small check to see if that file exists or not. If the file is not found, the script exits. Otherwise, the script reads the contents of the file using the Get-Content cmdlet and stores the list in an array called $computers.

Now that we have the list of computers, we can start changing the password for each computer. That is what the below code does.

Chaging the password on multiple computers

foreach ($Computer in $Computers) {
    $Computer    =    $Computer.toupper()
    $Isonline    =    "OFFLINE"
    $Status        =    "SUCCESS"
    Write-Verbose "Working on $Computer"
    if((Test-Connection -ComputerName $Computer -count 1 -ErrorAction 0)) {
        $Isonline = "ONLINE"
        Write-Verbose "`t$Computer is Online"
    } else { Write-Verbose "`t$Computer is OFFLINE" }

    $obj | Select ComputerName, IsOnline, PasswordChangeStatus
   
    if($Status -eq "FAILED" -or $Isonline -eq "OFFLINE") {
        $stream.writeline("$Computer `t $isonline `t $status")
    }
           
}

I am looping through each computer account in the array and first checking if it is online or not by using the Test-Connection cmdlet. This cmdlet does a ping check by sending one ICMP packet to the computer. If the ping is successful, the script changes the password. To do that, I am using the WinNT interface, which is pretty famous from VBScript days. After I get the reference to the administrator account, I invoke a method called SetPassword to change the password. If the password change fails, the respective error will be recorded using the catch block.

That’s it. The script has done its job and you will see the result in the console.

As you’ll notice in the output, the script creates a list of computers where the password has failed. The file "failed-computers.txt" is stored in the directory where the script picked up the computers list. If you want to provide a different directory where you want to store files, just pass the directory name to the -OutputDirectory parameter while executing the script.

Download the complete script from here.

A few tips for using this script

Type “Get-Help .\Update-LocalAdministratorPassword.ps1 -Detailed” in a PowerShell console for help.

• Use the -Verbose switch from the command line if you want to see the debug information and error messages at each stage.
• Passing the file name to the script is optional. The script will prompt you for the file if you don’t pass it.
• Using this script, you can change the password of any local account. Just replace “administrator” with the account name for which you want to change the password.

• Query free disk space details of remote computers using PowerShell (3)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)
• PowerShell tutorial for admins – Part 5: Using PowerShell Scriptomatic (0)

Querying processes running on local and remote computers is one of the most common jobs of system administrators. We sometimes need to know which user is running some XYZ application. If you know the process name of the application, then you can quickly scan all your network computers to see how many hosts are running that particular process, and for how long, so that you can prepare an application usage report.

Query process information

Let’s first see how we can check if a process is running or not. For example, the following command checks if Notepad is running and, if so, displays information about the process:

Get-Process -Name notepad.exe

You will get information about the process, if it is running. You can use the -ComputerName parameter with the command to check if the process is running on a given remote computer. For example:

Get-Process -ComputerName PC1 -Name notepad.exe

You can get similar information with other scripting languages like VBScript and Perl. So what is so special about PowerShell? The answer is that it helps you to get granular information about processes you are querying, such as process creation time, the owner of a given process (with which account it is started), command line information about the process, the title of the application, and much more.

Below are a few example code snippets.

Process creation time

Get-ProcessCreationTime.ps1 [cmdletbinding()]
param(
$ComputerName=$env:COMPUTERNAME,
[parameter(Mandatory=$true)]
$ProcessName
)
$Processes = Get-WmiObject -Class Win32_Process -ComputerName $ComputerName -Filter "name='$ProcessName'"
if($Processes) {
foreach ($process in $processes) {
$processid = $process.handle
$processcreationtime = $Process.Converttodatetime($Process.creationdate)
write-host "`nThe $ProcessName `($processid`) process creation time is $processcreationtime"
}
} else {
write-host "`nNo Process found with name $ProcessName"
}
write-host ""

The above script takes computer name and process name as arguments. The computer name is optional and defaults to the local computer if not provided. The process name is mandatory, and the script will throw an error if you don’t provide it. After reading the arguments, a WMI query gets the list of processes using the names in the argument and iterates through each process to get its creation date.

Process creation time

Process owner

Get-ProcessOwner.ps1 [cmdletbinding()]
param(
$ComputerName=$env:COMPUTERNAME,
[parameter(Mandatory=$true)]
$ProcessName
)
$Processes = Get-WmiObject -Class Win32_Process -ComputerName $ComputerName -Filter "name='$ProcessName'"
if($Processes) {
foreach ($process in $processes) {
$UserName = $process.getowner().user
$DomainName = $process.getowner().domain
$processid = $process.handle
write-host "`nThe owner of $ProcessName `($processid`) process is $domainname`\$username"
}
} else {
write-host "`nNo Process found with the name"
}
write-host "" This script executes in the same way as the Process creation time script.

Process owner

Process path

Get-Processpath.ps1

[cmdletbinding()]
param(
$ComputerName=$env:COMPUTERNAME,
[parameter(Mandatory=$true)]
$ProcessName
)
$Processes = Get-WmiObject -Class Win32_Process -ComputerName $ComputerName -Filter "name='$ProcessName'"
if($Processes) {
foreach ($process in $processes) {
$Executablepath = $process.ExecutablePath
$Commandline = $process.Commandline
$processid = $process.handle
Write-Host ""
Write-Host "Process Name = $ProcessName"
Write-Host "Process ID = $Processid"
Write-Host "Executable Path = $Executablepath"
Write-Host "Command Line = $Commandline"
Write-Host ""
}
} else {
write-host "`nNo Process found with the name $ProcessName"
}

This Powershell script displays the process path.

Process path

Though PowerShell has a built-in cmdlet (Get-Process) to retrieve process information, in all of the above examples I have used a WMI query to get process information from the Win32_Process class. The reason I did so is because Get-Process will not provide the owner, process path, and other values.

Kill a process

To terminate a process using PowerShell, you can either use the WMI interface or use the Stop-Process cmdlet, which comes by default with PowerShell.

Kill-ProcessusingWMI.ps1

[cmdletbinding()]
param(
$ComputerName=$env:COMPUTERNAME,
[parameter(Mandatory=$true)]
$ProcessName
)
$Processes = Get-WmiObject -Class Win32_Process -ComputerName $ComputerName -Filter "name='$ProcessName'"
if($processes) {
foreach ($process in $processes) {
$returnval = $process.terminate()
$processid = $process.handle
if($returnval.returnvalue -eq 0) {
write-host "`nThe process $ProcessName `($processid`) terminated successfully"
}
else {
write-host "`nThe process $ProcessName `($processid`) termination has some problems"
}
}
} else {
Write-host "`n No processes found with the name $ProcessName"
}
write-host ""

Kill a process

This script first queries the computer for a list of running processes and then terminates them using the terminate () method. This method will return a value of 0 if the termination is successful. Any non-zero value indicates some issues.

The second method terminates a process using the Stop-Process cmdlet. Below are some usage examples:

Get-Process -Name notepad | stop-Process

Stop-Process -Name notepad

Conclusion

Querying process information using PowerShell is pretty easy. You can use PowerShell for a variety of purposes, such as reporting application usage, querying the age or the start time of a process, or maximizing, minimizing, or restoring an application window.

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)
• PowerShell tutorial for admins – Part 5: Using PowerShell Scriptomatic (0)

VBScript is definitely fading, and PowerShell is rightfully gaining traction, but PowerShell’s learning curve and backwards compatibility issues will keep VBScript around a bit longer.

VBScript was once unquestionably the preferred scripting language of most systems administrators, offering them the ability to automate routine tasks and interact with Windows features like IIS, Active Directory, and Terminal Services. Using the Windows Scripting Host, VBScript performed tasks that the Windows shell (batch scripts) simply could not handle. Then, in 2006, Microsoft released an alternative to VBScript – and an extension to the basic shell – known as Windows PowerShell. Since then, VBScript has remained the same while PowerShell 2 has been released.

Of course it’s always nice to have more options. At the same time, the existence of two viable scripting languages poses some new questions for the budding admin. As we compare them head to head, let’s look a bit further into the benefits and drawbacks of each.

Functionality

Both VBScript and PowerShell offer similar feature sets. The difference between them is more about how they actually acheive those features, and in most cases, PowerShell takes the cake. VBScript utilizes COM components to access features while PowerShell is built on top of .NET, meaning that it utilizes the base classes and is capable of interacting with some applications (especially Microsoft ones) that cannot be manipulated via VBScript. In fact, the folks who developed Exchange 2007 actually built the entire management console using one-line PowerShell commands (called cmdlets) that do the dirty work for you behind the scenes. Because VBScript is now deprecated and does not respect .NET functionality, it is usually difficult or impossible to manage a .NET application like Exchange via VBScript.

Performance

Intuitively, one might think that PowerShell should blow VBScript out of the water in terms of performance given the fact that PowerShell is “integrated” with the kernel and VBScript relies on a COM interpreter. In reality, however, PowerShell and VBScript are roughly the same in terms of efficiency. We can speculate about why this would be the case – perhaps the added overhead of .NET roughly offsets the inefficiency of using COM components – but the bottom line here is that performance should not be a consideration when choosing between VBScript and PowerShell.

Compatibility/Deployment Readiness

The Windows Scripting Host dates back to Windows 98, so VBScript can be deployed to all of your Windows clients “out of the box.” On the other hand, PowerShell was released in 2006 and requires at least Windows XP. More importantly, it is not included in Windows distributions predating Windows Server 2008 and Windows 7, so you will need to deploy and install PowerShell on all of your XP, Vista, and Server 2003 hosts before you can get up and running with it. Perhaps you will want to use a VBScript to automate this process!

In many cases, PowerShell simply cannot perform all of its functions on pre-Windows Server 2008/Windows 7 systems. For example, the Active Directory module – an important one for most systems admins – requires Windows 7 and/or Windows Server 2008 R2. This can be a real deal-breaker if your architecture utilizes Windows Server 2003 or XP clients.

Learning Curve/Existing Scripts

For starters, we should be clear about one thing: VBScript is a scripting language. While PowerShell can be used for scripting, it is primarily meant to be a shell. So, if you are already familiar with a scripting language or Visual Basic, you might find VBScript quite easy to learn. If you are not a developer and have never used a scripting language before, you might find VBScript a bit harder to learn, but there are still resources and existing script libraries out there to help you get started on your first scripts.

Unless you are already familiar with the .NET base components, you will probably find PowerShell much more difficult to learn. This is not to say that PowerShell is not accessible – it’s just built on top of a larger framework and thus has a moderate learning curve attached.

Security

The Windows Scripting Host has gotten a bad rap over the years for being what Wikipedia terms a “vulnerability vector.” In years past VBScript could be executed through Internet Explorer and bad actors of all varieties would use VBScript to execute code at a high level of system privileges. PowerShell can use digital signatures (code signing) to prevent execution of malware, something that VBScript does not offer.

Brevity

PowerShell is, in most cases, simply shorter (but often less intelligible) than VBScript. Consider the simple task of renaming all files beginning with “CurrentLog” in their filename to “ArchiveLog:”

First, we have VBScript. We create filesystem objects to access, run a loop to catch the instances of what we are looking for, then use a function to split the filename string up and replace:

VBScript vs. PowerShell – VBScript example

Now, consider this PowerShell cmdlet. Assuming we have already navigated in the shell to the desired folder, we use this slick one-liner to rename the files:

VBScript vs. PowerShell – PowerShell example

As you can see, the VBScript example is perhaps more telegraphic, but there’s no debate as to which is shorter (and more elegant).

The Verdict

It’s somewhat telling that although VBScript has been in so-called “maintenance mode”- the final step before deprecation – systems administrators continue to use it today. Perhaps there is a laziness factor. I know that I have scripts in VBScript that I do not want to have to port to PowerShell. PowerShell, despite requiring far fewer lines of code, is far from intuitive. Plus, certain features in PowerShell require Windows 7 or Windows Server 2008 to even work at all.

The smart money is that PowerShell will be the Microsoft-platform automation language once Windows 7 and Server 2008 gain widespread use, and most would say that PowerShell has already become the scripting (and shell) language of choice in the Microsoft world. But, if PowerShell cannot play nicely with your existing architecture and needs, VBScript is still the way to go.

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)
• PowerShell tutorial for admins – Part 5: Using PowerShell Scriptomatic (0)

This is the sixth part of the Windows PowerShell series. PowerShell beginners should also read the previous parts.

In Windows Server 2008 a server role represents an installable unit of functionality that defines the primary function of a server. For instance, you may install Active Directory Domain Services (AD DS) to create a dedicated domain controller for your forest.

By contrast, Windows Server 2008 features are a bit more slippery to define. Like a server role, a feature is an installable unit of functionality. However, whereas a server role typically defines the chief duty of a server, a feature (at least according to Microsoft marketing literature) “provides auxiliary or supporting functions” within a system. Thus, a single server may be the holder of several features.

As you probably already know, you can manage server roles and features by using any of the following tools:

• ServerManagerCmd.exe
• Server Manager console
• Windows PowerShell

You also may know that, as of Windows Server 2008 R2, the ServerManagerCmd.exe command-line tool is formally deprecated (read: does not work anymore); you are instead politely “encouraged” to use Windows PowerShell instead. In this article we will learn how to leverage the Windows PowerShell scripting and automation environment to install, administer, and remove server roles and features.

Installing Windows PowerShell 2.0

The first order of business is ensuring that your target Windows Server 2008 computers have Windows PowerShell 2.0 installed. If you are running Windows Server 2008 RTM, then you can use the ServerManagerCmd.exe utility to install Windows PowerShell:

OS>ServerManagerCmd –install PowerShell

If you run Windows Server 2008 R2, then you already have Windows PowerShell 2.0 installed. To verify your installed Windows PowerShell version, open an elevated command prompt, issue the command powershell to start a Windows PowerShell session, and then invoke the $Host.Version method. All of these commands are depicted in the following exhibit:

Verifying Windows PowerShell

NOTE: There is a world of difference between Windows PowerShell v1.0 and v2.0. Please ensure that you are running PowerShell v2.0, and be certain to run Windows Update to download the latest enhancements to the technology.

Installing a Role or Feature

As far as I am personally concerned, it is a blessing that Windows PowerShell does not try to split hairs and differentiate server roles and features. As you will see momentarily, all roles and features appear in a single master list.

From an administrative command prompt, fire up Windows PowerShell and issue the cmdlet Import-Module Servermanager to load the Server Manager PowerShell module.

Next, run the cmdlet Get-WindowsFeature to see a tree list of all available server roles and features. Any roles or features that are currently installed will appear with an X within the selection brackets. Pay particular attention to the role and feature short names in the Name column, as shown in the below screenshot; we will need those IDs to perform the next step.

Listing available server roles and features

NOTE: In Windows PowerShell nomenclature, a module is a self-contained, reusable library of related PowerShell functionality. Most Microsoft server technologies, such as SQL Server 2008, SharePoint Server 2010, and Exchange Server 2010, ship with their own custom modules to enable administrators to use PowerShell with those products.

We use the Add-WindowsFeature cmdlet to install both server roles and features. To leverage this cmdlet, we simply pass a comma-separated list of either display names (in quotes) or short names for the roles and/or features you wish to install.

PS>Add-WindowsFeature role, feature, etc.

See the following exhibit for an interface example in which we install the File Server, Domain Name System (DNS), and Dynamic Host Configuration Protocol (DHCP) server roles on a Windows Server 2008 R2 server.

Installing roles and features

To verify that the new server roles have been installed successfully, let’s fire up Server Manager and have a look at the Roles tree:

Verifying server role installation

Ah, success!

Removing a Role or Feature

Removing Windows Server 2008 roles and features by using PowerShell is an equally simple procedure. To do this, we invoke the Remove-WindowsFeature cmdlet. You can throw in the optional –restart parameter to specify an automatic server restart if Windows needs to do so.

Removing server roles

One word of warning: If you do elect to add the –restart parameter to your cmdlet, the server will restart (if necessary) with absolutely no timeout or other warning. It just goes!

Conclusion

At this point you should be able to manage Windows Server 2008 roles and features by using PowerShell. I will leave you with some related study resources if you are so inclined. I hope that you found this article helpful. Thanks!

For Further Study:

• Adding Server Roles and Features
• Checking Server Roles with PowerShell
• Windows Server 2008 Server Management
• Windows PowerShell

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 5: Using PowerShell Scriptomatic (0)

This is the fifth installment of a multi-part series on Windows PowerShell for Windows systems administrators. To become current with our subject matter, I encourage you to read the four previous articles of this PowerShell tutorial.

As we discussed in a previous entry in this series, learning the syntax of the WMI Query Language (WQL) is tough enough without having the understand the WMI-related PowerShell cmdlets as well. In this essay I will introduce you to the nifty Microsoft PowerShell Scriptomatic utility. By the conclusion of this piece you will be integrating WMI and PowerShell with the best of ‘em!

Let’s get right to work.

Preliminary Terminology

As usual, we need to define our terms. By way of review, recall that Windows Management Instrumentation (WMI) is Microsoft’s implementation of Web-Based Enterprise Management (WBEM), which in turn uses the Common Information Model (CIM) standard to define access methods for computers, networks, applications, and so forth. Think of WMI and WBEM as the next generation of the Simple Network Management Protocol (SNMP).

In WMI, managed system information, including hardware and software-related data, is reported by using schemas. We employ the CIM schemas to access WMI classes, which in turn represent the specific data elements that we wish to query.

A WMI namespace is a subsection of the CIM repository. The most commonly used WMI namespace (and the one we will reference in this tutorial) is named root\CIMV2. The root\CIMV2 namespace ncludes an enormous number of Windows-related classes; lots of rich information in there!

Please see the following sources for a complete list of WMI namespaces and classes:

• MSDN: WMI Reference
• MSDN: WMI Classes

If you prefer the long way (that is, the manual way) around WMI systems administration, you can leverage the PowerShell Get-WMIObject cmdlet as well as your existing knowledge of WQL syntax to do your work. For instance, issue the following statement from a PowerShell prompt to return a list of all available WMI namespaces on the local system:

PS>Get-WMIObject –namespace “root” –query “SELECT * FROM __Namespace” | Select Name

Listing WMI namespaces from PowerShell

However, if you would prefer a bit of automation in your life with respect to WMI and PowerShell, then look no further than the PowerShell Scriptomatic tool. Read on, friends!

Introducing PoweShell Scriptomatic

Scriptomatic v2 is a GUI utility developed by the Microsoft Scripting Guys and has as its goal the easier creation of WMI scripts for system administration.

Scriptomatic 2.0

As you may or may not be able to tell from Figure 2, the use of Scriptomatic involves the following workflow:

1. Select your desired WMI namespace and WMI class. The tool helpfully defaults to root\CIMV2.
2. Choose appropriate scripting language and output format. Supported languages are VBScript, Perl, Jscript, and Python, and supported outputs are command prompt, plain text, HTML, Excel, and XML.
3. Select the target computer(s) for the script
4. Use the toolbar buttons to execute the script immediately, save the script to disk, etc.

Scriptomatic is a pretty awesome utility, isn’t it? However, unless you (a) are already proficient in VBScript or Jscript; or (b) already have the Perl and/or Python interpreters installed on your system, this tool is of limited use. After all, we are budding PowerShell scripters, correct?

Fortunately for us, the Microsoft Scripting Guys authored a PowerShell edition of Scriptomatic. You can’t beat the price, either: both Scriptomatic tools are free for your downloading pleasure!

Scriptomatic PowerShell edition

Note that the workflow for the PowerShell edition of Scriptomatic is essentially identical to that of Scriptomatic V2:

1. Select your desired WMI namespace and class
2. Specify one or more target computers (comma-separated list; you can load this from an external file)
3. Use the Control Pad buttons to specify output options

Scriptomatic PowerShell output

Check out the output in Figure 4; these expressions should look familiar to you if you’ve been keeping up on the content in this series. In this example we have variables and an invocation of the Get-WMIObject PowerShell cmdlet.

Following is a brief summary of the functionality of the Control Pad buttons:

• Run: Executes the current code in a command prompt window
• Save: Enables you to save your work as a .PS1 script file
• Clear Script: Clears the work area
• Refresh Script: Updates the active script to reflect any changes
• Notepad: Opens your work in a new Notepad file
• Open Temp File: Opens a blank file in Notepad

Hey, one more trick for you: Click the third toolbar button (for some inexplicable reason the Microsoft Scripting Guys have not differentiated these button icons!) and click Display Class Properties. Next, from the Control Pad, click Refresh Script. You now can drill into the granular data elements (aka properties) within the selected class. This procedure is shown in Figure 5:

Accessing class properties in Scriptomatic

Conclusion

Alrighty then! By now I think that you have a flying head start at using both WMI and PowerShell in your Windows systems administration work. I hope that you found this article helpful.

In the next installment of this series we will examine how to manage Windows Server 2008 roles and features by using PowerShell. Take care, and thanks for reading.

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)

This is the fourth installment of a multi-part series on Windows PowerShell for Windows systems administrators. To get caught up on our subject matter, you might want to read the three previous article about cmdlets and pipeline, aliases and drives, and running scripts.

Now that we have a preliminary understanding of Windows PowerShell, it is time to turn our attention to practical application of the technology. To wit, in this blog post we will learn how to leverage PowerShell in order to ascertain metadata (that is to say, data about data) from a Windows Server 2008 computer. Of course, the same cmdlets apply for obtaining metadata from Windows client machines as well. Let’s get to work!

Preliminary Terminology

Before we begin, it is imperative that we have our terminology down pat. First, let’s define environment variables and WMI. According to Microsoft, an environment variable is “a string that contains information about the environment for the system, and the currently logged on user.”

In current Windows systems, the traditional ways to access environment variables are either through the System Control Panel item or the SET command-line program.

Accessing environment variables in Windows

Wikipedia defines Windows Management Instrumentation (WMI) as “a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification.”

In Windows Server 2008, we use WMI not only to discover computer metadata, but we can also create employ WMI for local and remote system administration. In addition, we can define WMI filters in Group Policy to target Group Policy Objects (GPOs) based upon hardware and software-specific criteria.

Accessing Environment Variables in PowerShell

To begin with, fire up an administrative command prompt and type powershell to enter the PowerShell v2 environment. Next, issue the following command to return a list of all defined environment variables for the system:

PS>dir Env:

NOTE: You might recall that dir represents an alias for the Get-ChildItem cmdlet, and that Env: represents a PowerShell drive. See the earlier installments of this series for more information.

To query the value of an existing environment variable, use the following syntax:

PS>$Env:<variable_name>

Here is a nice list of examples to get you started:

• $env:username (Displays the name of the currently logged-on user)
• $env:userdomain (Displays the logon domain for the current user)
• $env:computername (Displays the hostname of the local system)
• $env:os (Displays the operating system kernel name)
• $env:path (Displays the search path for executable files)

Some PowerShell cmdlets, specifically those that access and modify system information for local and remote systems, require authentication credentials.

We can define a PowerShell variable, for instance $cred1, and instantiate an instance of the Get-Credential cmdlet. That is:

PS>$cred = Get-Credential

Storing a credential in PowerShell

Do you see what’s going on here? The PowerShell script author is prompted for those credentials, which can then be used later on in an interactive session or PowerShell script file.

For greater flexibility, we can hard-code a credential:

PS>$cred2 = Get-Credential –credential corpdomain\admin

In this case, you are prompted for the password and PowerShell stores the password as an encrypted string, safe and secure. We can then call the password later in our PowerShell script or interactive session like so:

PS> $user2 = $cred2.username

$pw = $cred2.password

Now let’s link our understanding of stored credentials with the magic of WMI.

Obtaining System Information in PowerShell

If you have ever tried to use WMI before, you doubtless have found that the WMI Query Language (WQL) used to perform these actions is a bit obtuse. Okay, maybe more than a bit obtuse. Yes, WQL is a subset of the Structured Query Language (SQL) that we database administrators know and love, but the syntax is just so non-intuitive!

Regardless, let’s dive right in with some examples:

PS>Get-WMIObject –Class Win32_ComputerSystem

The above statement lists detailed information about one or more target computers. We can extend that statement big-time by adding additional computer names and attaching our previously defined credential:

PS>Get-WMIObject –Class Win32_ComputerSystem –ComputerName server01, server02, host144, host 255 –Credential $cred1

You can also use this same syntax, substituting only the specific WMI objects to be retrieved. To wit:

• Win32_OperatingSystem (Detailed OS metadata)
• Win32_UserAccount (Lists user accounts)
• Win32_Group (Lists groups)

Enumerating Windows groups with PowerShell

Conclusion

In a future installment of this series I will share with you some tools that will make your PowerShell WMI querying a much more painless process. In the meantime, please feel free to leave your questions, comments, and suggestions for new topics in the comments. Thanks for reading and take care!

For Further Study:

• Creating and Modifying Environment Variables
• About Environment Variables
• WMI Reference
• Exploring WMI with PowerShell V2

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)

This is the third installment of a multi-part series on Windows PowerShell for Windows systems administrators. To get caught up on our subject matter, you might want to read the two previous articles about cmdlets and the pipeline and about aliases and drives.

Now, then—on with the show. While issuing ad-hoc PowerShell cmdlets from a PowerShell prompt is all well and good for occasional or on-demand use, you don’t truly begin to leverage the strengths of Windows PowerShell until you aggregate your code (which can include variables, branching, looping, error handling, etc.) into script files.

In a future installment we will begin to drill into practical examples of administering Windows using PowerShell. In this essay I will teach you the basics of creating and running PowerShell scripts from an overview perspective.

What is a PowerShell script?

A Windows PowerShell script file is nothing more than a plain text file that (a) has the .ps1 file extension; and (b) contains one or more lines of PowerShell source code.

Plaintext script file

Like VBScript, Python, and most other so-called “scripting languages,” your code is not compiled at run-time but is rather interpreted, line-by-line, by the PowerShell interpreter.

Therefore, you will get exactly nowhere unless and until you have PowerShell 2.0 installed on your target system. When you download PowerShell 2.0 (wonkily called the Windows Management Framework by Microsoft), you not only receive the PowerShell runtime environment, but you also receive the PowerShell Integrated Scripting Environment (ISE).

The ISE is a graphical interface (specifically a host application) for Windows PowerShell, and in my opinion should be your de facto scripting environment.

NOTE: In PowerShell nomenclature, a host application is a management tool that includes the Windows PowerShell runtime within its framework. For instance, the Microsoft Exchange Administrator console is a PowerShell host application, as are all third-party PowerShell ISEs.

The following exhibit shows the unique, three-paned interface of the PowerShell ISE:

The Windows PowerShell ISE

The three viewing panes have the following purpose:

• Script Pane: Enables you to edit your PowerShell scripts
• Output Pane: Displays the output from your scripts
• Command Pane: Enables you to issue PowerShell statements interactively

While we’re at it, in the name of completeness why don’t we briefly explain the function of the primary toolbar buttons as well:

Figure 2: The PowerShell ISE toolbar

• 1: New
• 2: Open
• 3: Save
• 4: Cut
• 5: Copy
• 6: Paste
• 7: Clear Output Pane
• 8: Undo
• 9: Redo
• 10: Run Script
• 11: Run Selection
• 12: Stop Execution
• 13: New Remote PowerShell Tab
• 14: Start PowerShell.exe
• 15: Show Script Pane Top
• 16: Show Script Pane Right
• 17: Show Script Pane Maximized

Creating a PowerShell script

Authoring a Windows PowerShell script is as easy as typing or pasting your code into the ISE script pane and then pressing the Run Script toolbar button. Be sure to save your file with the .ps1 extension; the PowerShell ISE takes care of that pesky little detail for you.

If you are a beginner to PowerShell scripting, then you will want to (1) purchase a great textbook or computer-based training course on the subject; and (2) make use of the wonderful Microsoft TechNet Script Repository.

In point of fact, the simple PowerShell script we use as an example in this article was borrowed from the TechNet Script Repository.

Running a PowerShell script

Before we learn how to run a PowerShell script from outside the ISE, we need to explain PowerShell execution policy, formally defined as Code Access Security.

By default, Windows PowerShell runs in the Restricted execution policy, which means that Windows PowerShell can be used only in interactive mode from a PowerShell prompt or from an ISE. This prohibition of PowerShell scripts from running “free” on a host system was done by design and obviously for security purposes.

The other three PowerShell execution policies are:

• AllSigned: Only scripts that are digitally signed by a trusted publisher are allowed to run
• RemoteSigned: Locally created scripts can run fine; downloaded scripts must be digitally signed by a trusted publisher in order to run
• Unrestricted: All PowerShell scripts can run without restriction (not recommended for most environments)

To change the PowerShell script execution policy on a system, open an elevated command prompt, start PowerShell by typing powershell, and then invoke the Set-ExecutionPolicy cmdlet. To verify the current execution policy, run Get-ExecutionPolicy.

The following exhibit demonstrates how to both verify the current execution policy, as well as how to change the default execution policy to something a bit more reasonable in a development environment—RemoteSigned.

Setting Windows PowerShell execution policy

Now for the good stuff. To run a PowerShell script from an elevated command prompt, perform one of the following actions:

• .\<script>.ps1 (You can use this form if your OS prompt is already focused in the local directory that contains the target PowerShell script file)
• C:\Scripts\<script.ps1> (Here we specify the fully qualified filename of the target PowerShell script)

As long as Windows is properly configured to associate the .ps1 extension with Windows PowerShell, the inclusion of the file extension in your scripts is optional.

If, by contrast, you are already within PowerShell, you can employ the Invoke-Expression cmdlet to run the script. To wit:

PS> Invoke-Expression “C:\Scripts\<script>.ps1”

NOTE: The use of quotation marks is required only if your directory path includes spaces. Be aware, also, that by default you must always fully qualify the location of the script file even if your present working directory is the same location as the target script.

Finally, you can use the ampersand (&) shortcut to run a script from within PowerShell. That is to say:

PS>& “C:\Scripts\<script>.ps1”

Conclusion

At this point you know a thing or two about creating and running Windows PowerShell scripts. I will leave you with some helpful links to foster further learning. If there are other PowerShell-related topics on which you would like to see coverage here at 4Sysops, then please feel free to leave those requests in the comments portion of this post.

For Further Study:

• Running Scripts
• Best IDE for PowerShell?
• Introducing the Windows PowerShell ISE
• Windows PowerShell Owner’s Manual
• Windows PowerShell 2.0 Administrator’s Pocket Consultant

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)

In the first part of this miniseries on Windows PowerShell terminology for administrators we briefly described what PowerShell is an introduced you to the cmdlet and the pipeline.

Let’s now continue our journey by learning two additional core terms that every PowerShell scripter should know.

Aliases

One of the things that I really love about Windows PowerShell is how much thought the Microsoft developers put into making the environment as user-friendly for existing Windows (and even *NIX) scripters as possible. To me, aliases represent the best example of this universality aspect of Windows PowerShell.

For instance, recall how earlier in this article I told you that the Get-ChildItem cmdlet is analogous in functionality to the Windows dir command? Well, as it happens, you can use dir all day long to retrieve directory listings in PowerShell. Are you a Mac or a NIX scripter? No problem—try using ls. It works!

In PowerShell, an alias is nothing more than a persistent mapping of a system- or user-defined shortcut to a known PowerShell cmdlet.

To obtain a full list of built-in aliases, simply invoke the cmdlet Get-Alias from your PowerShell environment.

Listing PowerShell aliases

Notice in the above exhibit that when you type cls to clear the screen, PowerShell actually invokes the Clear-Host cmdlet. You can define your own aliases as well by using the Set-Alias cmdlet. The kernel idea here is that over time you can develop a completely tricked-out, personalized scripting environment that is tuned to your intuitive workflow and command preferences.

Drives

As I previously mentioned, Windows PowerShell is built atop the .NET Framework. With PowerShell you can reach literally any aspect of local and/or remote computers, including the file system, the Registry, Windows Management Instrumentation (WMI) values, and the Active Directory Services Interface (ADSI).

According to Microsoft, a Windows PowerShell drive is a logical data store location that maps a logical name within PowerShell to a “real, live” data provider. Those data store locations can be:

• Local or remote filesystems
• Digital certificates
• Environment variables
• Registry keys and/or values

You can invoke the PowerShell cmdlet Get-PSDrive to obtain a list of currently loaded PowerShell drives on the local system. If you want to create a new PowerShell drive, then use the New-PSDrive cmdlet. The following exhibit demonstrates how we can define a virtual drive that maps to a remote file share.

Figure 2: Defining a new PowerShell drive

In the preceding example, the alias remotedocs represents the \\srv1\documents remote file share. We can access the new PowerShell drive by using the command dir remotedocs.

Conclusion

At this point you should have a pretty good grasp of basic Windows PowerShell terminology. I will leave you with a laundry list of resources that I hope you will find helpful for further study in PowerShell. In the meantime, if there are other PowerShell-related topics that on which you would like to see coverage here at 4sysops, then please leave your request in the comments. Thanks! Next in this series you will learn how to run a PowerShell script.

For Further Study:

• Wikipedia article on Windows PowerShell
• Active Directory Administration with Windows PowerShell
• Scripting with Windows PowerShell
• The PowerShell Guy
• PowerShell Modules
• CBT Nuggets Windows PowerShell Training
• 10 PowerShell Commands Every Windows Admin Should Know

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)

Microsoft Windows PowerShell was conceived as the next-generation replacement for the old and reliable cmd.exe command shell environment. What’s especially cool about PowerShell is that it has a lot to offer both Windows systems administrators as well as .NET solution developers.

Trouble is, you have doubtless discovered that the PowerShell documentation, whether published by Microsoft or a third party, rarely differentiates between these two very different audiences. Therefore, administrators get confused and frustrated while trying to wade through PowerShell developer terminology, and .NET developers get befuddled and angry while trying to comprehend PowerShell administrator nomenclature.

To that end, I thought in this piece that I would attempt to help at least those in the systems administrator camp by explaining in plain English the primary PowerShell vocabulary terms. Let’s get started, shall we?

The cmdlet

The cmdlet (pronounced COMMAND-let) is the basic building block of Windows PowerShell. When you install PowerShell 2.0 on a Windows system, you receive by default the core library of PowerShell cmdlets. As you probably know, Microsoft has invested heavily in PowerShell technology. Therefore, most Microsoft server technologies ship with their own custom PowerShell modules. Examples of first-party extension modules include Active Directory, SQL Server 2008, SharePoint Server 2010 and Exchange Server 2010.

Regardless of their source, all cmdlets are designed (1) using a consistent usage rubric; and (2) to accomplish a single, specific task. Take a look at the following exhibit, and we’ll break down the constituent parts and pieces of a typical PowerShell command:

The PowerShell cmdlet and its components

Cmdlets always consist of a verb-noun compound phrase separated by a hyphen; this is done by design in order to make remembering PowerShell commands easy and intuitive. In the previous example, Get-ChildItem, the Get (verb) part of the command directs the action; in this case, to retrieve data. The ChildItem (noun) part of the command provides the focus for the verb; in the example, to obtain a directory listing.

NOTE: Cmdlets are completely case IN-sensitive. Therefore, the statements get-childitem, Get-ChildItem, and GET-CHILDITEM are all equivalent in practice.

You will discover that PowerShell uses many of the same verbs regardless of the origin or context of a particular PowerShell cmdlet:

• Get
• Set
• Add
• Remove
• Clear
• Enable
• Disable
• Start
• Restart
• Resume
• Stop

Please check out the nifty A-Z Index of Windows PowerShell 2.0 Commands for an alphabetical list of the built-in Windows PowerShell v2.0 cmdlet library.

Most PowerShell cmdlets support one or more parameters and arguments. A parameter represents additional data that is passed into a cmdlet to customize its operation. In PowerShell nomenclature, a named parameter is the parameter name followed by an argument. While most named parameters are prepended with a hyphen (-), not all are.

Moreover, not all cmdlets require an argument to accompany a parameter; these are called positional parameters because all that is required is the name of the cmdlet and the name of the parameter issued the proper order.

You can instruct PowerShell to list the full syntax of any available cmdlet by typing get-help cmdletname from the PowerShell prompt.

In case you haven’t picked this up from context, an argument is nothing more than a value that is passed to a parameter. In the current example, the Get-ChildItem cmdlet, which functions identically to the old DOS dir command, requires that you pass an argument (namely, the filespec for which you need a directory listing) to the cmdlet. In this case, -path is a positional parameter and can safely be omitted; thus, the statements Get-ChildItem –path C:\Tools and Get-ChildItem C:\Tools are synonymous.

The Pipeline

One of the most powerful aspects of Windows PowerShell (besides the fact that its command set has its roots in the all-pervasive .NET Framework, that is), is what is called the pipeline. Those of you who are already masters of *NIX shell scripting are already familiar with the pipeline, but for us Windows administrators, give a listen.

In PowerShell, piping refers to the process of passing the results of one cmdlet as an argument into a second cmdlet. Therefore, the pipeline enables us to create compound cmdlet sequences that perform multiple tasks in a single operation. Take a look at the following example:

The PowerShell pipeline

In the previous example, we “chain” together three PowerShell cmdlets by using the pipe (|) character. The net result in this case is that we receive a nifty, formatted list of our Windows services, organized by their run status. Pretty cool, eh?

Conclusion

There is so much more to Windows PowerShell for us systems administrators that I have had space or time to devote to in this brief article. In the second installment of this two-part miniseries, Windows PowerShell Terminology for Administrators: Part 2 of 2, I will cover two additional basic PowerShell terms: Alias and PowerShell Drive.

If there are other PowerShell-related topics that on which you would like to see coverage here at 4sysops, then please leave your request in the comments. Thanks!

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

I suppose if I had asked this question a few years ago, we would have received an even stronger bias for the GUI. PowerShell is changing the view of many Windows admins, simply because you can now do many things on the CLI that you can’t do with the admin tools that come with Windows. Before we had PowerShell, the Windows command prompt was mostly used for relatively trivial tasks like pinging a remote computer or perhaps clearing the DNS cache.

It is not difficult to guess for what I have voted. I am clearly pro GUI. It is not really that I am completely against working on command prompt. On a Linux server, I wouldn’t even install a desktop environment. In my view, Windows is just not made for the command line. Perhaps this is the reason why PowerShell commands are often so longwinded.

What upsets me in this discussion is the argument that you can “automate” administration tasks with PowerShell. In my opinion, this claim is absolutely meaningless. Every piece of software is meant to automate tasks. In fact, software has no other purpose. PowerShell fans usually want to imply with this assertion that with GUI tools, you have to do everything manually and that Windows admins can save a lot of time if they finally start automating things, just as their Linux colleagues do. The main reason why Windows is so successful is because there are so many great administration tools available that allow you to automate all kinds of tasks for thousands of machines with just a few clicks.

However, that doesn’t mean that I am against PowerShell. On the contrary! PowerShell is one of the most important Windows enhancements of the last years. It is probably the best programming language for Windows management. Thus, it has become a very important tool for all system management developers.

I also recommend that every Windows admin learns PowerShell. Microsoft sometimes offers only a PowerShell interface for new Windows features, probably in the hope that someone else will take on the expensive task of programming a graphical user interface. And, of course, sometimes you have no other choice than to write a script to get the job done, simply because no one else has yet written such a program or because your organization can’t afford a new tool. (Even though this is not as often the case as in former times.) Some readers have pointed out that it depends on the kind of task whether a GUI or a CLI is preferable. This is certainly also true.

The fact that one third of Windows admins can live perfectly with the command prompt also shows that, to a certain degree, the answer to this question is a matter of taste. Not all brains work the same way. I have seen admins who can type faster than I can think. If you feel comfortable on the command prompt, my anti-CLI rants won’t persuade you anyway. I am the most tolerant person when it comes to the choice of the right administration tool. Just do me the favor and don’t tell me that you can automate tasks just because you have PowerShell. It is like telling me that you can sit because you have the tools to build a chair and all others have to keep standing.

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• FREE: SetACL – Manage access control lists (acl) (0)

If you want to use these new features, you have to add the Cmdlets first. PowerShell v2 is now modularized. This only works under Windows Server, because you need to install the role “Active Directory Services” and the feature “Remote Server Administration Tools.” You can use the Server Manager for the installation, or if you prefer typing the following commands, you will have the same results:

import-module servermanager Add-WindowsFeature -Name “RSAT-AD-PowerShell” -IncludeAllSubFeature import-module ActiveDirectory

Now you have all the tools and are ready to check them out. One novation is that the AD gets mounted like a drive. The command to change to the drive and display its content is the same as with other drives:

cd AD: dir

Your window should look like this now:

If the AD was not mounted, make sure the relevant port (TCP 9389) is not blocked by a firewall. Besides that, the target AD Server must have installed the role “Active Directory Web Services.” If the requirements are met, you can add the drive with the following command:

New-PSDrive -PSProvider ActiveDirectory -Name AD -Root “” -Server “server.domain.tld” -get-credential

Here is a screenshot with an overview of all available Cmdlets:

The list was created with the following Cmdlet:

(Get-Module ActiveDirectory).ExportedCommands | format-table -Autosize

The help text for, e.g., the Get-ADForest Cmdlet, is displayed with this command:

get-help Get-ADForest

Now you can create and alter objects. I’ll just give you a few examples of adding a user, a group and a user to a group. The final example deletes the created user:

New-ADUser -Name “User” -SamAccountName “Username” -GivenName “Miller” -Surname “John” -DisplayName “John Miller” -Path ‘ou=Office,DC=domain,DC=tld’

New-ADGroup -Name “GroupToJoin” -SamAccountName groupToJoin -GroupCategory security   -GroupScope Global -DisplayName “GroupToJoin” -Path ‘ou=Office,DC=domain,DC=tld’ -Description “John wants to join this group”

Add-ADGroupMember “GroupToJoin” “Username”

Remove ADUser -Identity “Username”

The Cmdlets used for managing the Active Directory were not the only feature that got a nice boost with PowerShell v2. The management of HyperV and Exchange via PowerShell was also greatly improved. If you are interested in these topics, let me know and I’ll write about them.

• Raffle: Blackbird Auditor for Active Directory – Real-time Active Directory auditing (0)
• FREE: ManageEngine Free Active Directory Tools (0)
• Microsoft Exam 70-640 – Operations Masters – Sample question (3)
• Query free disk space details of remote computers using PowerShell (3)
• Microsoft Exam 70-640 – The Global Catalog – Sample question (0)

One of the more interesting trends of the computer age is that physical science students are increasingly unwilling or unable to write computer code. I was very upset when I first observed this and took stern measures in my department to counteract it, much to the students’ chagrin, for I myself am very good at coding and consider it something any self-respecting technologist should know how to do. Eventually, however, I realized that the students were right and I was wrong, and stopped the crusade. Computer programming is one of those things in life, like fixing one’s own car, that is fascinating, fun, useful–and unacceptably time-consuming. The truth is that it is no longer cost-effective for most well-educated people to program their own computers, or even to learn how to do so. The wise use of a time is to spend a few bucks to buy a program that does what one wants, or in extreme cases, search the internet for free software.

If you replace “physical science students” with “system administrators” you have more or less the same situation in today’s IT departments. Only most recently some administrators seem to be enticed by the powers of PowerShell to write their own code again.

I’ve often seen IT pros making the same mistake that Laughlin made at first. They believe that “any self-respecting IT pro should know how to code” and programming certainly also is “fascinating, fun, and useful”.

But as Laughlin correctly acknowledges, it is also “unacceptably time-consuming” and therefore, as far as IT departments are concerned, unacceptably expensive. The point here is that professional developers can do the job for a much lower price, especially if the program is not only used in one IT department , but in hundreds or thousands around the globe.

In the early days of networking, you simply had no other choice than to write your own scripts to get the job done. But those times are over. Rest assured that almost every “automation problem” you face has been already encountered by other admins somewhere else. And then, it is most likely that someone wrote a program to solve the problem which you can buy or perhaps even get for free on the web.

Thus, don’t make the mistake just because “PowerShell rocks” of wasting your time with coding if you could as well solve the problem in minutes with a downloadable tool. We live in a more and more specialized world. Programming and system administration were once just one discipline. But both fields have developed and are now highly complex; they are now two very distinct disciplines. To be successful you have no other choice than to focus on just one of them. Of course, if you are a developer working in an IT department, then PowerShell is now the first choice when it comes to programming Windows scripts.

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)

To some extent, the article reads as if Repadmin is a new tool, yet both tools have already been introduced in Windows 2000. Therefore, Microsoft dropped a GUI tool in favor of the command line version. This is in contradiction to Microsoft’s official policy, i.e., that command line and graphical admin tools are supported in the same manner. It has occurred to me several times, however, that this is really no longer the case. Ned Pyle indicates why:

Windows administrators are much more comfortable with the command-line, and that’s great…

I am not sure how to interpret this sentence. Perhaps he means that Windows admins are now more comfortable with the command line than they were some years ago, but the “that’s great” comment, as well as the tone in the article, seem to claim that Windows admins currently prefer command line tools.

This sort of praising of command line tools is relatively new for Microsoft, and it all started with the introduction of PowerShell. The idea for PowerShell was born at a time when many believed that Linux was a serious threat to Windows. Linux advocates often argued that Windows’ MS-DOS-based command shell is no match for the UNIX-like shells of the Open Source OS. Microsoft then decided to make up for this shortcoming. It was with the release of PowerShell 2.0 that Microsoft actually surpassed Linux in this field.

This certainly strengthens the Windows platform, but I also see the danger in the possibility that Repadmin won’t be the last tool that will be dropped in favor of a command line tool. Of course, it is much cheaper to develop a command line tool than the corresponding GUI version. Since more and more Microsoft tools are now based on PowerShell, the temptation to offer only a command line version is significant.

In detail, I’ve already outlined my view about the GUI-CLI controversy. I am still very much pro-GUI, and I believe that this renaissance of the command line interface (CLI) is a step backward. I started working as a sys admin at a time before Windows conquered PC networks, and I am also used to managing Linux boxes. In this respect, I feel like I know both worlds.

Anyway, I would like to know if Ned Pyle’s claim is true. I know that my obvious support for the GUI fraction endangers the validity of this poll since it might influence some readers. However, I also recommend reading Ned Pyle’s article as a counterweight. You might also want to read some of the pro CLI comments in my former rant against the CLI.

Before you vote, sit back for a moment, forget everything you have read, close your eyes, and then imagine your daily work as a Windows admin. Then, make your decision.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• FREE: SetACL – Manage access control lists (acl) (0)

I believe PowerShell’s integration into Windows will bring its breakthrough. As far as I’m concerned, the “DOS Command Prompt” is finally dead. Even if you haven’t found the time to learn PowerShell yet, it makes sense to use PowerShell ISE whenever you need a command line, because a graphical user interface is much more convenient.

The main advantage of PowerShell ISE is that you can work within two panes: one for typing commands and one where the output results are displayed. There is a third pane for editing scripts, but you can disable it, so as to have more space for the output pane.

My only complaint is that the command pane isn’t able to display a list of previously entered commands. You can navigate through commands with the cursor keys, as with the Command Prompt, but this is a very inconvenient way of accessing old commands, particularly if you have to accomplish complicated tasks that require many steps. If there was a complete list of all entered commands, you could just select the appropriate line without having to press the cursor key numerous times.

A good feature is the ability to resize PowerShell ISE’s, window using the mouse. I have never understood why the default width of the Command Prompt is only 80 characters, or why you can only resize it by accessing the window’s properties menu. Moreover, the Command Prompt’s copy and paste function is quite cumbersome. If a command or output overruns a line, it is impossible to highlight the whole line. Another nice feature of PowerShell ISE is that you can work with multiple shell tabs, which is more convenient than opening multiple Command Prompt windows.

Of course, the main function of PowerShell ISE is that you can use it for PowerShell commands. Moreover, it is much more convenient to write scripts in PowerShell ISE than it is in Notepad, because of features such as syntax highlighting, script tabs, and basic debugging capabilities.

However, if you often write PowerShell programs you probably will prefer the free PowerGUI tool, mostly because of its PowerPacks, which simplify the creation of PowerShell scripts for all kinds of products within the Windows ecosystem. Considering that PowerShell ISE can also be extended by third parties, I assume that there will be some interesting competition between the two in the future. This will also mean commercial products like Idera PowerShell Plus might find it hard to keep up.

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)

The main idea behind PowerGUI is to create PowerShell code by selecting objects, and performing actions on them. For instance, you can select Active Directory objects or Exchange objects manually or by using filters. Then you tell PowerGUI that you want to move these objects to a new location and it will create the corresponding PowerShell script which you can enhance with your own code.

This can be helpful for PowerShell beginners. However, you should have some basic knowledge of PowerShell or at least some experiences in object oriented programming. The real power of PowerGUI is that it helps you find the objects and their attributes easily. If you ever wrote a program to manipulate objects in a Microsoft application, then you know what I am talking about.

PowerGUIs script editor is great, too. It support syntax highlighting, autocomplete and offers bracket matching functionality. Most importantly, it comes with a nice debugger. I, personally, don’t like to write a script or program longer than five lines without a debugger at hand. The latest version supports pipeline debugging and breakpoints.

To get a quick overview of PowerGUI, I highly recommend watching this short online presentation.

PowerGUI

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)

The fact that I forgot to mention it is typical for me because I am not really a friend of the Windows command prompt. On Linux, it is just the opposite. I usually don’t even install KDE or Gnome on a Linux box. But from my point of view, Windows is just not made for this kind of administration. That’s why it is called Windows and not ComanndOS.

However this doesn’t mean that Server Manager’s command line capabilities don’t make sense at all. Actually, they can be very useful under certain circumstances. Usually, they come into play when you have to perform a certain task on many servers. But then you wouldn’t really use these commands on a prompt. Instead you would write a little script that does the job for you.

Usually, when I write such a script, I would try things first on the command prompt in a test environment. This is why such command line extensions of graphical tools can be quite useful. Scripting with Microsoft applications was always possible via APIs. The difference then is that you usually can’t just run a quick test on a command prompt if you write a program this way.

The same applies to PowerShell. The real power of PowerShell is that you can play with the commands while you write a little application. However, when things get a bit more complicated I prefer writing a real program with Visual Studio. So PowerShell like SERVERMANAGERCMD scripts are good for relatively simple automation tasks.

I know, there are many admins who disagree with me here, especially those who grew up in a UNIX environment will feel more at home on the command line. So to a certain degree, it is just a matter of taste if you work on the command prompt or with a GUI. However, I claim that under Windows in most cases you are simply faster with a graphical tool.

Takes one of Aaron’s examples:

SERVERMANAGERCMD -install TS-Terminal-Server,TS-Licensing,TS-Session-Broker -restart

I am not only referring to the fact that commands under Windows and also PowerShell tend to be quite long winded and will just cause finger arthritis in the long run. My point rather is that nobody memorizes such a command for a longer time. If you have to perform the same task after a month or so, you will start wondering if it was “TS-Session-Broker”, or was it just “session broker”? or maybe “TS-Sessionbroker”?

If you are an adventurous admin, you might just try and correct your command afterwards. But usually, you end up checking the manual. Then, you edit your command again, only to find out that Server Manager didn’t really do what you wanted because there was a typo in your command. If you are lucky, Windows would just respond with an error message. If this isn’t just your day, you would have seriously damaged some hundred servers.

One argument often put forward is that you can do more on the command prompt than with a GUI. This might be true in some rare cases, but can hardly be the reason for working always on the command prompt. And in some environments the opposite is true. For instance, you can’t configure server roles with Servermanagercmd.

It is also a big misunderstanding that you have somehow a more technical knowledge of the underlying processes if you work on the command prompt. Whether you understand what you are doing or not doesn’t depend on your typing skills, but on the time you invested to learn about the technical structure of your environment. Pasting a command from a manual and changing some of its parameters doesn’t really require geek knowledge.

That said, I certainly welcome the new command prompt capabilities of Vista and Server 2008. They are very useful in automating tasks in cases where the corresponding graphical tool doesn’t offer (yet) this functionality.

But, then, we usually talk about scripting and not about working on the command prompt. If you need a script for a certain task, it usually means that the developers of an application still have work to do to extend the graphical capabilities of their program. Scripting is nothing else than doing the job for your software vendor. Good graphical tools already come with all the automation you need. After all, every kind of program is only about automation. That’s why computers are so useful.

Thus, if someone from Microsoft tells you that PowerShell really rocks because you can automate all kinds of tasks with it, you can just respond that this is the very idea of any programming language. So I hope that in the future, Microsoft will add a feature to Server Manager that allows you to install server roles on multiple servers with just a mouse click.

The achievement of Windows and other graphic-oriented operating systems is that they made working with computers more human. Graphical interfaces mean more work for computers, but less for humans. Going back to the good old times of MS DOS is certainly not an option.

How about you? Are you working often now on the command prompt because of these new command tools? Or are you just using them to write scripts and continue your daily work like before with graphical tools?

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)

GPMC PowerShell Cmdlets

• Folder Redirection – Part 5: Best practices (1)
• Folder Redirection – Part 4: Group Policy configuration (0)
• Folder Redirection – Part 3: Explanation of folder permissions (4)
• Folder Redirection – Part 2: Setting up your file server (0)
• Folder Redirection – Part 1: Introduction (0)

There is a free and a commercial version. Please, check out this comparison table for the differences between the two. These are the most interesting features of the free edition of Specops Command:

Automatic PowerShell installation: The biggest problem you face when it comes to using PowerShell network wide is to get it installed on all your machines. Specops Command helps you deploy PowerShell in the background by using Group Policy software installation. It thereby makes sure that the correct PowerShell package is installed on different Windows editions.

Foreground and background script execution using Group Policy: Specops Commands allows you to execute PowerShell scripts using well known Group Policy procedures. That is, you can remotely launch scripts in the foreground (boot or logon) or background (Group Policy refresh intervals).

Credential elevation for user scripts: Users usually (hopefully) don’t have enough privileges for management tasks on their machines. Therefore, logon scripts often have to run with elevated credentials.

If you want to try Specops Command you should reserve some time for your test. The installation package installs the full version which is quite a sophisticated tool. The trial license allows you to use the full version for a limited time period. After that, you can continue using its free version. This video will you give a first impression of how to use Specops Command.

Specops Command

• Raffle: Blackbird Auditor for Active Directory – Real-time Active Directory auditing (0)
• FREE: ManageEngine Free Active Directory Tools (0)
• Folder Redirection – Part 5: Best practices (1)
• Folder Redirection – Part 4: Group Policy configuration (0)
• Folder Redirection – Part 3: Explanation of folder permissions (4)

The first thing you should do before you start playing with Graphical PowerShell is to change the execution policy to “unrestricted“. Otherwise, you won’t be able to run scripts within Graphical PowerShell. Open a PowerShell prompt as administrator and type:

Set-ExecutionPolicy Unrestricted

If you want to learn more about execution policies type:

get-help about_signing

Okay, let’s start looking at Graphical PowerShell.

Syntax highlighting

Check out the screenshot and you’ll see how Graphical PowerShell highlights syntax.

Multi-tabbed scripting pane

Grapical PowerShell allows you to open multiple scripts and you can switch between them using tabs.

Run scripts

In the upper pane, you can edit the scripts. After you saved it in a file, you can run it within Graphical PowerShell. The output of the script will be displayed in the middle pane.

Work on the command line

To work interactively with PowerShell you have to type in commands in the lower pane. The ouput will be displayed in the middle pane.

Multiple runspaces

The concept of runspaces is probably something for advanced PowerShell programmers. In Grapical PowerShell, you can consider them as different shells. Runspaces are organized in vertical tabs.

• Query free disk space details of remote computers using PowerShell (3)
• Change the local administrator password on multiple computers with PowerShell (4)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)