Are you *sure* you need to rebuild the WMI Repository?

To continue the subject of WMI troubleshooting: I am always frustrated at the quick, shotgun method of rebuilding the WMI repository as a rote, rudimentary troubleshooting step. This is very dangerous and risky. Rebuilding the WMI repository manually has resulted in some 3rd party products not working until reinstallation – IN SOME CASES – even this does not work. This is especially a shame since it may not always be necessary and even if it were – if there is severe WMI corruption, it may almost be better to “in-place” upgrade the OS or do a complete reinstallation of the operating system and software as incomplete repositories can yield lingering problems.

Before you go down that road, ask yourself the following:

1.) Have I properly troubleshot the error to the point that the only possible source could be corruption?

2.) Have I researched and installed all of the latest service packs and hotfixes related to WMI? (Hint: Go to http://support.microsoft.com and search WMI, hotfix, and <OS>)

3.) Have I gone through the rudimentary WMI checklist so I don’t get burned by simple things such as firewall rules? (Hint – https://madvirtualizer.wordpress.com/2014/01/22/the-importance-of-troubleshooting-wmi-part-2/)

4.) Have I ran WMIDiag (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=7684)

and received really bizarre errors like 0x80041010 WBEM_E_INVALID_CLASS or does it fail to connect at all?

5.) Do you fail to connect to WMI Control from Computer Management?

If you answered “yes” to 4 out of the 5 above, here are some steps you can do to safely troubleshoot the WMI repository using “soft” actions:

Instructions for Operating Systems Prior to Windows Vista (XP/2003)

1. Open the Services MSC console and stop the Windows Management Instrumentation service.

2. You will be prompted to stop dependent services. Click “Yes” on the prompt.

3. Once the service is stopped, browse to %SystemRoot%\System32\wbem. Rename the Repository folder to Repository.old.

4. Once the folder has been renamed, restart the WMI and dependent services in the following order:

Windows Management Instrumentation

SMS Agent Host (If SCCM/SMS is installed)

Windows Firewall / Internet Connection Sharing (ICS)

Any other services that were detected as dependencies

5. Once services have restarted, verify the Repository folder has been recreated. Now bear in mind, it could take up to one hour for WMI to fully rebuild.

Instructions for Windows Vista and Later (2008/Win7/2008 R2/Win8)

1.  Open an elevated command prompt.

2.    Verify the WMI repository is not corrupt by running the following command:

winmgmt /verifyrepository

If the repository is not corrupted, a “WMI Repository is consistent” message will be returned. If you get something else, go to step 3. If the repository is consistent, you need to troubleshoot more granularly. The repository is not the problem.

3. Run the following commands to repair WMI:

winmgmt /salvagerepository

If the repository salvage fails to work, then run the following command to see if it resolves the issue:

winmgmt /resetrepository

After the last command, there should be a “WMI Repository has been reset” message returned that verifies the command was successful.

Even the above commands should be a last resort if you are getting an error related to “Access Denied” or “RPC Server unavailable.”

A special note for those downloading Windows Server Update Services 3.0 Service Pack 2 (KB2734608)

Official information about this update is available here:

http://support.microsoft.com/kb/2734608

This update to WSUS 3.0 SP2 is very significant in that it adds operating system patching support for Windows 8 and Windows Server 2012 WSUS clients. In addition, it also fixes minor issues with KB2720211 (which is included in this update). For stand-alone WSUS environments this update also includes the updated version of the Windows Update Agent (WUA): 7.6.7600.256 which addresses security vulnerabilities of the Windows Update client component.

When KB2734608 is installed and you are leveraging the WSUS server engine as a Software Update Point in Configuration Manager, you may notice that when the new catalog is downloaded, the changes in that catalog structure may trigger some unexpected changes in the existing patch management database. Some existing patches may show as Invalid and may require to be re-download and re-distributed throughout the Configuration Manager hierarchy. It is highly likely that some enterprise administrators may not desire this.  

A Hotfix to the Rescue!

To prevent these actions from occurring, Microsoft released the hotfix (KB2783466.) This hotfix has to be applied to all Configuration Manager SUP/WSUS systems if  the KB2734608 was applied and preferably before the next Patch Tuesday cycle (December 11^th, 2012). If you have not applied the hotfix KB2734608, then applying this hotfix prevents the unnecessary re-downloading and re-distribution of existing patches. Official information about the hotfix can be found here:

http://support.microsoft.com/kb/2783466

Information Regarding the Updated Windows Update Agent

As described above, the KB2734608 update includes a new version of the Windows Update Agent. On standard WSUS systems, they will push out the new updated Windows Update Agent automatically to clients once the KB2734608 is installed. However, for Configuration Manager 2007 systems, the Windows Update Agent is not leveraged in the same way as standalone WSUS systems; therefore the update does not occur automatically. The security issue addressed by the Windows Update Agent update does not impact Configuration Manager, as Configuration Manager does not download their content through the Windows Update Agent. It only leverages the WU APIs for scanning and installation. The update binaries delivered through the Configuration Manager Software Update component are delivered directly from the distribution point, not through a WUA call to WU/MU or WSUS for content. There is no vulnerability exposure here for Configuration Manager Software Update Management clients, thus no need to update the Windows Update Agent to this version.

However if customers would like to upgrade WUA to the latest revision it is recommended to create software distribution command line only package from Configuration Manager  using the following command to initiate update process:

wuauclt /detectnow

This package will have to be applied to all managed systems.

SCCM (Configuration Manager) Installed Component Provider Binaries on SQL Clustered Drive (or other shared clustered drive) by Mistake.

Configuration Manager 2007 supports the Site Backup role on a clustered drive so long as the SQL cluster is Active/Passive.

The problem is the fact that the default largest NTFS drive is used to install the provider binaries and it is real easy for the SMS Component Provider in SCCM 2007 to be installed on a clustered drive by mistake when configured on a remote SQL cluster.

The scenario usually happens as follows:

1.) SMS/SCCM Site Server is installed selecting remote SQL instance and database on a clustered server as the location of the site database.

2.) Provider binaries then get placed on clustered drive that was currently owned by active node containing SQL server instance.

3.) As a result, the configuration of the SCCM/SMS backup differs on each of the database nodes. One node may be configured to run the binaries from the system drive and the other may be configured to run on a clustered drive (or even both.)

4.) Drive either becomes no longer available to the node (failed over to other node) or the drive resides on a LUN no longer presented to the cluster.

5.) You will see critical status messages related to the SMS_SITE_SQL_BACKUP and the site component manager.

The remedy for this was first devised in SMS 2003. it is mentioned in the article KB 871234:

http://support.microsoft.com/kb/871234

It is also mentioned here: http://technet.microsoft.com/en-us/library/bb632890.aspx

Now placing the file NO_SMS_ON_DRIVE.SMS on all clustered drives is a great way to prevent this from happening, how can you correct this issue after the problem has occurred?

The answer is a combination of several things including use of the NO_SMS_ON_DRIVE.SMS feature:

1. Create the following file on all clustered drives:

NO_SMS_ON_DRIVE.SMS

2. Stop the SMS_Site_SQLBackup_%SERVERNAME% on the problem node

3. Remove the following Registry Keys on the problem node:

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMS_SITE_SQLBACKUP_%SERVERNAME%

4. On the site server, browse to the fllowing registry key:

HKLM\Software\Microsoft\SMS\Components\SMS_SITE_Component_Manager\Multisite Component Servers\%SERVERNAME%

5. Change the install directory to the appropriate drive and then go to:

HKLM\Software\Microsoft\SMS\Components\SMS_SITE_Component_Manager\Multisite Component Servers\%SERVERNAME%\SMS_Site_Backup and change the value “Installed At Least One file” to 0.

6. Restart the SiteComp service on the Site server