Petri Newsletter Sign-up
Office 365 Insider

Here at Petri.com, we get IT — and so can you. Subscribe today to stay informed and knowledgeable regarding the latest on IT.

    See All Petri Newsletters

    What Is the Difference Between WMI and CIM?

    Posted on by Russell Smith in Windows Server

    Most Windows administrators are familiar with Windows Management Instrumentation (WMI), which is Microsoft’s implementation of the Common Information Model (CIM). CIM is a standard from DMTF.org (Distributed Management Task Force) that provides a common definition of management information for systems, networks, applications, and services.

    Without going into too much detail, the standard includes a Specification, Schema, and Metamodel that allow vendors to provide a standard way to manage their products. CIM includes some standard classes that represent information like computer hardware and software. CIM classes can be extended so that vendors may add properties relevant to their products.

    WMI History

    WMI is Microsoft’s implementation of CIM and it first appeared in Windows NT 4.0. Because Microsoft was an early adopter, DCOM was used for remote management because there was no other defined standard at the time. DCOM stands for Distributed COM and it uses Remote Procedure Calls (RPCs) to make remote connections, which is fine if all devices are on the same network but once they are separated by NAT routers and firewalls, remote connectivity becomes a challenge.

    Windows Server 2012 and Windows 8 saw Microsoft make some changes to WMI by aligning it with CIMv2 and moving to WS-MAN for remote connections. Because WS-MAN is a HTTP-based protocol, it is more firewall friendly than DCOM. Although it’s worth noting that the updated WMI stack can be accessed using DCOM for backwards compatibility.

    Microsoft Deprecates WMI Commands

    Microsoft has since deprecated the WMI commands in Windows in favor of their CIM counterparts. For example, if you are using PowerShell for management, you should use the CIM cmdlets and not the WMI cmdlets.

    Because the WMI cmdlets are deprecated, Microsoft won’t develop them any further. PowerShell Core doesn’t even include the WMI cmdlets, so you must use CIM. And because CIM uses WS-MAN for remote access, connecting to remote systems is easier. The command below uses the Get-WmiObject PowerShell cmdlet to get information about the operating system:


    In PowerShell Core, you need to use CIM:

    Open Management Infrastructure (OMI)

    But the story doesn’t end there. While CIM can be used as a management model for any kind of device, it can be difficult to implement, and it is too large for mobile and embedded devices. As more IoT devices get connected to the cloud, a more flexible solution was needed.

    In partnership with The Open Group, Microsoft developed a new open source solution called Open Management Infrastructure. OMI is publicly available and can be used for standards-based management in any device for free.

    OMI is a portable, small footprint, and high performance CIM Object Manager that provides DMTF standards support, remote manageability using WS-MAN, API compatibility with WMI, and supports CIM IDEs, like the one in Visual Studio. OMI’s base size is just 250KB and uses 1MB of RAM.

    Because OMI isn’t full CIM, some old providers won’t work with it. Providers written to work with Windows 2012 and Windows 8 or later should also work with OMI.

    BECOME A PETRI MEMBER:

    Don't have a login but want to join the conversation? Sign up for a Petri Account

    Register