Summary: Guest blogger, Jason Hofferle, talks about Windows PowerShell Interactive and fan-out remoting.

Microsoft Scripting Guy, Ed Wilson, is here. TechReady 15 in Seattle has been a great event. I am really enjoying getting to see friends. Of course, I am also really enjoying Jason’s series about PowerShell Remoting. As a refresher here is a bit about Jason:

Jason Hofferle has been an IT professional since 1997. His experience includes enterprise desktop engineering for a Fortune 500 financial institution and Active Directory design for local governments and law enforcement. Jason currently works for the Defense Contract Management Agency, where he implements new technology such as virtual desktop infrastructure. He recently has been speaking about Windows PowerShell at SQL Saturday and IT Pro Camp events in Florida, and he frequently attends the Tampa PowerShell User Group.

Blog: Force Multiplication through IT Automation
Twitter: @jhofferle

In Part Two of this series, Configuring PowerShell Remoting, I discussed how to configure PowerShell Remoting in your environment. Now we’re going to take a look at how it can be used after it’s up and running.

There are two primary PowerShell Remoting usage paradigms for IT professionals: interactive and fan-out. Interactive remoting is used when I need to interact with a remote computer as if I was sitting directly in front of the system, logged into the console. Fan-out remoting is used when I have a single command or script that I want to run on a group of computers. It could be two systems, or two thousand systems. Whenever I need a command to efficiently execute on a large number of systems, fan-out is the way to go.

To use interactive remoting, or one-to-one, I utilize the Enter-PSSession cmdlet with the ComputerName parameter. When my prompt changes to reflect the remote computer’s name, I know that I’m interacting with the remote system. This is great for performing actions that don’t have built-in functionality for performing actions against remote systems, such as registering a dynamic link library (DLL) to correct an issue. When I’m finished working on the remote computer, the Exit-PSSession cmdlet closes the session, and my prompt returns to the local operating system.

Enter-PSSession –ComputerName DC1

Set-Location C:\Windows\System32

Regsvr32.exe .\capiprovider.dll /s

When I want to use fan-out remoting, or one-to-many, I turn to the Invoke-Command cmdlet. This time I use a list of computer names for the ComputerName parameter, and I provide the command that I want them to run for the ScriptBlock parameter. Because the command executes on the remote computer, tasks such as searching and filtering the event log are performed locally, and only the information I want is sent over the network. When using Invoke-Command, each returned object has a PSComputerName parameter added, which enables me to determine which remote computer each object came from.

Invoke-Command –ComputerName DC1,Win7,Win7-2 –ScriptBlock {Get-Service The*}

Typing commands into a script block can be tedious and error prone when it’s more than something simple. Invoke-Command has a FilePath parameter than can be used when an entire script needs to be executed remotely. Windows PowerShell takes the .ps1 file on the local computer, and converts it into a script block automatically.

Invoke-Command –ComputerName DC1,Win7 –FilePath C:\MyScript.ps1

PowerShell Remoting can also be used in conjunction with background jobs. The AsJob parameter of Invoke-Command allows a long-running PowerShell Remoting command to run in the background, freeing up the Windows PowerShell console for other tasks. When the job has completed, the results can be retrieved with the Receive-Job cmdlet.

Invoke-Command –ComputerName DC1,Win7 –ScriptBlock {Get-Service WinD*} –AsJob

PowerShell Remoting is extremely useful in situations where I need to quickly collect information from systems, like performing ad-hoc queries on event logs. During a recent deployment of Windows 7, we experienced frequent issues with Outlook losing connectivity with Exchange. It was determined that a specific chip set combined with a particular driver on this particular operating system enabled a power-saving feature on the network adapter. Every time the monitor went into sleep mode, the adapter renegotiated the network speed to the lowest possible value. This disconnected the network for a few seconds, which was enough to cause Outlook to complain. Users would come back from a meeting and find that Outlook wasn’t working correctly.

After the fix was deployed to the Windows 7 test group, we needed to prove that the issue had been resolved. I used PowerShell Remoting to collect network disconnection events from our Windows 7 systems, exported the results to a comma separated values file, and then used Microsoft Excel to generate a chart showing how the disconnection events significantly dropped after the fix. In a few minutes, I was able to produce hard evidence that we resolved our remaining issue and get the green light for Windows 7 deployment.

~Jason

Way cool stuff, Jason. Thank you for taking the time to share with us today. We look forward to Part Four tomorrow.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy