Exploring Configuration Manager Automation Fundamentals – WMI

Hello everyone!

Welcome back to our blog series on and API capabilities within Microsoft Configuration Manager. In our previous post, we delved into the SMS Provider, the WMI interface that enables interaction with an MECM site. In this installment, we will take a closer look at Windows Management Instrumentation (WMI) and its significance in MECM.

Recap – The SMS Provider is our WMI-Interface to interact with a MECM-Site. With the Installation of an MECM-Client we also have WMI-Namespaces to gather information or automate Tasks:

msfoxworks_1-1686593619037.png

Building-Blocks

Before we dive into the details of WMI and its usage, let's familiarize ourselves with its building blocks.

The following Illustration gives a High-Level-Overview:

msfoxworks_2-1686593619041.png

In WMI, we navigate through namespaces, such as the SMS Provider ROOTSMSSite_[SiteCode]. Within these namespaces, we encounter classes, which represent the objects we interact with and sometimes act as type definitions. As an example, let's consider the SMS_Site class. Within a class, we find instances, such as SMS_Site.SiteCode=”LAB,” which provide properties holding specific values. In our illustration, the InstallDir property holds the value D:RolesConfigMgr. Additionally, classes may offer methods, which can be executed at either the class level or instance level. For instance, the ImportMachineEntry method.

Lazy Properties / Static Methods

In Microsoft Configuration Manager, certain WMI classes utilize lazy properties for improved performance. Lazy properties display only the necessary information, and you can retrieve the entire object using a Get-Method or an implemented provider method. When using the WMI Explorer, you can identify classes employing lazy properties by a specific column indicator.

msfoxworks_3-1686593619041.png

In our example, we explore the SMS_SiteControlFile class, which contains five properties when displayed,

msfoxworks_4-1686593619043.png

but the instance definition specifies six properties, with SCFData being a lazy property.

msfoxworks_5-1686593619044.png

Static methods, on the other hand, apply to WMI classes and not specific instances.

msfoxworks_6-1686593619046.png

Understanding this concept is crucial, especially for working with the Administration Service. Let's consider an example using the SMS_SiteControlFile class mentioned earlier.

We utilize a native WMI call in PowerShell, defining a variable to store the information, specifying the namespace (rootsmssite_fox) and the target class (SMS_SiteControlFile). Then, we employ the WMI built-in method GetInstances().

msfoxworks_7-1686593619048.png

The result mirrors what we saw in the WMI Explorer, with SCFData being empty because it is a lazy property.

In this case, we utilize the static method GetCurrentVersion to retrieve SCFData by providing the SiteCode parameter.

msfoxworks_8-1686593619055.png

Associations between WMI Classes

In Microsoft Configuration Manager, certain WMI class properties may refer to different WMI classes. For instance, when dealing with machine variables in the context of a task sequence deployment, we require two WMI classes: SMS_MachineSettings and SMS_MachineVariable.

SMS_MachineSettings

The SMS_MachineSettings class includes instances for records with assigned variables, and its primary key is the ResourceID. This class does not provide a method, so we must create a new instance for new objects.

msfoxworks_9-1686593619056.png

By using the Get-Member cmdlet or WBEMTest.exe, we can examine the type of the property, which reveals the WMI class it references.

msfoxworks_10-1686593619060.png

SMS_MachineVariable

On the other hand, the SMS_MachineVariable class does not have instances or a method to create a variable. However, we need to create an instance to obtain the specific type for the SMS Provider.

msfoxworks_11-1686593619069.png

Once we create the instance in SMS_MachineVariable, we can set the properties we desire.

msfoxworks_12-1686593619072.png

msfoxworks_13-1686593619074.png

Depending on the scenario, we can add or replace machine variables using the object created with SMS_MachineVariable and the MachineVariable property of the SMS_MachineSettings class for a specific ResourceID.

msfoxworks_14-1686593619075.png

Conclusion:

In this blog post, we have covered important fundamentals of WMI and explored specific aspects within the context of Microsoft Configuration Manager. Familiarizing yourself with WMI is crucial since it serves as the interface used with the SMS Provider. In our next blog, we will delve into Configuration Manager PowerShell cmdlets, which heavily leverage WMI. Stay tuned for more insights!

Disclaimer
The sample are not supported under any Microsoft standard support program or service. The sample are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

 

This article was originally published by Microsoft's Azure Blog. You can find the original article here.