I wanted a clean and simple way to prevent group policies applying during an automated build process. This is because it can potentially cause some of the components of the build process to fail. One of the last tasks to run on all servers built using my unattended build method will stamp the registry with the build version and date, so I was pretty eager to implement a WMI filter that would read the build version to determine whether or not the policy should apply. Easier said than done! I found a great article on WMI Filters that went into the requirements and gave an example, but I found that I still needed to do a considerable amount of research in order for everything to start making sense.
Copy the below MOF file to…
%SystemRoot%\System32\wbem
Compile it by typing…
Mofcomp -class:forceupdate BuildInfo.mof
Test it by typing…
Wmic path BuildInfo WHERE (BuildVersion Like “2.%”) get BuildVersion
This will return the build number from the registry for all 2.x builds
WMI Filter will be…
select * from BuildInfo where (BuildVersion Like “2.%”)
This will return True for all version 2.x builds
Please review the MOF file below. It is fully documented, and will help anyone who wants to implement the same process.
Enjoy!
///////////////////////////////////////////////////////////////////////////
// BuildInfo MOF File
// This MOF File makes it possible to query for the server build version
// and date with a Group Policy WMI filter. It’s specifically handy for
// Citrix XenApp builds, as it prevents the GPO from applying during a
// server build that potentially cause some of the components of the build
// process to fail.
//
// Release 1.0
// Written by Jeremy@jhouseconsulting.com.au on 6th May 2009.
//
// Copy it to…
// %SystemRoot%\System32\wbem
//
// Compile it by typing…
// mofcomp.exe -class:forceupdate %SystemRoot%\System32\wbem\BuildInfo.mof
//
// Test it by typing…
// Wmic path BuildInfo WHERE (BuildVersion Like “2.%”) get BuildVersion
// This will return the build number from the registry for all 2.x builds
//
// WMI Filter will be…
// select * from BuildInfo where (BuildVersion Like “2.%”)
// This will return True for all version 2.x builds
//
// Reference: http://grouppolicy.editme.com/WMIFilters
///////////////////////////////////////////////////////////////////////////
// First we must register the System Registry Provider by declaring and
// creating the Property Provider used to enumerate registry data and
// values from specific registry locations.
// It is important to understand that if the data that you want to report
// is contained within several subkeys in a registry location, you must
// use an Instance Provider instead.
#pragma namespace (“\\\\.\\root\\cimv2″)
instance of __Win32Provider as $PropProv
{
Name=”RegPropProv”;
Clsid=”{72967901-68EC-11d0-B729-00AA0062CBB7}”;
};
instance of __PropertyProviderRegistration
{
Provider=$PropProv;
SupportsPut = TRUE;
SupportsGet = TRUE;
};
// Now we define the registry Class With Qualifiers
#pragma namespace (“\\\\.\\root\\cimv2″)
[DYNPROPS]
class BuildInfo
{
[key]string Keyname=””;
string BuildVersion;
string BuildDate;
};
[DYNPROPS]
instance of BuildInfo
{
KeyName=”BuildInfo”;
[PropertyContext(“Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Datacom\\Build|Version”), Dynamic, Provider(“RegPropProv”)] BuildVersion;
[PropertyContext(“Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Datacom\\Build|Build Date”), Dynamic, Provider(“RegPropProv”)] BuildDate;
};
///////////////////////////////////////////////////////////////////////////
Jeremy Saunders
Latest posts by Jeremy Saunders (see all)
- Best Practice for the Active Setup StubPath value - September 25, 2023
- User Profile Migration Strategy and PowerShell Script with a User Interface - August 28, 2023
- Cold Starting and/or Hydrating Your Applications To Improve Their Startup Times - June 27, 2023