SMS: Distinguishing WEPOS From XP

One common problem that arises when using SMS to manage WEPOS machines alongside XP machines is that there is no simple way for SMS to distinguish the two. Whenever a query is run that specifies XP machines, WEPOS machines will find themselves lumped in too. The following is a pair of methods that help you work around this problem.

The first method is the quick-and-dirty method. WEPOS has a few files that are branded specifically for WEPOS. Executable files are picked up by Software Inventory by default, so it makes sense for our query to look through the Software Inventory for any WEPOS-specific executables. For example, one such executable is WEPOS’s explorer.exe. If we decided to look for the WEPOS-branded explorer.exe, we could use the following query:

select distinct sys.Name, sys.OperatingSystemNameandVersion, sys.LastLogonUserName, SMS_G_System_SoftwareFile.FileName, SMS_G_System_SoftwareFile.FileVersion from  SMS_R_System as sys inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = sys.ResourceId where SMS_G_System_SoftwareFile.FileName = "explorer.exe" and SMS_G_System_SoftwareFile.FileVersion = "6.00.2900.2647 (xpsp.050404-1634)"

Notice the FileName and FileVersion portions of this query near the end. The file version has been collected from the file properties dialog.

Great, we’ve got our WEPOS machines now, right? Eh, not quite. This solution isn’t workable in the long run for a couple of reasons. First, there’s no guarantee that the versioning on a WEPOS-specific file will always remain the same. If an update is applied to some of your machines which alters the file your query is looking at, those machines will find themselves dropped out of the query. Second, if you have machines with WEPOS installed to a secondary partition and another OS installed to the first, you could wind up with some false positives.

Why consider this method at all? It’s simple, and it will be reliable if you’ve met the right conditions and only need a temporary solution. Perhaps you need run a one-time install of a batch of updates to several fresh WEPOS installations. This query might be all you need. Just be sure to double check that it’s actually doing what you want it to do.

The second method is a bit heavier, but it is much more reliable. With SMS, it is possible to extend the Hardware Inventory to collect other information about the client. Our silver bullet with regards to our problem is to use an extended Hardware Inventory to collect information in the registry about the WEPOS installation, which is found at HKLM\Software\Microsoft\WEPOS. This is done by editing the SMS_def.mof file.

First, some suggested reading:

https://www.microsoft.com/technet/prodtechnol/sms/sms2003/opsguide/default.mspx?mfr=true

https://www.microsoft.com/technet/archive/sms/sms2/proddocs/sms-regx.mspx?mfr=true

These resources describe how to extend Hardware Inventory in SMS. The first link is to the SMS Operations Guide. In the guide, go to (Chapter 2 > Hardware Inventory Administrative Tasks > Configuring Hardware Inventory Rules) for info on editing the SMS_def.mof file in order to customize what Hardware Inventory data is gathered. Also, (Chapter 3 > Extending Hardware Inventory) will provide further information. The second link is to a whitepaper describing how to edit SMS_def.mof in order to collect information from the registry of the client machine during Hardware Inventory.

Here is one example of an addition to SMS_def.mof that will gather WEPOS registry data.

 

//----------------------// WEPOS Install//----------------------

#pragma namespace ("\\\\.\\root\\cimv2")

[DYNPROPS]class WeposInstall{ [key]string Name = ""; string Value;};

[DYNPROPS]instance of WeposInstall{ Name = "Version"; [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WEPOS|Version"), Dynamic, Provider("RegPropProv")] Value;};

[DYNPROPS]instance of WeposInstall{ Name = "Additional Code Page Support"; [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WEPOS\\Optional Components|Additional Code Page Support"), Dynamic, Provider("RegPropProv")] Value;};

[DYNPROPS]instance of WeposInstall{ Name = "Additional Driver Support"; [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WEPOS\\Optional Components|Additional Driver Support"), Dynamic, Provider("RegPropProv")] Value;};

// And so on...// Add one of these for every optional component install you wish to report:////[DYNPROPS]//instance of WeposInstall//{// Name = "Optional Component Name";// [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WEPOS\\Optional Components|Optional Component Name"),// Dynamic, Provider("RegPropProv")]// Value;//};

#pragma namespace ("\\\\.\\root\\cimv2\\sms")

[ SMS_Report (TRUE), SMS_Group_Name ("WEPOS Install"), SMS_Class_ID ("MICROSOFT|WEPOSInstall|1.0") ]

class WeposInstall : SMS_Class_Template{ [SMS_Report (TRUE), key ] string Name; [SMS_Report (TRUE) ] string Value;};

1. Add the text to the end of your SMS_def.mof file.

2. This new SMS_def.mof needs to be compiled on your client machines before they will report the extended hardware inventory. This can be done by creating and advertising a package to all of your clients which:

a. Contains the new SMS_def.mof file, and

b. Runs a program containing the command “mofcomp.exe SMS_def.mof”

3. After the program runs, trigger a hardware inventory cycle on the clients. When the inventory completes, the clients should be reporting WEPOS install information.

After these steps, resource explorer should show a new entry called “WEPOS Install” (this is true for all clients that compiled the SMS_def.mof, not just WEPOS Installs). This entry will display whether or not a particular WEPOS optional components is installed on the client. Additionally, the WEPOS version number is collected here. If these optional component entries are blank, then the machine you’re looking at is not a WEPOS install.

From here, a simple query checking that the WEPOS Install optional components (or version) are not blank will become your “All WEPOS Systems” query. You might also consider updating your XP queries in order to exclude WEPOS systems. And of course, give this a try in a test environment first!

- Ryan