{"id":76781,"date":"2016-02-08T00:01:40","date_gmt":"2016-02-08T00:01:40","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/?p=76781"},"modified":"2019-02-18T09:19:57","modified_gmt":"2019-02-18T16:19:57","slug":"should-i-use-cim-or-wmi-with-windows-powershell","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/should-i-use-cim-or-wmi-with-windows-powershell\/","title":{"rendered":"Should I use CIM or WMI with Windows PowerShell?"},"content":{"rendered":"<p><strong>Summary<\/strong>: Richard Siddaway explains the differences between the CIM cmdlets and the WMI cmdlets, and details use cases.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/q-for-powertip.jpg\" alt=\"Hey, Scripting Guy! Question\" \/>\u00a0Hey, Scripting Guy! Should I use the WMI cmdlets or the newer CIM cmdlets?<\/p>\n<p>\u2014NR<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/a-for-powertip.jpg\" alt=\"Hey, Scripting Guy! Answer\" \/>\u00a0Hello NR,<\/p>\n<p>Honorary Scripting Guy, Richard Siddaway, here today filling in for my good friend, The Scripting Guy. The simple answer is that you can use either Windows Management Instrumentation (WMI) or Common Information Model (CIM) cmdlets, but there are (to my mind) some significant advantages to using the newer CIM cmdlets.<\/p>\n<p>Before I show you why I think you should use the CIM cmdlets, let\u2019s do a little recap.<\/p>\n<p>First, you have to remember that CIM = WMI = CIM. CIM is an open standard from the <a href=\"http:\/\/www.dmtf.org\/standards\/cim\" target=\"_blank\">Distributed Management Task Force<\/a> (DMTF), with the latest version introduced in January 2016. CIM provides a common definition of management information for systems, networks, applications, and services, and it allows for vendor extensions. WMI is the Microsoft implementation of CIM for the Windows platform.<\/p>\n<p>Let\u2019s start by runnig this:<\/p>\n<p style=\"padding-left: 30px\">\u00a0Get-CimClass *Process | select CimClassName<\/p>\n<p style=\"padding-left: 30px\">CimClassName<\/p>\n<p style=\"padding-left: 30px\">&#8212;&#8212;&#8212;&#8212;<\/p>\n<p style=\"padding-left: 30px\">CIM_Process<\/p>\n<p style=\"padding-left: 30px\">Win32_Process<\/p>\n<p style=\"padding-left: 30px\">Win32_NamedJobObjectProcess<\/p>\n<p style=\"padding-left: 30px\">CIM_OSProcess<\/p>\n<p style=\"padding-left: 30px\">Win32_SessionProcess<\/p>\n<p style=\"padding-left: 30px\">Win32_PerfFormattedData_PerfProc_Process<\/p>\n<p style=\"padding-left: 30px\">Win32_PerfRawData_PerfProc_Process<\/p>\n<p>Notice the CIM_Process and Win32_Process classes? CIM_Process is the original standard class. Win32_Process is the Microsoft-specific class, which may (or may not) be modified from the original. You\u2019ll see many pairings like this in the default CIM namespace \u2013 root\\cimv2.<\/p>\n<p>WMI was first introduced in the days of NT\u00a04.0, and usual way to access it by IT pros was to use VBScript. Moving swiftly on\u2026<\/p>\n<p>These WMI cmdlets were introduced in Windows PowerShell 1.0 and 2.0:<\/p>\n<ul>\n<li>Get-WmiObject<\/li>\n<li>Invoke-WmiMethod<\/li>\n<li>Register-WmiEvent<\/li>\n<li>Remove-WmiObject<\/li>\n<li>Set-WmiInstance<\/li>\n<\/ul>\n<p><strong>Get-WmiObject<\/strong> is one of the original PowerShell cmdlets. (As a quick quiz, how many of the 137 original cmdlets can you name?). It was enhanced in PowerShell\u00a02.0 when the other WMI cmdlets were introduced. In PowerShell\u00a01.0, <strong>Get-WmiObject<\/strong> was the only cmdlet with the option to access another system.<\/p>\n<p>The big drawback to the WMI cmdlets is that they use DCOM to access remote machines. DCOM isn\u2019t firewall friendly, can be blocked by networking equipment, and gives some arcane errors when things go wrong.<\/p>\n<p>The CIM cmdlets appeared in PowerShell\u00a03.0 as part of the new API for working with CIM classes, which is more standards based. The CIM cmdlets were overshadowed by PowerShell workflows, but they are (to my mind) the most important thing to come out of that release.<\/p>\n<p>The other major CIM-related advance was the introduction of CDXML, which enables a CIM class to be wrapped in some simple XML and published as a PowerShell module. This is how over 60% of the cmdlets in Windows\u00a08 and later are produced.<\/p>\n<p style=\"padding-left: 30px\"><strong>Note<\/strong>\u00a0\u00a0\u00a0I explained how to use CDXML in my <a href=\"https:\/\/social.msdn.microsoft.com\/Search\/en-US?query=%22Richard%20Siddaway%22%20and%20registry&amp;beta=0&amp;rn=Hey%2C+Scripting+Guy%21+Blog&amp;rq=site:http:\/\/blogs.technet.com\/b\/heyscriptingguy&amp;ac=6\" target=\"_blank\">Hey, Scripting Guy! Blog series about creating Registry cmdlets<\/a>.<\/p>\n<p>There are CIM cmdlets that are directly equivalent to the WMI cmdlets:<\/p>\n<ul>\n<li>Get-CimInstance<\/li>\n<li>Invoke-CimMethod<\/li>\n<li>Register-CimIndicationEvent<\/li>\n<li>Remove-CimInstance<\/li>\n<li>Set-CimInstance<\/li>\n<\/ul>\n<p>You also get extra cmdlets for working with CIM classes:<\/p>\n<ul>\n<li>Get-CimAssociatedInstance<\/li>\n<li>Get-CimClass<\/li>\n<li>New-CimInstance<\/li>\n<\/ul>\n<p>The big difference between the WMI cmdlets and the CIM cmdlets is that the CIM cmdlets use WSMAN (WinRM) to connect to remote machines. In the same way that you can create PowerShell remoting sessions, you can create and manage CIM sessions by using these cmdlets:<\/p>\n<ul>\n<li>Get-CimSession<\/li>\n<li>New-CimSession<\/li>\n<li>New-CimSessionOption<\/li>\n<li>Remove-CimSession<\/li>\n<\/ul>\n<p>If you look in the PowerShell Help files, you\u2019ll see messages like this:<\/p>\n<p style=\"padding-left: 30px\">\u201cStarting in Windows PowerShell 3.0, this cmdlet has been superseded by Get-CimInstance.\u201d<\/p>\n<p>I take this to mean that the CIM cmdlets are the supported option and that in time the WMI cmdlets could be removed.<\/p>\n<p>Time to look at the individual cmdlets\u2026<\/p>\n<p><strong>Get-WmiObject<\/strong> does a great job (if you\u2019ve ever had to work with WMI through VBScript you\u2019ll appreciate how great), but it has a few awkward edges. A particular pain point is working with dates, for example:<\/p>\n<p style=\"padding-left: 30px\">Get-WmiObject -Class Win32_OperatingSystem | select LastBootUpTime<\/p>\n<p style=\"padding-left: 30px\">LastBootUpTime<\/p>\n<p style=\"padding-left: 30px\">&#8212;&#8212;&#8212;&#8212;&#8211;<\/p>\n<p style=\"padding-left: 30px\">20160131094454.487954+000<\/p>\n<p>The objects produced by <strong>Get-WmiObject<\/strong> have a couple of methods added by the PowerShell team to make life easier:<\/p>\n<p style=\"padding-left: 30px\">Get-WmiObject -Class Win32_OperatingSystem | select @{N=&#8217;LastBootTime&#8217;; E={$_.ConvertToDateTime($_.LastBootUpTime)}}<\/p>\n<p style=\"padding-left: 30px\">LastBootTime<\/p>\n<p style=\"padding-left: 30px\">&#8212;&#8212;&#8212;&#8212;<\/p>\n<p style=\"padding-left: 30px\">31\/01\/2016 09:44:54<\/p>\n<p>But the CIM cmdlets do it all for you:<\/p>\n<p style=\"padding-left: 30px\">Get-CimInstance -ClassName Win32_OperatingSystem | select LastBootUpTime<\/p>\n<p style=\"padding-left: 30px\">LastBootUpTime<\/p>\n<p style=\"padding-left: 30px\">&#8212;&#8212;&#8212;&#8212;&#8211;<\/p>\n<p style=\"padding-left: 30px\">31\/01\/2016 09:44:54<\/p>\n<p><strong>Invoke-WmiMethod<\/strong> has a quirk in that if you supply the method parameters in the order specified by the WMI documentation, you will sometimes get an error message. The way to check the correct order of the parameters is to use <strong>Get-CimClass<\/strong>:<\/p>\n<p style=\"padding-left: 30px\">\u00a0PS&gt; $class = Get-CimClass -ClassName Win32_Process<\/p>\n<p style=\"padding-left: 30px\">PS&gt; $class.CimClassMethods[&#8220;Create&#8221;].Parameters<\/p>\n<p style=\"padding-left: 30px\">Name\u00a0\u00a0\u00a0\u00a0\u00a0 CimType Qualifiers<\/p>\n<p style=\"padding-left: 30px\">&#8212;-\u00a0\u00a0\u00a0\u00a0\u00a0 &#8212;&#8212;- &#8212;&#8212;&#8212;-<\/p>\n<p style=\"padding-left: 30px\">CommandLine\u00a0\u00a0\u00a0 \u00a0String {ID, In, MappingStrings}<\/p>\n<p style=\"padding-left: 30px\">CurrentDirectory\u00a0\u00a0 String {ID, In, MappingStrings}<\/p>\n<p style=\"padding-left: 30px\">ProcessStartupInformation Instance {EmbeddedInstance, ID, In, MappingStrings}<\/p>\n<p style=\"padding-left: 30px\">ProcessId\u00a0\u00a0\u00a0\u00a0 UInt32 {ID, MappingStrings, Out}<\/p>\n<p><strong>Invoke-CimMethod<\/strong> requires a hash table of key value pairs where <strong>Invoke-WmiMethod<\/strong> only takes the parameter values. <strong>Invoke-CimMethod<\/strong> requires a bit more typing but you don\u2019t have worry about the parameter order:<\/p>\n<p style=\"padding-left: 30px\">Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{CommandLine=&#8217;notepad.exe&#8217;; CurrentDirectory=&#8217;C:\\test&#8217;}<\/p>\n<p style=\"padding-left: 30px\">ProcessId ReturnValue PSComputerName<\/p>\n<p style=\"padding-left: 30px\">&#8212;&#8212;&#8212; &#8212;&#8212;&#8212;&#8211; &#8212;&#8212;&#8212;&#8212;&#8211;<\/p>\n<p style=\"padding-left: 30px\">\u00a0\u00a08144\u00a0\u00a0 0<\/p>\n<p>You get the <strong>ProcessId<\/strong> of the new process and the return value. Remember that a return value of 0 is always good when using CIM. If it is any other number, something has gone wrong somewhere.<\/p>\n<p>This next trick isn\u2019t possible with the WMI cmdlets. A frequent task is to view the resources used by a process\u2014in this case, the Kernel mode and user mode times:<\/p>\n<p style=\"padding-left: 30px\">Get-CimInstance -ClassName Win32_Process -Filter &#8220;Name=&#8217;PowerShell.exe'&#8221; | select *time<\/p>\n<p style=\"padding-left: 30px\">KernelModeTime UserModeTime<\/p>\n<p style=\"padding-left: 30px\">&#8212;&#8212;&#8212;&#8212;&#8211; &#8212;&#8212;&#8212;&#8212;<\/p>\n<p style=\"padding-left: 30px\">\u00a0\u00a028906250 \u00a039062500<\/p>\n<p style=\"padding-left: 30px\">You can keep running the code, or try this:<\/p>\n<p style=\"padding-left: 30px\">$x = Get-CimInstance -ClassName Win32_Process -Filter &#8220;Name=&#8217;PowerShell.exe'&#8221;<\/p>\n<p style=\"padding-left: 30px\">$x | select *time<\/p>\n<p style=\"padding-left: 30px\">KernelModeTime UserModeTime<\/p>\n<p style=\"padding-left: 30px\">&#8212;&#8212;&#8212;&#8212;&#8211; &#8212;&#8212;&#8212;&#8212;<\/p>\n<p style=\"padding-left: 30px\">\u00a0\u00a032187500 \u00a042187500<\/p>\n<p style=\"padding-left: 30px\">$x | Get-CimInstance | select *time<\/p>\n<p style=\"padding-left: 30px\">KernelModeTime UserModeTime<\/p>\n<p style=\"padding-left: 30px\">&#8212;&#8212;&#8212;&#8212;&#8211; &#8212;&#8212;&#8212;&#8212;<\/p>\n<p style=\"padding-left: 30px\">\u00a0\u00a033125000 \u00a043281250<\/p>\n<p style=\"padding-left: 30px\">$x | Get-CimInstance | select *time<\/p>\n<p style=\"padding-left: 30px\">KernelModeTime UserModeTime<\/p>\n<p style=\"padding-left: 30px\">&#8212;&#8212;&#8212;&#8212;&#8211; &#8212;&#8212;&#8212;&#8212;<\/p>\n<p style=\"padding-left: 30px\">\u00a0\u00a033281250 \u00a043281250<\/p>\n<p>You can pass the object back through <strong>Get-CimInstance<\/strong> and the values will be refreshed. This could be a good place to use the <strong>-Properties<\/strong> parameter on <strong>Get-CimInstance<\/strong> to restrict the amount of data, but you need to give the property names because wildcard characters aren\u2019t allowed.<\/p>\n<p>I mentioned earlier that the CIM cmdlets use WSMAN to access remote computers. As a consequence, they return inert objects. The WMI class methods aren\u2019t available on the object. Compare the output of <strong>Get-Member<\/strong>:<\/p>\n<p style=\"padding-left: 30px\">PS&gt; Get-WmiObject -Class Win32_Process | Get-Member -MemberType Method<\/p>\n<p style=\"padding-left: 30px\">\u00a0TypeName: System.Management.ManagementObject#root\\cimv2\\Win32_Process<\/p>\n<p style=\"padding-left: 30px\">Name\u00a0\u00a0\u00a0\u00a0 MemberType Definition<\/p>\n<p style=\"padding-left: 30px\">&#8212;-\u00a0\u00a0\u00a0\u00a0 &#8212;&#8212;&#8212;- &#8212;&#8212;&#8212;-<\/p>\n<p style=\"padding-left: 30px\">AttachDebugger\u00a0 \u00a0Method \u00a0System.Management.ManagementBaseObject AttachDebugger()<\/p>\n<p style=\"padding-left: 30px\">GetAvailableVirtualSize Method \u00a0System.Management.ManagementBaseObject GetAvailableVirtualSize()<\/p>\n<p style=\"padding-left: 30px\">GetOwner\u00a0\u00a0\u00a0 Method \u00a0System.Management.ManagementBaseObject GetOwner()<\/p>\n<p style=\"padding-left: 30px\">GetOwnerSid\u00a0\u00a0 \u00a0Method \u00a0System.Management.ManagementBaseObject GetOwnerSid()<\/p>\n<p style=\"padding-left: 30px\">SetPriority\u00a0\u00a0 \u00a0Method \u00a0System.Management.ManagementBaseObject SetPriority(System.Int3&#8230;<\/p>\n<p style=\"padding-left: 30px\">Terminate\u00a0\u00a0\u00a0 Method \u00a0System.Management.ManagementBaseObject Terminate(System.UInt32&#8230;<\/p>\n<p style=\"padding-left: 30px\">PS&gt; Get-CimInstance -ClassName Win32_Process | Get-Member -MemberType Method<\/p>\n<p style=\"padding-left: 30px\">\u00a0TypeName: Microsoft.Management.Infrastructure.CimInstance#root\/cimv2\/Win32_Process<\/p>\n<p style=\"padding-left: 30px\">Name\u00a0\u00a0\u00a0\u00a0 \u00a0MemberType Definition<\/p>\n<p style=\"padding-left: 30px\">&#8212;-\u00a0\u00a0\u00a0\u00a0 \u00a0&#8212;&#8212;&#8212;- &#8212;&#8212;&#8212;-<\/p>\n<p style=\"padding-left: 30px\">Clone\u00a0\u00a0\u00a0\u00a0 \u00a0Method \u00a0System.Object ICloneable.Clone()<\/p>\n<p style=\"padding-left: 30px\">Dispose\u00a0\u00a0\u00a0\u00a0 Method \u00a0void Dispose(), void IDisposable.Dispose()<\/p>\n<p style=\"padding-left: 30px\">Equals\u00a0\u00a0\u00a0\u00a0 Method \u00a0bool Equals(System.Object obj)<\/p>\n<p style=\"padding-left: 30px\">GetCimSessionComputerName Method \u00a0string GetCimSessionComputerName()<\/p>\n<p style=\"padding-left: 30px\">GetCimSessionInstanceId Method \u00a0guid GetCimSessionInstanceId()<\/p>\n<p style=\"padding-left: 30px\">GetHashCode\u00a0\u00a0\u00a0 Method \u00a0int GetHashCode()<\/p>\n<p style=\"padding-left: 30px\">GetObjectData\u00a0\u00a0 \u00a0Method \u00a0void GetObjectData(System.Runtime.Serialization.Serializatio&#8230;<\/p>\n<p style=\"padding-left: 30px\">GetType\u00a0\u00a0\u00a0\u00a0 Method \u00a0type GetType()<\/p>\n<p style=\"padding-left: 30px\">ToString\u00a0\u00a0\u00a0 \u00a0Method \u00a0string ToString()<\/p>\n<p>Notice that the class methods, such as terminate, aren\u2019t present. You can still access them, but you need to modify your technique. Instead of using this line:<\/p>\n<p style=\"padding-left: 30px\">$x = Get-WmiObject -Class Win32_Process -Filter &#8220;Name=&#8217;calculator.exe'&#8221;<\/p>\n<p style=\"padding-left: 30px\">$x.Terminate()<\/p>\n<p>You can use this:<\/p>\n<p style=\"padding-left: 30px\">Get-CimInstance -Class Win32_Process -Filter &#8220;Name=&#8217;calculator.exe'&#8221; | Invoke-CimMethod -MethodName Terminate<\/p>\n<p>Without any doubt, the best feature of the CIM cmdlets is CIM sessions. If you think back to PowerShell remoting for a second, you can send individual commands to a remote machine by using <strong>Invoke-Command<\/strong>, but you have to create and tear down the connection each time, which can add appreciable overhead. If you create a PowerShell remoting session, you can keep the connection open and send multiple commands to the same machines.<\/p>\n<p>CIM sessions work in exactly the same way. You create a session and use it as many times as you need it before pulling it down.<\/p>\n<p style=\"padding-left: 30px\">$cs = New-CimSession -ComputerName RSSURFACEPRO2<\/p>\n<p style=\"padding-left: 30px\">$cs<\/p>\n<p style=\"padding-left: 30px\">Id\u00a0\u00a0 : 1<\/p>\n<p style=\"padding-left: 30px\">Name\u00a0 \u00a0: CimSession1<\/p>\n<p style=\"padding-left: 30px\">InstanceId : b4099322-f548-4e3c-a9c2-65da311627df<\/p>\n<p style=\"padding-left: 30px\">ComputerName : RSSURFACEPRO2<\/p>\n<p style=\"padding-left: 30px\">Protocol \u00a0: WSMAN<\/p>\n<p>If you have machines running Windows PowerShell\u00a02.0, you can\u2019t create a WSMAN-based CIM session because the version of the WSMAN stack was changed in Windows PowerShell 3.0, and you can\u2019t use the PowerShell 2.0 version. In this case, you can drop back to DCOM:<\/p>\n<p style=\"padding-left: 30px\">$opt = New-CimSessionOption -Protocol DCOM<\/p>\n<p style=\"padding-left: 30px\">$csd = New-CimSession -ComputerName RSSURFACEPRO2 -SessionOption $opt<\/p>\n<p style=\"padding-left: 30px\">$csd<\/p>\n<p style=\"padding-left: 30px\">Id\u00a0\u00a0 : 2<\/p>\n<p style=\"padding-left: 30px\">Name\u00a0 \u00a0: CimSession2<\/p>\n<p style=\"padding-left: 30px\">InstanceId : 4aa11e35-33c8-462a-9788-47f5520f7038<\/p>\n<p style=\"padding-left: 30px\">ComputerName : RSSURFACEPRO2<\/p>\n<p style=\"padding-left: 30px\">Protocol \u00a0: DCOM<\/p>\n<p style=\"padding-left: 30px\"><strong>Note<\/strong>\u00a0\u00a0\u00a0If you use a DCOM-based CIM session, you automatically get packet privacy DCOM authentication. This means that you can access classes that need that level of encryption, such as the IIS classes or the cluster classes.<\/p>\n<p>Using a CIM session couldn\u2019t be simpler:<\/p>\n<p style=\"padding-left: 30px\">\u00a0Get-CimInstance -ClassName Win32_Bios -CimSession $cs<\/p>\n<p style=\"padding-left: 30px\">SMBIOSBIOSVersion : 2.05.0250<\/p>\n<p style=\"padding-left: 30px\">Manufacturer \u00a0: American Megatrends Inc.<\/p>\n<p style=\"padding-left: 30px\">Name\u00a0\u00a0 \u00a0: 2.05.0250<\/p>\n<p style=\"padding-left: 30px\">SerialNumber \u00a0: 036685734653<\/p>\n<p style=\"padding-left: 30px\">Version\u00a0\u00a0 : OEMA &#8211; 1072009<\/p>\n<p style=\"padding-left: 30px\">PSComputerName : RSSURFACEPRO2<\/p>\n<p>Also take a look at the CDXML-based cmdlets that were introduced in Windows\u00a08. They all have a <strong>CIMSession<\/strong> parameter.<\/p>\n<p style=\"padding-left: 30px\">Get-Command Get-NetAdapter -Syntax<\/p>\n<p style=\"padding-left: 30px\">Get-NetAdapter [[-Name] &lt;string[]&gt;] [-IncludeHidden] [-Physical] [-CimSession &lt;CimSession[]&gt;] [-ThrottleLimit &lt;int&gt;] [-AsJob] [&lt;CommonParameters&gt;]<\/p>\n<p style=\"padding-left: 30px\">Get-NetAdapter -InterfaceDescription &lt;string[]&gt; [-IncludeHidden] [-Physical] [-CimSession &lt;CimSession[]&gt;] [-ThrottleLimit &lt;int&gt;] [-AsJob] [&lt;CommonParameters&gt;]<\/p>\n<p style=\"padding-left: 30px\">Get-NetAdapter -InterfaceIndex &lt;uint32[]&gt; [-IncludeHidden] [-Physical] [-CimSession &lt;CimSession[]&gt;] [-ThrottleLimit &lt;int&gt;] [-AsJob] [&lt;CommonParameters&gt;]<\/p>\n<p>The CDXML process automatically generates the <strong>CIMSession<\/strong> parameter so you don\u2019t have to do any work to get that functionality. You can also create CIM sessions to work against systems running OMI (the open source CIM server to which Microsoft contributes), meaning you can manage Linux machines and network switches through the CIM cmdlets.<\/p>\n<p>And that\u2019s why I prefer the CIM cmdlets and would recommend that you use them instead of the WMI cmdlets.<\/p>\n<p>Bye for now.<\/p>\n<p>~Richard<\/p>\n<p>Richard Siddaway is based out of the UK and spends his time writing about PowerShell and automating anything and everything. A multi-year year PowerShell MVP, Richard is a prolific blogger, mainly about PowerShell (see <a href=\"http:\/\/msmvps.com\/blogs\/richardsiddaway\/default.aspx\" target=\"_blank\">Richard Siddaway&#8217;s Blog: A PowerShell MVP&#8217;s site<\/a>), and he is a frequent speaker at user groups and PowerShell conferences. He has written a number of PowerShell books: PowerShell in Practice; PowerShell and WMI, PowerShell in Depth (co-author); PowerShell Dive (co-editor), and Learn Active Directory Management in a Month of Lunches, which features lots of PowerShell. He is currently working on the third edition of PowerShell in Action with Bruce Payette of the PowerShell team. All of the books are available from <a href=\"http:\/\/www.manning.com\" target=\"_blank\">www.manning.com<\/a>. Richard has been a director of PowerShell.org since the inception of that organization.<\/p>\n<p>Thanks, Richard!<\/p>\n<p>I invite you to follow me on <a href=\"http:\/\/bit.ly\/scriptingguystwitter\">Twitter<\/a> and <a href=\"http:\/\/bit.ly\/scriptingguysfacebook\" target=\"_blank\">Facebook<\/a>. If you have any questions, send email to me at <a href=\"mailto:scripter@microsoft.com\">scripter@microsoft.com<\/a>, or post your questions on the <a href=\"http:\/\/bit.ly\/scriptingforum\" target=\"_blank\">Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.<\/p>\n<p><strong>Ed Wilson, Microsoft Scripting Guy<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Summary: Richard Siddaway explains the differences between the CIM cmdlets and the WMI cmdlets, and details use cases. \u00a0Hey, Scripting Guy! Should I use the WMI cmdlets or the newer CIM cmdlets? \u2014NR \u00a0Hello NR, Honorary Scripting Guy, Richard Siddaway, here today filling in for my good friend, The Scripting Guy. The simple answer is [&hellip;]<\/p>\n","protected":false},"author":596,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[568],"tags":[385,56,189,45,6],"class_list":["post-76781","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hey-scripting-guy","tag-cim","tag-guest-blogger","tag-richard-siddaway","tag-windows-powershell","tag-wmi"],"acf":[],"blog_post_summary":"<p>Summary: Richard Siddaway explains the differences between the CIM cmdlets and the WMI cmdlets, and details use cases. \u00a0Hey, Scripting Guy! Should I use the WMI cmdlets or the newer CIM cmdlets? \u2014NR \u00a0Hello NR, Honorary Scripting Guy, Richard Siddaway, here today filling in for my good friend, The Scripting Guy. The simple answer is [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/76781","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/596"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=76781"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/76781\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=76781"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=76781"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=76781"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}