Breaking CIM sessions

A CIM session is analogous to a PowerShell remoting session but for CIM based cmdlets – the CIM cmdlets themselves and any CDXML based cmdlets e.g. the networking cmdlets

By default a CIM session uses WSMAN as its transport protocol – the same as remoting. You do have the choice to create a CIM session using DCOM for transport (same as the WMI cmdlets use)

I’ve always maintained that DCOM based sessions could be broken if the remote machine was re-started. This was based on the testing I did when writing PowerShell and WMI.

Some recent information cast doubt on that assertion though.  I’ve digging into CIM sessions recently and have what I think is a definitive statement on DCOM based CIM sessions.

If you create a DCOM based CIM session to a machine running PowerShell 2.0 from a machine running PowerShell 3.0 (or PowerShell 4.0 – I haven’t tested recently but remember doing this when writing the CIM section of PowerShell in Depth) access the remote machine and then restart and attempt to use the session – it will break like this:

$dopt = New-CimSessionOption -Protocol Dcom
$dcs = New-CimSession -ComputerName W8R2STD01 -SessionOption $dopt
Get-CimInstance -ClassName Win32_OperatingSystem -CimSession $dcs

SystemDirectory   Organization     BuildNumber      RegisteredUser   SerialNumber     Version          PSComputerName
—————   ————     ———–      ————–   ————     ——-          ————–
C:\Windows\sys…                  7601             Windows User     00477-179-000… 6.1.7601         W8R2STD01

Restart-Computer -ComputerName W8R2STD01
Get-CimInstance -ClassName Win32_OperatingSystem -CimSession $dcs
Get-CimInstance : Access is denied.
At line:1 char:1
+ Get-CimInstance -ClassName Win32_OperatingSystem -CimSession $dcs
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (root\cimv2:Win32_OperatingSystem:String) [Get-CimInstance], CimExcept
    + FullyQualifiedErrorId : HRESULT 0x80070005,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand
    + PSComputerName        : W8R2STD01

The CIM session will usually become usable again after a period of time.

If you repeat the experiment using WSMAN or DCOM sessions to machines running PowerShell 3.0 or above the command to use the session is effectively paused until the session is responsive – this can take a little time

A machine running PowerShell 5.0 RTM can create a CIM session to PowerShell 2.0 (DCOM)  or later (DCOM or WSMAN) and the command is effectively paused until the remote machine is up.

The only time I can see the need to use a DCOM based CIM session is to access a PowerShell 2.0 machine – under any other circumstances I’d recommend using the default WSMAN based sessions.

Bottom line is that DCOM based sessions can be broken under specific circumstances that hopefully with time will disappear. 

This entry was posted in PowerShell and CIM. Bookmark the permalink.

One Response to Breaking CIM sessions

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s