As you may have read, in PowerShell 3.0, there is a new family of cmdlets designed to improve the way we work with WMI. The powerful Get-WmiObject cmdlet may become obsolete over time.
Get-CimInstance, for example, works very similar to Get-WmiObject. It focuses on object properties, though, because the CIM cmdlets can base on different remoting techniques, some of which are stateless (and very robust). By default, all CIM cmdlets use WinRM, the new remoting technique found in PowerShell 3.0 as well.
So by default, you cannot remotely access a system that has no WinRM capabilities. With a little trick, however, you can convince the CIM cmdlets to fall back and use the old DCOM protocol instead. Here is an example:
Get-CimInstance -ClassName Win32_BIOS Get-CimInstance -ClassName Win32_BIOS -ComputerName storage1
This will first get BIOS information from the local computer. Next, it tries and read the information from a remote system called "storage1". This may fail if that system won't support WinRM, for example, because it might be some old server 2003 with PowerShell 2.0 on it. In this case, you'd get an ugly red exception message, complaining that some DTMF resource URI wasn't found.
So next are the lines you can use to force Get-CimInstance to use the old DCOM technology:
$option = New-CimSessionOption -Protocol DCOM $session = New-CimSession -ComputerName storage1 -SessionOption $option Get-CimInstance -ClassName Win32_BIOS -CimSession $session
This time, the server could be contacted and returns the data.
