Prof. Powershell

WMI CIM-plified Part 3: Remote Systems Management

Remote systems management is where it gets interesting for CIM in PowerShell 3.0.

• By Jeffery Hicks
• 04/30/2013

We've been exploring the new world of CIM in PowerShell 3.0. Where this really gets interesting is when it comes to remote systems management. If you look at help for Get-CimInstance, you'll see there are parameters for Computername and something called CimSession. More on that in a bit. The "easy" way is to have PowerShell 3.0 installed locally and remotely and simply specifying the remote computer name.

PS C:\> get-ciminstance win32_operatingsystem -computer client8 | select Lastbootuptime

Lastbootuptime
--------------
3/13/2013 2:44:39 PM

If we were using Get-WMIObject, PowerShell would have used DCOM to connect to the remote machine and query WMI. But now, PowerShell will use the WSMAN protocol. This is the same protocol that PowerShell remoting uses, which means you only have a single, secure port to deal with. While typically systems running Windows Management Framework v3 will also be running PowerShell 3.0, they don't have to be running it. Or even have PowerShell remoting enabled!

PS C:\> enter-pssession client8 enter-pssession : Connecting to remote server client8 failed with the following error message :
Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ enter-pssession client8
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidArgument: (client8:String) [Enter-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : CreateRemoteRunspaceFailed

PS C:\> get-ciminstance win32_operatingsystem -computer client8 | select Lastbootuptime

Lastbootuptime
--------------
3/13/2013 2:44:39 PM

Even though remoting is disabled, I am still able to use the CIM cmdlets to query the computer. This means that any WMI enabled device that supports the latest version of the WSMAN protocol, which is an open standard, can be managed from PowerShell 3.0. Even non-Microsoft systems. But for now, we'll stick to the world of Windows.

When you use Get-CimInstance to connect to a remote computer, what happens behind the scenes is that PowerShell creates a temporary remote session called a CIMSession. It uses this session, retrieve the data, then tears it down. However, if you are going to be working with remote systems repeatedly, there is a benefit to creating CIMSessions so that they can be reused with New-CimSession.

First I'll create a few sessions using alternate credentials.

PS C:\> $a,$b = new-cimsession chi-dc01.globomantics.local,chi-fp01.globomantics.local -Credential globomantics\administrator
PS C:\> $a

Id           : 2
Name         : CimSession2
InstanceId   : c3041675-0a31-4c74-af0b-926c482ec64b
ComputerName : chi-dc01.globomantics.local
Protocol     : WSMAN

PS C:\> $b

Id           : 3
Name         : CimSession3
InstanceId   : 12eb801e-e0bb-469f-a4a3-e7350c7083ba
ComputerName : chi-fp01.globomantics.local
Protocol     : WSMAN
Now I can use these sessions.
PS C:\> get-ciminstance win32_operatingsystem -CimSession $a,$b | Select PScomputername,LastBootuptime

PSComputerName                                    LastBootuptime
--------------                                    --------------
chi-fp01.globomantics.local                       3/25/2013 6:14:31 PM
chi-dc01.globomantics.local                       3/25/2013 5:40:19 PM

You can also pipe the sessions.

PS C:\>$a,$b | get-ciminstance win32_operatingsystem | Select PScomputername,LastBootuptime

Or, if I have a lot of sessions, I can retrieve them all and pipe them to Get-CimInstance.

PS C:\> get-ciminstance | get-ciminstance win32_operatingsystem | Select PScomputername,LastBootuptime

I can re-use these sessions as often as I need to without the added overhead of setting them up and tearing them down. This also explains why there are no methods returned because the data is serialized over the wire like it is in a normal PowerShell remoting session.

But what happens when we try to query a computer running PowerShell 2.0?

PS C:\> get-ciminstance win32_bios -computername jdhit-dc01
get-ciminstance : The WS-Management service cannot process the request. A DMTF resource URI wasused to access a non-DMTF class. Try again using a non-DMTF resource URI.

At line:1 char:1
+ get-ciminstance win32_bios -computername jdhit-dc01
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (root\cimv2:win32_bios:String) [Get-CimInstance], CimE   xception
+ FullyQualifiedErrorId : HRESULT 0x80338139,Microsoft.Management.Infrastructure.CimCmdlets.Ge
tCimInstanceCommand

Looks bad. But it really isn't. Next time I'll show you how to handle this situation.