Exploring Configuration Manager Automation Fundamentals – WMI
Published Jun 26 2023 12:00 AM 2,876 Views
Microsoft

Hello everyone!

 

Welcome back to our blog series on automation 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 ROOT\SMS\Site_[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:\Roles\ConfigMgr. 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 (root\sms\site_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 scripts are not supported under any Microsoft standard support program or service. The sample scripts 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 scripts 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.

5 Comments
Co-Authors
Version history
Last update:
‎Jun 26 2023 12:00 AM
Updated by: