Summary: Guest blogger, Trevor Sullivan, compares Windows PowerShell PSSessions and CIM sessions. Microsoft Scripting Guy, Ed Wilson, is here. Today we have the exciting conclusion to Honorary Scripting Guy, Trevor Sullivan’s guest blog series on CIM. To see more of Trevor’s guest posts, see these Hey, Scripting Guy! Blog posts. You can reach Trevor on Twitter (https://twitter.com/pcgeek86) or follow him on his blog, Trevor Sullivan’s Tech Room, Minding the gap between administration and development.      Note  This is the fifth in a of five blog series by Trevor where he talks specifically about using the CIM cmdlets. To catch up, read the following posts:

• What is CIM and Why Should I Use It in PowerShell?
• Introduction to the CIMCmdlets PowerShell Module
• Use PowerShell to Manipulate Information with CIM
• Invoking CIM Methods with PowerShell

In today’s post, we will compare and contrast Common Information Model (CIM) sessions and Windows PowerShell (PS) sessions. Both types of sessions are intended to provide remote connectivity to Windows computers, primarily for management purposes.

Windows Remote Management service

The most obvious trait that is shared by CIM and PS sessions is that they both leverage the Windows Remote Management (WinRM) service. As we discussed in an earlier post this week, the WinRM service allows network administrators to reliably predict where network traffic will be running to and from. This is a huge benefit for both types of sessions, for network and security teams, and for Windows administrators who need to troubleshoot WinRM connectivity. WinRM is an HTTP-based service, so both CIM sessions and Windows PowerShell sessions also support connectivity through an authenticated proxy server connection. Windows PowerShell sessions offer the ability to deploy arbitrary scripts to remote systems via the WinRM service. These scripts can return any type of .NET object as a result to the host session, and they are not restricted to CIM information. A Windows PowerShell session will stay connected, by default, until the idle timer runs out. In Windows PowerShell 4.0 and Windows PowerShell 3.0, you can disconnect Windows PowerShell sessions by using the Disconnect-PSSession cmdlet, and then reconnect to the session by using the Connect-PSSession cmdlet.

CIM sessions are a bit limited

CIM sessions are more limited than PS Sessions, because they cannot execute arbitrary commands and return arbitrary objects. However, they provide the unique benefit of taking up fewer system resources. CIM sessions stay dormant in the background of a Windows PowerShell session until an instruction is received. Upon receipt of an instruction, the CIM session will connect to the remote computer, retrieve the results, and then disconnect from the remote system. If you are writing Windows PowerShell scripts that target a very large number of systems, you might find that CIM sessions offer a lighter weight solution than PS sessions.

The bottom line

So, when exactly will you use a CIM session over a Windows PowerShell session? That’s for you to decide, however… In most of my Windows PowerShell development efforts, I tend to take advantage of the Windows PowerShell remote sessions because they offer much richer capabilities. There are quite a few Windows PowerShell modules in Windows Server 2012 R2 and Windows 8.1 that take advantage of CIMSessions. These modules include: DnsClient, DnsServer, VpnClient, NetConnection, NetTCPIP, PSDesiredStateConfiguration, BranchCache, IpamServer, and ScheduledTasks. I thank you for joining me this week to review the CIMCmdlets PowerShell module. I look forward to your continued involvement in the Windows PowerShell community. Please find me on Twitter via alias @pcgeek86. ~Trevor Thank you, Trevor, for an awesome week. It has been fun and educational. This concludes CIM Week. Join us tomorrow when we will talk about auto installer and Windows PowerShell. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy