Troubleshooting WMI Repository Bloat

Troubleshooting WMI Repository Bloat

I was recently asked to assist in troubleshooting large WMI repositories, sometimes in upwards of 1GB. This was causing the slow RDP logon issue described in KB2020286. We found that RSOP logging was not enabled on these machines. My first step was to identify which servers had large WMI repositories. I created a SCOM Management Pack (MP) for this which I have attached. The MP also does some basic health checks of WMI using the script below.

Update: I removed the /verifyrepository check from the MP. We found that it can sometimes conflict with WMI on reboots. WMI also does a /verifyrepository on startup. If SCOM also runs this check at the same time then WMI may appear to be hung for several minutes, but it eventually recovers. Connections to WMI can still be made but queries won’t return anything until after both /verifyrepository commands are done.

Once we identified the machines with WMI repositories over 300MB we worked to identify what in the repository was taking up all the space. I researched various ways to determine this including recursively going through each namespace and class in WMI and counting them but since many providers populate instances that aren’t actually stored in the repository I figured this wouldn’t be an accurate method of determining what is taking up space in WMI. I ended up going with the method below instead.

Copy the objects.data (WMI repository) file from several of the machines identified to your desktop. The file is located in the %windir%\system32\wbem\repository folder.

We found that SCCM data seemed to be using up the most space. Knowing that I figured that now would be a good time to recursively go through the root\ccm namespace (used by SCCM) to determine which class has the most instances. The script below shows you how many instances are under root\ccm (and any namespaces under this) and lists out each class along with the top namespaces.