Ever had a machine where WMI stopped working properly and needed to be rebuilt? Was it running something that does high volumes of WMI calls (like System Center agents, or Tivoli, or HP OpenView (to name a few regular problem children – I’m sure you can think of more)?
Here’s a PS script I run to increase memory per WMI process (and globally across the machine) available to WMI, as well as modifying it in the boot order (if you rely on RSOP, WMI’s default configuration means it’s possible it won’t be completely loaded properly when Group Policy runs, and can cause RSOP issues, amongst other things).
$oWMI=get-wmiobject -Namespace root -Class __ProviderHostQuotaConfiguration $oWMI.MemoryPerHost=768*1024*1024 $oWMI.MemoryAllHosts=2048*1024*1024 $oWMI.put() Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Winmgmt -Name 'Group' -Value 'COM Infrastructure' winmgmt /standalonehost
This script increases VA available to WMI to 768MB per WMI process, and 2GB per machine. It sets WMI to run in it’s own svchost (useful for debugging purposes), and moves it to run in the “COM Infrastructure” group so that it starts closely after RPCSS (versus waiting until the end of service processing to start), which can improve boot times as well. Note that these changes even survive sysprep, so they can be “baked in”:
This isn’t a silver bullet, by any means – I still recommend installing WMI hotfixes when available from Microsoft, but this can improve WMI reliability by quite a bit.