Object enumeration failed
Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "Print Services"
Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "MSSQL$MGT"
Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "CLusSvc"
Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "MSSQL$RCT"
The following Microsoft article provides a foundation for one solution to this issue:
http://support.microsoft.com/kb/2590230
Basically, the Windows Management Instrumentation files (*.mof) have the encryption flag turned on. This is not necessarily the case for all servers. For example, out of 100 servers, 10 exhibited this behavior.
To check on the accessibility of wmi from a remote machine, I connected with the Scriptomatic tool, changing the "WMI Source" to the remote system. When I attempted to do so, the application would error out and a warning would be logged on the remote server as to the offending WMI class.
I had to walk through several classes, repeating the steps in the microsoft article each time. I found, in most cases, the encryption flag had to be set to false in the following files:
C:\Windows\System32\WBEM\win32_tpm.mof
C:\Windows\System32\WBEM\Tscfgwmi.mof
C:\Windows\System32\WBEM\ServiceModel.mof
C:\Windows\System32\WBEM\IISwmi.mof
C:\Windows\System32\InetSrv\WebAdministration.mof
C:\Windows\SysWow64\InetSrv\WebAdministration.mof
After setting the encryption flags to FALSE and recompiling the mof files, I was able to successfully connect to the remote system via Scriptomatic and consequently, the warnings subsided in SCOM as well.
In case the Microsoft Article disappears, the steps are as follows:
1. Open C:\Windows\system32\wbem\
2. Recompile the
3. Restart the winmgmt service
You may have to adjust security on those files in order to make changes in them. They are typically owned by the System or TrustedInstaller and not able to be directly written into.
No comments:
Post a Comment