Scripting and automation are common features requests that IT administrators love to have. There are common
tasks that IT administrators do in their daily job which requires more than a few clicks, for example, user
creation, which they would love to be able to automate the process.
So what can PowerShell in Windows Server 2008 R2 do for you? We are going to look into the fundamentals and move
on to advanced capabilities you will find beneficial in your work.
PowerShell in a Nutshell
PowerShell is a task-based command line shell and scripting language for system administrators. Through
PowerShell, common tasks can be scripted to automate the administration work of Windows operating systems and
Windows-based applications for system administrators.
Unlike traditional tools such as the command line (cmd.exe in Windows XP and above, or command.com in
Win9x), PowerShell allows easy access to COM and WMI, allowing the ability to perform advanced administrative tasks
on both local and remote Windows systems. Since PowerShell is built on top of .NET framework, it is possible to extend and take advantage of .NET classes for greater functionality and customizations.
PowerShell 2.0, which comes built in with Windows Server 2008 R2, has received some major improvements we’ll cover shortly. One of the big changes with PowerShell 2.0 is the presence of PowerShell Remoting, which allows scripts to be executed on remote machines. Equipped with PSJob (Background Jobs), commands can be executed and run in the background. Cmdlets and provider developers can perform transaction operations, allowing transaction cmdlets to be started, committed and rolled back if needed.
There are other cool improvements on PowerShell 2.0, but we’ll put additional focus on the above 3 features.
PowerShell 2.0 in Action
PowerShell 2.0 is built into Windows Server 2008 R2 and Windows 7. For older operating systems, PowerShell 2.0
is scheduled to be available a few months down the road and will include support for Windows XP SP3, Windows Server
2003 SP2, Windows Vista SP1 and Windows Server 2008.
PowerShell Remote Management
PowerShell supports two types of remote management: Fan-in remoting, and Fan-out remoting. Fan-in remoting
allows concurrent users to remote into a single server. Multiple customers could, for instance, remote into a
hosted Exchange server to manage their respective mailbox. Fan-out remoting makes it possible to send out a set of
commands or scripts to a group of remote servers at once. Fan-out remoting relies on Windows Management
Instrumentation (WMI) and Windows Remote Management (WinRM)
The first step to use PowerShell remoting is to enable the remoting feature on the remote box:
PowerShell Remoting only works if the network location is set under Home, Work or Domain. If one or more network
connections are under the Public network location, enabling PowerShell Remoting will fail.
In PowerShell 1.0, the only cmdlet that allows remote query is Get-WMIObject, which only allows the
retrieval of remote objects through WMI. However now more cmdlets are able to establish a remote PowerShell
To execute a cmdlet on a remote computer, we’ll use the –ComputerName parameter. Let’s list out the
services on the remote machine:
Get-service –ComputerName JabezGan-HP
By default, all cmdlets that are executed runs synchronously, as in, the entire script will be executed and
finished on one remote machine, before the next remote machine will execute the script. With background job, the
scripts will be executed on all affected remote machines at the same time.
$servers = @("hyper-v","Jabezgan-hp")
Get-Wmiobject Win32_operatingsystem –computername @servers
To execute the cmdlet as a background job, we use the –asjob switch:
Get-Wmiobject Win32_operatingsystem –computername @servers –asjob
To check for on the status of the jobs, we use the cmdlet Get-Job:
PowerShell 2.0 supports transactions, which allows you to commit or rollback to earlier configurations. Let
me show you how.
First step is to enable transaction, by running the following:
Let’s add a new value into the registry:
New-ItemProperty -path HKCU:Test -name TransactedValue -value "Test value!" -useTransaction
Note the use of –useTransaction. –useTransaction tells PowerShell that the command is part of a
transaction, and by running the above command, it will only add the commands into memory.
To commit, we use the cmdlet:
And to discard, we use:
I’ve introduced three of my favorite new features in PowerShell 2.0 — PowerShell Remoting, Background job and
Transaction support — but there are many more features in PowerShell 2.0 that I did not cover. These new features introduce us to a whole new level of remote management and improved machine performance.
As Microsoft’s product group moves to convert their current management consoles to be built in top of
PowerShell, we’ll be getting more powerful management consoles in coming releases.
We are going to look into Active Directory and Identity Management in our next article. Stay tuned!