To access a remote machine using WMI we use
Get-WmiObject -Class Win32_ComputerSystem -ComputerName webr201
This is replicated using the CIM cmdlets
Get-CimInstance -ClassName Win32_ComputerSystem -ComputerName webr201
No lets repeat with another server
Get-WmiObject -Class Win32_ComputerSystem -ComputerName server02
and with CIM
Get-CimInstance -ClassName Win32_ComputerSystem -ComputerName server02
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.
At line:1 char:1
+ Get-CimInstance -ClassName Win32_ComputerSystem -ComputerName server02
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (Win7Test.Manticore.org:) [Get-CimInstance], CimException
+ FullyQualifiedErrorId : 2150859065,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand
We get an error. Huh! What’s going on?
The problem is that the WMI cmdlets use DCOM to access remote machines. By default the CIM cmdlets use WSMAN. In fact the only time they use DCOM is to access the local machine IF a machine name such as “.”, “localhost” or “$env:COMPUTERNAME” isn’t used i.e. no use of the –Computername parameter to access local machines.
My webr201 server is using PowerShell v3 but server02 is still on PowerShell v2. We can see the difference
PS> Test-WSMan -ComputerName webr201 -Authentication default
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: 6.1.7601 SP: 1.0 Stack: 3.0
PS> Test-WSMan -ComputerName server02 -Authentication default
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: 6.1.7601 SP: 1.0 Stack: 2.0
Webr201 is using WSMAN 3 from PowerShell v3 so it works with the CIM cmdlets but server02 is using WSMAN 2 so doesn’t work. Does that mean that we can’t use the CIM cmdlets against systems running PowerShell v2? NO it doesn’t – it means we need to use CIM sessions but that is a topic for next time
CIM cmdlets can use DCOM, if you establish the session beforehand and provide a session option.
$options = New-CimSessionOption -Protocol Dcom
$cim = New-CimSession -SessionOption $options -computer SomePowerShellV2Computer
Get-CimInstance win32_bios -CimSession $cim
It’s a bit more work than Get-WMIObject, but it is possible.
Agreed – thats why I said it was going to be my next post
http://richardspowershellblog.wordpress.com/2012/01/16/cim-sessions/
CIM sessions are much more powerful that straight DCOM with the WMI cmdlets. I can see myself dropping the WMI cmdlets for the CIM cmdlets when v3 comes out