I haven’t added any articles for ages, so here’s a fairly simple one…
One of the key things for SysAdmins is the ability to monitor the devices they’re responsible for. Pretty standard stuff and nothing new to anyone.
The most simplistic and universal method of doing so is to use the Simple Network Management Protocol (SNMP). It’ll give you all the standard things you usually want to know about your server(s), e.g. CPU, Memory and Disk usage.
Hello WMI
However it would probably useful and in some cases essential to also be able to monitor your standard Windows Applications or additional Windows Performance Counters otherwise unavailable through SNMP; e.g. IIS, SQL Server, Sharepoint to name just a couple.
For this you can utilise Windows Management Instrumentation (WMI). It’s worth noting that WMI can be used for more than simply querying/monitoring performance counters.
If you want to read more about the power of WMI, then read up on it here: About WMI
I won’t go into configuring WMI, there are plenty of articles on the Web that can help you with that, just use your usual Google foo.
The Problem
So if you’re only monitoring systems on your Internal LAN then you’re probably set to go. See ya later!
However in cases where you want to make use of WMI monitoring for remote devices over the public network, you’ll likely find your queries fail and time out.
The issue is WMI doesn’t work through Network Address Translation (NAT), or more accurately the Distributed Component Object Model (DCOM) doesn’t.
When you make your WMI query to your target, DCOM responds with a list of Hostnames and IP Addresses. Your client then pings these and uses the first one that responds.
For a device that is NAT’d the DCOM response knows nothing about the public IP Address, and thus none of the returned addresses will respond.
It is also worth noting that DCOM allocates ports dynamically, so you’ll need to keep an eye on your firewall rules, or look to restrict DCOM to a set of specific ports.
The Fix
The issue is actually fairly simple to resolve, the only reason I have written this article is I had to click around the web a few times before I discovered the reason behind the failure.
So to resolve the issue you just need to give your client a method to resolve the hostname that is returned by DCOM.
The simplest method of course is to use a hosts file entry on your client.
Assuming you configured WMI/DCOM correctly you should now find you can successfully query your remote NAT’d devices via WMI.
The drawback of course is, if you have a large number of remote NAT’d devices to monitor; you’re going to have a potentially large hosts file to maintain.
Another alternative of course would be using an Agent based monitoring method.
As an example Solarwinds Orion provides such a method which allows you to take advantage of WMI Monitoring without the NAT issue, other products may provide similar functionality.
Anyway, Happy Monitoring….