In my last post I talked about how to delete unwanted WMI classes using SMS 2003/Configuration Manager hardware inventory. In this post, I'll flip the coin to talk about how to ensure that WMI data class information is not lost--or at least not lost for long.
Every time a client computer's operating system starts, it checks the integrity of the WMI repository. If a client's WMI repository has become corrupted or somehow been damaged/deleted, the WMI repository is automatically rebuilt. The bad thing about this, from an SMS 2003 administrator's point of view at least, is that all that hard work you've put into modifying hardware inventory using custom data classes has now been lost. In order for clients to once again begin reporting the custom data class information, the client has to recompile a custom MOF file to re-create the custom data classes (not such a huge deal with Configuration Manager sites as the Configuration.mof is automatically compiled during client policy evaluation--including SMS 2003 clients assigned to Configuration Manager sites by the way).
So there's the background, here are the details. Each computer maintains a list of MOF files that it knows must be automatically re-compiled when the WMI repository is rebuilt. If you're curious, the list of autorecover MOF files stored in the registry can be viewed at: HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\autorecover mofs.
It's pretty easy to get your customized MOF file into this select group of files, just add the following line to the top your customized MOF file and WMI will add it to the list of autorecover MOF files in the registry:
#Pragma Autorecover
If that line is not present, and you are MOFCOMP'ing your MOF on a Windows Vista machine you will most likely recieve the following message:
WARNING: File <YourMOF>.mof does not contain #PRAGMA AUTORECOVER.
If the WMI repository is rebuilt in the future, the contents of this MOF file
will not be included in the new WMI repository.
To include this MOF file when the WMI repository is automatically reconstructed
place the #PRAGMA AUTORECOVER statement on the first line of the MOF file.
Done!
That's just Vista's way of telling you to read this post...OK not really. It is however, a reminder that if you want this WMI information to be rebuilt along with the other MOF files on 'the list' then you need to use the autorecover statement. If you are manually compiling the customized MOF file, just add the autorecover command to your MOFCOMP command like so:
MOFCOMP -Autorecover <YourMof>.MOF
Sounds great right?! Now you'll never lose that data class customization...of course there's a catch. WMI cannot recover MOF files located on a remote computer. When you use the autorecover command, MOFCOMP not only adds the name of the MOF file to autorecover, but it also takes note of the location of the MOF file. If you are going to use the autorecover command, you probably don't want to store the file in a temporary directory or somewhere that a user is going to inadvertantly delete it. Following WMI's lead, you can store the custom MOF file in the %WINDIR%\System32\WBEM directory before running MOFCOMP -Autorecover on it. You don't have to put it there, but just make sure that wherever you put it, it won't be deleted.