I don’t know about you, but the management acronym thing has caught me a couple of times, so I thought it might be worth an article giving some context around these things.
[There’s now a better version, with more information and accuracy, at PowerShell.org]
CIM stands for Common Information Model. It’s a vendor-neutral, industry standard way of representing management information. It was developed by the DMTF, or Distributed Management Task Force, an industry standards group. CIM defines a number of standardized, vendor-neutral classes to represent information like computer hardware and software. Vendors can extend those classes to add product-specific properties. Initially, DMTF didn’t define any communications protocols that would let you retrieve management information from remote computers.
WMI is Windows Management Instrumentation. This is a Microsoft implementation of early CIM standards. Lacking a protocol definition, Microsoft used DCOM, or Distributed COM, which was based on RPCs, or Remote Procedure Calls. Both were prevalent in Windows NT 4.0, which is where WMI was first introduced.
In Win2012, Microsoft pivoted a bit, and brought WMI in line with the newest and finalized CIM standards, CIMv2. They implemented a standardized, HTTP-based protocol for communicating with remote machines. That protocol is WS-MAN, or Web Services for Management; more formally, it’s WS-Management. This is the same protocol used by PowerShell Remoting (Windows Remote Management, or WinRM). WinRM and CIM aren’t the same thing, but they do use the same underlying communication protocol. At this point, Microsoft started using “CIM” to refer to this newer, standards-compliant version of WMI.
WMI is build around a repository, which is where all of its management information lives. The repository isn’t exactly a database, but you can think of it that way. The information gets into the repository by means of many different providers. A provider is a chunk of code, usually written in C++, that goes out and gets whatever information, and then makes that information available in the repository. So, the more providers you have, the more information WMI can offer.
OMI stands for Open Management Instrumentation. It’s a join effort between Microsoft and The Open Group – it was formerly known as NanoWBEM, or “Nano Web Based Enterprise Management.” The “Nano” part is a clue, telling us that OMI is intended to have a small footprint. So it’s no surprise that companies like Cisco and Arista are porting OMI to run on their network switches – OMI is wee, or can be. In theory, any tool that “speaks” OMI can talk to any OS, hardware device, or other thing that also understands OMI. So, one set of tools to rule them all.
Wait, why not just use CIM and WS-MAN? Those can certainly do the job, but they’re “heavier” technologies, using a lot more in the way of code, so they’re harder to get ported to network devices that have limited memory and processing power. OMI, on the other hand, demands only a quarter megabyte of storage and about a megabyte of memory, well within the capabilities of almost any “smart” device. OMI supports the DMTF standards, just in a lightweight way, and Microsoft released the OMI base code under an Apache 2 license, making it available to anyone who might want to use it.
OMI is essentially a prepackaged, easily portable set of code that gets you CIM and WS-MAN on the cheap.
The downside is that OMI’s provider model is also greatly simplified. Wait, that’s a downside? Well, sorta. It means that providers written for “old WMI” won’t work under OMI. This actually comes into play with Windows Server’s Nano Server install. Nano Server supports the full WMI, because it was too costly for Microsoft to rewrite all the existing providers to be OMI-compliant. OMI, in other words, would only provide a subset of the rich management information that Windows Server has provided for years. And Nano Server isn’t a “constrained” environment in the way a network switch is, so supporting the full “new” WMI stack – including CIM, WS-MAN, etc. – wasn’t a burden.
New providers can be written for Win2012/Win8 and later, and plug into the “new” WMI stack – and also be OMI-compatible. Old, pre-Win2012/Win8 providers continue to work through the “old” WMI stack. Both stacks are accessible through the same WS-MAN protocol, and for backward compatibility can be made available through the old DCOM-based RPC protocol set.
There are some neat implementation details about OMI that don’t affect its operation, but which keep it little. For example, it doesn’t use a repository. Instead, providers generate information on-demand, so that there isn’t a need for the larger storage footprint of a repository. The main coding language is C (not even C++), since that’s a lowest-common-denominator language that can be used for pretty much any platform. The OMI example stack is written in C, making it easier to port and compile almost anywhere.
So in short, you can think of OMI as a “mini” WMI that’s designed to run cross-platform. It uses the same protocols as “new” WMI (WS-MAN), and supports the same data model (CIM). It’s a provider-based model, although it uses the “new” WMI provider model that has a simplified interface. Windows as an OS will likely continue to support the “old” WMI provider model as well, so that older providers don’t have to be rewritten right away. Windows can also support the “old” WMI communication protocol, for backward compatibility, but as tools move to WS-MAN, you’ll get broader coverage that way.