Three Essential PowerShell 2.0 Remote Management Features

With Windows Server 2008 R2, PowerShell gets a big overhaul and makes remote management a snap. Jabez Gan examines three key remote management features.

By Jabez Gan | Posted May 3, 2010
Page of   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

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

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:

Enabling PowerShell Remoting

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 connection.

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

Background Job

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:

Get-Job

Transactional Support

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:

Enable-Transaction

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:

Complete-Transaction

And to discard, we use:

Undo-Transaction

Conclusion

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!

Resources

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter