Blog
MSI Windows Managed Instrumentation (WMI)
What is WMI?
MSI Windows Managed Instrumentation (WMI) is acronym for Windows Management Instrumentation. WMI is a new management technology allowing scripts to monitor and control managed resources throughout the network. Resources include hard drives, file systems, operating system settings, processes, services, shares, registry settings, networking components, event logs, users, and groups. WMI is built into clients with Windows 2000 or above, and can be installed on any other 32-bit Windows client.
When WMI is used? (MSI Windows Managed Instrumentation (WMI) )
WMI is the Microsoft implementation of the Common Information Model (CIM) initiative developed by the Distributed Management Task Force (DMTF). The DMTF is an association of various computer and software companies (e.g. Novell, Microsoft, Cisco, HP, etc.) developing standards in the Enterprise management space. As large Enterprises have many computers with many software environments, managing these diverse environments can be a real challenge. In order to unify the management techniques for the sake of simplicity, the DMTF defined CIM to represent real-world manageable entities in a unified way. The CIM object model is an object data model using terms and semantic that is unique to all constructors and software developers.
Based on the CIM model, WMI includes real-world manageable components, available from the DMTF standards with some specific extensions that represent the various Windows components. Moreover, WMI exposes a collection of COM scriptable objects that allow various applications to take advantage of the management information. WMI is the Microsoft implementation of CIM.
As part of the installation process, most of the Microsoft applications available today (e.g. SQL 2000, Exchange 2000/2003, Office 2000/XP/2003, Internet Explorer 6.0, Host Integration Server, Automated Deployment Services) extend the standard CIM object model to add the representation of their manageable entities in the CIM repository. This representation is called a class, and it exposes information through properties and allows the execution of some actions via methods. The access to the manageable entities is made via a software component, called a “provider” which is nothing else than a DLL implementing a COM object written in C/C++.
Because a provider is designed to access some specific management information, the CIM repository is also logically divided into several areas called a namespace. Each namespace contains a set of providers with their related classes specific to a management area (i.e. RootDirectoryDAP for active directory, ROOT SNMP for SNMP information or Root Microsoft IIS version 2 for internet information server information).
To locate the huge amount of management information available from the CIM repository, WMI comes with a SQL-like language called the WMI query language (WQL). Briefly, WQL is a subset of the standard American National Standards Institute Structured Query Language (ANSI SQL) with minor semantic changes. A basic WQL query remains fairly understandable for people with a basic SQL knowledge. Therefore, WQL is dedicated to WMI and is designed to perform queries against the CIM repository to retrieve information or get event notifications.
This briefly describes the WMI implementation and some of the terms often used when dealing with WMI.
Sample script:
This Script fetches the data from AD and populates the same in excel sheet:
Dim ObjWb
Dim ObjExcel
Dim x, zz
Set objRoot = GetObject(“LDAP://RootDSE”)
strDNC = objRoot.Get(“DefaultNamingContext”)
Set objDomain = GetObject(“LDAP://” & strDNC) ” Bind to the top of the Domain using LDAP using ROotDSE
Call ExcelSetup(“Sheet1″) ” Sub to make Excel Document
x = 1
Call enummembers(objDomain)
Sub enumMembers(objDomain)
On Error Resume Next
Dim Secondary(20) ” Variable to store the Array of 2ndary email alias”s
For Each objMember In objDomain ” go through the collection
If ObjMember.Class = “user” Then ” if not User object, move on.
x = x +1 ” counter used to increment the cells in Excel
objwb.Cells(x, 1).Value = objMember.Class
” AD properties are set to variables so if needed one could do Null checks or add if/then”s to this code
” this was done so the script could be modified easier.
SamAccountName = ObjMember.samAccountName
Cn = ObjMember.CN
FirstName = objMember.GivenName
LastName = objMember.sn
initials = objMember.initials
Descrip = objMember.description
Office = objMember.physicalDeliveryOfficeName
Telephone = objMember.telephonenumber
Email = objMember.mail
WebPage = objMember.wwwHomePage
Addr1 = objMember.streetAddress
City = objMember.l
State = objMember.st
ZipCode = objMember.postalCode
Title = ObjMember.Title
Department = objMember.Department
Company = objMember.Company
Manager = ObjMember.Manager
Profile = objMember.profilePath
LoginScript = objMember.scriptpath
HomeDirectory = ObjMember.HomeDirectory
HomeDrive = ObjMember.homeDrive
AdsPath = Objmember.Adspath
LastLogin = objMember.LastLogin
zz = 1 ” Counter for array of 2ndary email addresses
For each email in ObjMember.proxyAddresses
If Left (email,5) = “SMTP:” Then
Primary = Mid (email,6) ” if SMTP is all caps, then it”s the Primary
ElseIf Left (email,5) = “smtp:” Then
Secondary(zz) = Mid (email,6) ” load the list of 2ndary SMTP emails into Array.
zz = zz + 1
End If
Next
” Write the values to Excel, using the X counter to increment the rows.
objwb.Cells(x, 2).Value = SamAccountName
objwb.Cells(x, 3).Value = CN
objwb.Cells(x, 4).Value = FirstName
objwb.Cells(x, 5).Value = LastName
objwb.Cells(x, 6).Value = Initials
objwb.Cells(x, 7).Value = Descrip
objwb.Cells(x, 8).Value = Office
objwb.Cells(x, 9).Value = Telephone
objwb.Cells(x, 10).Value = Email
objwb.Cells(x, 11).Value = WebPage
objwb.Cells(x, 12).Value = Addr1
objwb.Cells(x, 13).Value = City
objwb.Cells(x, 14).Value = State
objwb.Cells(x, 15).Value = ZipCode
objwb.Cells(x, 16).Value = Title
objwb.Cells(x, 17).Value = Department
objwb.Cells(x, 18).Value = Company
objwb.Cells(x, 19).Value = Manager
objwb.Cells(x, 20).Value = Profile
objwb.Cells(x, 21).Value = LoginScript
objwb.Cells(x, 22).Value = HomeDirectory
objwb.Cells(x, 23).Value = HomeDrive
objwb.Cells(x, 24).Value = Adspath
objwb.Cells(x, 25).Value = LastLogin
objwb.Cells(x,26).Value = Primary
” Write out the Array for the 2ndary email addresses.
For ll = 1 To 20
objwb.Cells(x,26+ll).Value = Secondary(ll)
Next
” Blank out Variables in case the next object doesn”t have a value for the property
SamAccountName = “-“
Cn = “-“
FirstName = “-“
LastName = “-“
initials = “-“
Descrip = “-“
Office = “-“
Telephone = “-“
Email = “-“
WebPage = “-“
Addr1 = “-“
City = “-“
State = “-“
ZipCode = “-“
Title = “-“
Department = “-“
Company = “-“
Manager = “-“
Profile = “-“
LoginScript = “-“
HomeDirectory = “-“
HomeDrive = “-“
Primary = “-“
For ll = 1 To 20
Secondary(ll) = “”
Next
End If
” If the AD enumeration runs into an OU object, call the Sub again to itinerate
If objMember.Class = “organizationalUnit” or OBjMember.Class = “container” Then
enumMembers (objMember)
End If
Next
End Sub
Sub ExcelSetup(shtName) ” This sub creates an Excel worksheet and adds Column heads to the 1st row
Set objExcel = CreateObject(“Excel.Application”)
Set objwb = objExcel.Workbooks.Add
Set objwb = objExcel.ActiveWorkbook.Worksheets(shtName)
Objwb.Name = “Active Directory Users” ” name the sheet
objwb.Activate
objExcel.Visible = True
objwb.Cells(1, 2).Value = “SamAccountName”
objwb.Cells(1, 3).Value = “CN”
objwb.Cells(1, 4).Value = “FirstName”
objwb.Cells(1, 5).Value = “LastName”
objwb.Cells(1, 6).Value = “Initials”
objwb.Cells(1, 7).Value = “Descrip”
objwb.Cells(1, 8).Value = “Office”
objwb.Cells(1, 9).Value = “Telephone”
objwb.Cells(1, 10).Value = “Email”
objwb.Cells(1, 11).Value = “WebPage”
objwb.Cells(1, 12).Value = “Addr1”
objwb.Cells(1, 13).Value = “City”
objwb.Cells(1, 14).Value = “State”
objwb.Cells(1, 15).Value = “ZipCode”
objwb.Cells(1, 16).Value = “Title”
objwb.Cells(1, 17).Value = “Department”
objwb.Cells(1, 18).Value = “Company”
objwb.Cells(1, 19).Value = “Manager”
objwb.Cells(1, 20).Value = “Profile”
objwb.Cells(1, 21).Value = “LoginScript”
objwb.Cells(1, 22).Value = “HomeDirectory”
objwb.Cells(1, 23).Value = “HomeDrive”
objwb.Cells(1, 24).Value = “Adspath”
objwb.Cells(1, 25).Value = “LastLogin”
objwb.Cells(1, 26).Value = “Primary SMTP”
End Sub
MsgBox “Done” ” show that script is complete
What is the overall development process? (MSI Windows Managed Instrumentation (WMI) )
Because WMI abstracts the manageable entities with CIM and a collection of providers, the development of a provider implies several steps. Although there are 4 major steps with some sub-steps, each of them taken separately are quite easy to execute. These can be summarized as follows:
Create the manageable entity model
Define a model
Implement the model
Create the WMI Provider
Determines the provider type to implement
Determines the hosting model of the provider
Create the provider template with the ATL wizard
Implement the code logic in the provider
Register the provider with WMI and the system
Test the provider
Create consumer sample codes
Why is it important to write a WMI provider for our customers?
Since the release of the first WMI implementation during the Windows NT 4.0 SP4 era (as an out-of-band download), Microsoft never stopped to add WMI providers in Windows. Under Windows NT 4.0, Microsoft had roughly 15 WMI providers available once WMI was installed. When Windows 2000 was released, customers discovered 29 WMI providers part of the Operating System installation. More recently, with the release of Windows Server 2003, Microsoft included in the platform more than 80 WMI providers. This has been a sign for many customers that WMI became at Microsoft the “ubiquitous” management layer of Windows, even if this commitment has never been explicit from Microsoft. This is the net result of the on-going work made during the last Windows release.
During these last years, due to a constant increasing exposure of management data through WMI in Windows, more and more people in the field started to develop scripts and automation procedures based on WMI. Beyond the scripting needs, most leading management software in the world, such as MOM, SMS, ADS, HP OpenView for Windows (HPOV), BMC, CA, or Kaseya are WMI-enabled and capable to consume and provide WMI information through various User Interfaces. This enables administrators and operators, not capable to script or program on top of WMI, to enjoy the benefits of WMI without even learning about WMI. However, if they want to, because WMI is scriptable, it gives the opportunity to any of them to consume WMI information from scripts or from any Enterprise Management software that is WMI-aware.
These trends have made WMI very popular among our customers management communities. Tons of references and publications exist on the Internet about WMI. At the same time, this story increased our customer expectations because the management communities leveraging WMI today expect our management layer to be predictable and consistent through WMI for more and more Windows manageable components. This also means that our customers expect to leverage the knowledge and investment made in WMI during these past years to improve, pursue and achieve their business goals at lower cost.
What WMI offers for free out-of-the box? (MSI Windows Managed Instrumentation (WMI) )
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces: Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out-of-the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate and test a scripting model as it is already available from WMI.
.NET Management interfaces: Because the System Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all .NET applications independently of the language used (e.g. C#, VB.NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the .NET Framework as this support is already available from WMI for free.
C/C++ COM/DCOM programming interfaces: Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (Scripting and .NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre-defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes life very easy for developers to be familiar with the scripting experience.
Remoting capabilities over DCOM and SOAP: More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS-Management initiative lead by Microsoft, INTEL, SUN and DELL. This initiative allows to run any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The big advantage for the WMI provider developer is when he exposes all his features through WMI, WS-Management can in turn consume that information as well (embedded objects in WMI instances are not supported in R2. It is however a target for Longhorn). All the layering to WS-Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS-Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine.
Support for Queries: WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. That implies that one get the WQL query support for free.
Eventing capabilities: WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related call-backs, is part of the WMI COM/DCOM and automation interfaces. Any one writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes.
Code template generator: To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre-defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic.
Predictability: Predictability is an important concern for our customers because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this causes more pain to our customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, .NET) whatever the manageable entity is.
Protect existing customer investments: Protecting customers and partners investment motivates customers to invest in technologies. Microsoft invested a lot of these past years in writing WMI providers (more than 80 in Windows Server 2003), so customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, it is a common sense for them to continue to exploit these capabilities instead of having to use a (new) set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in-house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology.
Provide a logical and unified administration model: As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF. The CIM class-based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model (For instance, INTEL is doing this for some their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Last but not least, WMI XP SP2 is leveraging WMI to get information status from anti-virus software and firewall).
What do one need to work with WMI?
From a development perspective, one must run Windows 2000, Windows XP or Windows Server 2003. Visual Studio 2003 or 2005 must be installed on the machine. The latest service pack and fixes are obviously recommended. The Windows machine doesn’t have to be part of any domain unless the provider one plan to develop requires to access information in the domain.
Some WMI tools can also be very useful during the design and development phases. These tools are:
The MOF compiler (MOFCOMP.Exe): The Managed Object Format (MOF) compiler parses a file containing Managed Object Format statements and adds the classes and class instances defined in the file to the CIM repository. The MOF format is a specific syntax to define CIM class representation in an ASCII file (e.g. MIB are to SNMP such as MOF files are to CIM). MOFCOMP.Exe is included in every WMI installation. Every definition existing in the CIM repository is initially defined in a MOF file. MOF files are located in %SystemRoot%\system32\wbem. During the WMI setup, they are loaded in the CIM repository.
The WMI Administrative Tools: The WMI Administrative Tools are made of four tools: WMI CIM Studio, WMI Object Browser, WMI Event Registration and WMI Event viewer. The most important tool for a WMI provider development is WMI CIM Studio as it helps in the initial WMI class creation in the CIM repository. It uses a web interface to display information and relies on a collection of ActiveX components installed on the system when it runs for the first time. WMI CIM Studio provides the ability to:
Connect to a chosen system and browse the CIM repository in any namespace available.
Search for classes by their name, by their descriptions or by property names.
Review the properties, methods and associations related to a given class.
See the instances available for a given class of the examined system.
Perform Queries in the WQL language.
Generate a MOF file based on selected classes.
Compile a MOF file to load it in the CIM repository.
Winmgmt.Exe: WinMgmt.Exe is not a tool; it is the executable that implements the WMI Core service. Under Windows NT, Windows 2000 and Windows Server 2003, WMI runs as a service. On computers running Windows 98, Windows 95 or Windows Millennium, WMI runs as an application. Under Windows NT, Windows 2000, Windows XP or Windows Server 2003, it is also possible to run this executable as an application, in which case, the executable runs in the current user context. For this the WMI service must be stopped first. The executable supports some switches that can be useful when starting WMI as a service or as an application. WMI provider developers who may want to debug their providers essentially need to run the WMI service as an application.
WBEMTEST.Exe: WBEMTEST.Exe is a WMI tester tool, which is delivered in standard with WMI. This tool allows an administrator or a developer to perform most of the tasks from a graphical interface that WMI provides at the API level. Although available under Windows NT, Windows 2000, Windows XP and Windows Server 2003, this tool is not officially supported by Microsoft. Actually, the usage of this tool is not easy at first glance unless one are used to the WMI COM API and the WMI concepts. With WBEMTEST, one can:
Enumerate, open, create and delete classes.
Enumerate, open, create and delete instances of classes.
Select a namespace.
Perform data and event queries.
Execute methods associated to classes or instances.
Execute every WMI operation asynchronously, synchronously or semi-asynchronously.
The WMI command line tool (WMIC): WMIC is a command-line tool designed to ease WMI information retrieval about a system by using some simple keywords (aliases). WMIC.Exe is only available under Windows XP Professional and Windows Server 2003. It is not included in other Windows platforms. By typing “WMIC /?” from the command-line, one can obtain a complete list of the switches and reserved keywords available. By typing “WMIC switch-name /?” one can gather more information about the switch usage.
WBEMDUMP.Exe: WBEMDUMP is a tool delivered with the Platform SDK. This command line tool comes with its own Visual C++ project. Basically, the tool can show the CIM repository classes, instances, or both. It is possible to retrieve the same information as that retrieved with WMIC. WBEMDUMP.Exe requires more specific knowledge about WMI, as it doesn’t abstract WMI as WMIC. However, it runs under Windows NT 4.0 and Windows 2000. It is also possible to execute methods exposed by classes or instances. Even if it is not a standard WMI tool delivered with the system installation, this tool can be quite useful for exploring the CIM repository and WMI features.
Reference Terms of WMI:
ADSI – This is an acronym for Active Directory Service Interface. It’s a library of routines that provide an interface to various directories, such as the Windows NT user account database and the Windows 2000 Active Directory. ADSI can be used in VBScript, Visual Basic, and Visual Basic for Applications, and other environments. Besides NT and Active Directory, ADSI also supports Novell bindery, Novell NDS, Internet Information Server (IIS), and other LDAP compliant directories.
LDAP – This stands for Lightweight Directory Access Protocol. A language based on the X.500 directory standard that allows clients and servers to communicate. The LDAP provider allows access to the hierarchical structure of Active directory. However, the Windows NT user account database is not LDAP compliant.
WinNT – Windows NT namespace provider, supporting the Windows NT user account database. The WinNT provider can also be used to access Active Directory, but it exposes it as a flat namespace.
WSH – Windows Script Host, an ActiveX scripting host providing an environment for the execution of scripts using one of several scripting engines or languages, such as VBScript. WSH is included with Windows 2000 and Windows XP. It can be installed on any Windows 32-bit client. WSH has two applications, Cscript and Wscript. Cscript executes scripts in a command line environment, while Wscript executes scripts in a GUI environment.
VBScript – Visual Basic Script Edition, a subset of the Visual Basic language. Programs written in VBScript are saved in files with the .VBS extension
Active Directory – It is a Microsoft’s directory database for Windows 2000 networks. It stores information about resources on the network and provides a means of centrally organizing, managing, and controlling access to the resources.
ADO – Acronym for ActiveX Data Objects. ADSI can act as an OLE-DB provider that allows database queries of Active Directory using ADO. Searches using ADO are only allowed in the LDAP namespace.
WMI – Acronym for Windows Management Instrumentation. WMI is a new management technology allowing scripts to monitor and control managed resources throughout the network. Resources include hard drives, file systems, operating system settings, processes, services, shares, registry settings, networking components, event logs, users, and groups. WMI is built into clients with Windows 2000 or above, and can be installed on any other 32-bit Windows client.
AdsPath – A string that specifies an object in Active Directory or the NT SAM account database. In Active Directory, the AdsPath includes the provider (either “LDAP://” or “WinNT://”) and the path to the object in Active Directory. Using the LDAP provider, this path is the Distinguished Name of the object.
Distinguished Name – It is a string that uniquely identifies an object in Active Directory. Used by the LDAP provider to bind to the object. The Distinguished Name, sometimes abbreviated DN, specifies the name of the object (the Relative Distinguished Name) and the location of the object in the hierarchical structure of Active Directory.
Relative Distinguished Name – The name of an object in Active Directory relative to it’s location in the hierarchical structure. The Relative Distinguished Name, sometimes abbreviated RDN, will be the lowest level component of the Distinguished Name. The RDN must be unique in the container (or OU), while the DN will be unique in the forest.