I ran into an issue with my SCOM environment that prompted some digging.
My external name resolution monitor for my DNS 2008 MP was always coming up critical. See below:
The server health status would roll up to critical and consequently would cause AD alerts to come up:
The issue here is in the way that the actual monitor is performing the test because I can resolve external names. I tested this in my DNS server and clients both by using my DNS server with forwarders or with Root Hints.
Here is what the test is actually doing:
Now, from a Health Explorer perspective, here is the actual test:
So the DNS 2008 external name resolution monitor is performing an ns query on www.microsoft.com using my DNS server.
This will actually fail. Well, sort of… See below:
There was an output. So what’s the issue?
Kevin Holman (OpsMgr MVP) blogged about this issue some time ago. See here:
http://blogs.technet.com/kevinholman/archive/2009/02/24/dns-mp-external-resolution-monitor-always-in-a-critical-state.aspx
Kevin was correct in his post that the actual issue with this specific monitor test is that we are attempting to perform an ns query against a host (www.microsoft.com and not a zone: microsoft.com).
If we modify the test as follows, the output returns the list of name servers:
That’s great. We get the list of name servers. What’s interesting here, is this is the expected output.
How would we have known that from the test? Here is a more important question: Why are we even using an ns query when the monitor is performing test lookups against external addresses?
More on that, for now let’s just correct the monitor test so that our environment reports correctly.
OK, so now we know how to modify the monitor to work correctly with an ns test. We should override this monitor for all objects of class: DNS server since the test itself is flawed and not the monitor per se on any particular DNS Server. Make sure to save your override in a relevant unsealed management pack if you need to get at it easily later.
It may take up to 5 minutes for your alert to clear once you have made the override.
OK, so the alert closed itself since the default monitor behavior was configured to do so.
The Computer health status is also Healthy now.
We can also see that the name resolution test is fixed as well. All is good.
Now, why did the ns query not liking the output… We did get an output from the original test remember?
Well, I found that out by digging. This post below confirms it:
http://www.gasmi.net/nslman.html
OK so we sort of have the answer for what was wrong with the test. That still does not really answer what was wrong with the output that we received…
When a monitor is configured, a health status is equated to something and it is still unclear what constitutes “unhealthy” for this test.
I will expand on that in a separate post as I actually discover the answer.
Now for the other question:
Why are we even using an ns query when the monitor is performing test lookups against external addresses?
I think that the type of test being performed is not what we are looking for.
A name resolution given a host name (ex. www.microsoft.com) would resolve to an IP address by checking a host (A) record on some DNS server. See below:
So given the name of the monitor “External Address Resolution” we should be performing a query against “A” or host records. Let’s try that.
OK, the query seems to work as expected.
To make the change quickly, I’ll override the monitor properties for all objects of class: DNS Server using the Closed Alerts view that I created in my environment.
What I did was to put the Host parameter back as www.microsoft.com but to change the Query Type parameter from ns to A.
My Health status is Healthy and I have no new Active Alerts!