We are having Discovery WMI failures following the most recent Microsoft Patches; anyone else experiencing this?

DuaneNMore
Kilo Guru

Last weekend the various windows teams were pressed to apply the most recent set of Microsoft "Security Patches" . Looks like we applied KB4512489 and KB4511872. When we run a discovery shazzam finds port 135 (wmi) and 5985 (winrm) open but then spawns WMI: CLassify probe and we get a 

Connection failed to WMI service. Error: Permission denied

This is happening on all of our Windows Servers. 

 

 

1 ACCEPTED SOLUTION

DuaneNMore
Kilo Guru

 

I found that all of the failed Discoveries were associated with MID Servers that got rebooted during the patch cycle, and had the following Message in the MID Server Issues table (ecc_agent_issue)

Error encountered when invoking PowerShell, the result from running '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -noninteractive -nologo -noprofile -command "$ver = if (Test-Path Variable:\PSVersionTable) { $PSVersionTable.PSVersion } else { (get-host).Version }; 'full_version:' + $ver.ToString() + ', major_version:' + $ver.Major"' is

Restarted the MID Server service on the offending MID Server; the issue went away and discovery works. I am going to have a couple of my test Windows servers rebooted and see if the problem re-emerges after the reboot. 

The Occams's razor principle of MID server troubleshooting. "Suppose there exist two explanations for an occurrence. In this case the one that requires the least speculation is usually correct"

Or in this case step 1 should be restart the MID Server Service. 

 

 

View solution in original post

8 REPLIES 8

Gil Munoz
Kilo Contributor

When one of these security patches turns off a service or changes a protocol, I'd be real nervous about undoing the change.  There is, at least sometimes, very good reason for the changes.  Often, they are reasons related to security exploits.  Do we know whether DCOM negotiation or, especially, mid.use_legacy_wmi would revert to some inherently vulnerable service or protocol?  Unless we know positively that the change had nothing to do with security issues, I'd be careful about some of the suggestions on here.

DuaneNMore
Kilo Guru

 

I found that all of the failed Discoveries were associated with MID Servers that got rebooted during the patch cycle, and had the following Message in the MID Server Issues table (ecc_agent_issue)

Error encountered when invoking PowerShell, the result from running '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -noninteractive -nologo -noprofile -command "$ver = if (Test-Path Variable:\PSVersionTable) { $PSVersionTable.PSVersion } else { (get-host).Version }; 'full_version:' + $ver.ToString() + ', major_version:' + $ver.Major"' is

Restarted the MID Server service on the offending MID Server; the issue went away and discovery works. I am going to have a couple of my test Windows servers rebooted and see if the problem re-emerges after the reboot. 

The Occams's razor principle of MID server troubleshooting. "Suppose there exist two explanations for an occurrence. In this case the one that requires the least speculation is usually correct"

Or in this case step 1 should be restart the MID Server Service. 

 

 

DuaneNMore
Kilo Guru

One last update. After we found that the MID Server service needed a restart, we decided to test what happens when the Server is Rebooted. Well When the server is rebooted, the problem re-emerges and we then have to restart the MID Server service again. 

So we are opening a HI on this issue. Likely some kind of timing issue with when MID Server service is getting started.

Thanks for the update and reporting the issue, Duane.