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:
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:
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.
In our example, we explore the SMS_SiteControlFile class, which contains five properties when displayed,
but the instance definition specifies six properties, with SCFData being a lazy property.
Static methods, on the other hand, apply to WMI classes and not specific instances.
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().
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.
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.
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.
By using the Get-Member cmdlet or WBEMTest.exe, we can examine the type of the property, which reveals the WMI class it references.
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.
Once we create the instance in SMS_MachineVariable, we can set the properties we desire.
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.
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!
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.