"Check mismatched MS updates" in every Server

I cannot help you resolve this unfortunately but can fill you in on my experience with this.

Customer site - Main Poller, 3 APEs and 1 AWS.

Was also seeing these msgs in Deployment Health and also seeing them when running Diagnostics from each SW server (in that case, I would see the msgs related to "Cannot get" for all the other (including Main Poller) SW servers and not for the one running Diagnostics on).

This (I believe) is some cross-server communications issue (RCP, Firewall, WMI access or some such) and not exactly an issue with SW servers necessarily in sync with their OS Versions, .NET versions etc.. Basically, the diagnostic/Deployment Health "scripts" are attempting to connect to the other servers in the Orion/SW environment and check that all the pollers etc. are running same/supported versions of underlying other vendor software that SW relies on.

This connection (for some reason) is not working and thus the errors.

Also (in my opinion) the description of this issue in Deployment Health/Diagnostics "could" lead one to believe that there is some sort of issue with the "versions" rather than there is a communications/permissions/whatever issue.

The fact that these are flagged in Deployment Health as Warning leads one to assume that it is an issue that "could" impact performance and should be fixed (and indeed the "help" implies exactly this).

I raised a ticket for this.

Long story short - after at least six times explaining to support that, yes, I understand that this is a check for versions and, no, your response that (basically) "ignore these as it has nothing to do with SW running and you can check them yourself" does not explain what is "broken" and how to fix, I ended up giving up.

Replies like this:- "It was not an issue, it was indicating that your WIndows patches are different from the Main Poller and on the APE. Orion comparing this data as comparison. Best Regards", "Orion will detects is OS and patch using the WMI query that why it know the status of the server and health. As a new feature of the Orioj which is the Deployment health it will detect some possible or potential issue as listed which are the example for the MisMatch of your Patch." and on and on.

My replies of:

"Hi,   Yes – I understand what it does.   Please look at the messages being produced.   The messages are not indicating that Orion has detected mismatch in patches or updates.   The messages are indicating   From each SolarWinds Server (Main and APEs) – each server is unable to connect to any of the other servers to check their Versions/mismatches Some messages related to being unable to resolve IP addresses for the other servers   This is being indicated for each Solarwinds server (Main and APEs) – there is an issue with whatever this process is connecting to the other servers and doing its checking etc.   We need information on what exactly is not working, what “things” are required for this cross-system communication to work and how to fix/settings required etc."

resulted in the same verbiage describing what the function does and no help with identifying the failure issues or where to look etc.

The back and forth goes over 30 entries in the ticket over a 9 week period (I kid you not).

In the end, the person I was dealing with went "on leave" and after 2 or 3 back and forths, the new person closed the ticket and opened a new one.

I did not bother following up and the ticket was auto closed (as they are) after no activity after a week or so.

I would suggest you raise a ticket with support, however if you end up in the same merry-go-round I did, that's not going to help you unfortunately.

With luck, some other Thwacker will chime in with useful help.

I will watch this thread in anticipation.

Good luck.

You are likely receiving this message because of port restrictions. Can the main poller reach the scalability engines via WMI?

Yes, they can reach each other.

What method did you use to valiate this? Also, what is the latecey between these machines and main poller?

I seem to be having the same issue.  Did original poster figure out what their issue was?

Agreed...same problem here and hoping a solution exists.

Same here.  If someone at Solarwinds goes to the trouble of building these checks into the diagnostics, take the extra time to spell out the condition that lead to a failure/warning.  If it were a port restriction as alterego suggests, the result description should say "Target xx does not respond on port xx."  If the diagnostics always return it a predicable list of warnings/errors that can be ignored, its very difficult to spot the new/real warnings and errors, thus it discourages admins from using it.