Prof. Powershell

WMI CIM-plified Part 4: Remote to Second PowerShell

The fourth part of the CIM cmdlets blog series focuses on creating a duplicate CIM session on a different PowerShell unit.

• By Jeffery Hicks
• 05/07/2013

The new CIM cmdlets in PowerShell 3.0 rely on a remoting feature called a CIM Session. By default this session utilizes the WSMAN protocol, Specifically the newer version of the protocol. So creating a session to another PowerShell 3.0 computer is as easy as this:

PS C:\> $s = new-cimsession server01

However, this won't work for computers running PowerShell 2.0 or even no PowerShell at all! One way to test this is with Test-WSMan.

PS C:\> test-wsman client8

wsmid           : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 3.0

The Stack version is what we're interested in and as you can see here the computer is running 3.0. A computer running PowerShell 3.0 would show 2.0. Unfortunately, the version number is not a distinct property so you would need to parse it out of the ProductVersion property. But here's one way using regular expressions that you could turn into a function. First, I'll define a simple regular expression pattern to match the number pattern at the end of the line.

PS C:\> [regex]$rx="\d\.\d$"

Now get the test data.

PS C:\> $data = test-wsman client8

Finally I can test for a match:

PS C:\> $rx.match($data.ProductVersion)

Groups   : {3.0}
Success  : True
Captures : {3.0}
Index    : 25
Length   : 3
Value    : 3.0

Or this would be even better.

PS C:\> $rx.match($data.ProductVersion).value -eq '3.0'
True

If this had not been true, then I need to create a CIM Session that takes this into account. What this means is that I need to create a session that uses DCOM, the legacy protocol, instead of WSMAN. This requires an extra step to create a CIM SessionOption.

PS C:\> $opt = New-CimSessionOption -Protocol Dcom

Now I can create the correct CIM Session object.

PS C:\> $s = new-cimsession -ComputerName Server08 -SessionOption $opt

And use it:

PS C:\> $s | get-ciminstance win32_logicaldisk -filter "deviceid='c:'" | fl

DeviceID       : C:
DriveType      : 3
ProviderName   :
FreeSpace      : 166254592000
Size           : 201504845824
VolumeName     : Drive_C
PSComputerName : Server08

As long as the session is configured properly you can have a mix of protocols. This makes it easier to run commands like this:

PS C:\> get-cimsession | get-ciminstance win32_logicaldisk -filter "deviceid='c:'" | export-clixml c:\work\cdrives.xml

While I recommend using sessions with the appropriate protocol, Get-CIMInstance has a little quirk when using the –Query parameter. A command like this will fail against an older system.

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

But this equivalent command works, all without having to predefine any sessions or protocols.

PS C:\> get-ciminstance –query "select * from win32_bios" –computer jdhit-dc01

SMBIOSBIOSVersion : 6.00 PG
Manufacturer      : Phoenix Technologies, LTD
Name              : Phoenix - AwardBIOS v6.00PG
SerialNumber      :
Version           : KM400  - 42302e31
PSComputerName    : jdhit-dc01

In this situation the cmdlet appears to be reverting to the DCOM protocol automatically. But I still think the best approach is to use a CIM Session so that you have complete control of all settings such as port, protocol and credentials. Eventually, you will want to get all of your systems to the latest version of the Management Framework so that you can use the CIM cmdlets. In the next lesson we'll look at how to invoke a method on a CIM object.