Share via

Reliable Time Monitor False Positives for AD Domain Member Monitoring

  • Article

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

I had a chance to work with a customer on importing the new AD MP for SCOM. I like this MP in particular, as it’s much less noisy than the old management pack for AD. That said, one thing I’ve seen in a few environments is a warning from the Reliable Time Server Monitor being unable to locate a time server. I had a chance this week to do some digging into this particular monitor, and there appears to be a flaw in the script data source that calculates this monitor.

Why does it matter?

In short, it’s an authentication thing. Protocols such as Kerberos rely on time stamps for authentication, and in order for those to be accurate, all systems in the domain must be using a shared time source.

What is it doing?

The script is straight forward, it runs the following command:  nltest.exe /dsgetdc: /gtimeserv

Documentation for this command can be found here. Interestingly enough, there are two time server commands available. The /gtimeserv command, which our script is using, looks for a master time server, which from what I can tell has to be designated. The /timeserv command simply looks for a time server. I’m not an AD expert, but I can say that in any AD domain, a master time server is not designated from the get go. It’s possible that an admin should do this with an authoritative internet source, but documentation on that process seems rather light in my quick search of the issue. That said, the output from said commands is the same:

image

It’s worth noting the circled items, as these appear to play a role in our script. The key line in the script is here:

image

I don’t pretend to be a VB expert, but from my untrained eye, the script runs the NLTEST command and then does a filter against the string GTIMESERV. Note that this string does not appear anywhere in the NLTEST results. As such, this will generate an alert in almost any (if not every) environment. My guess would be that the preferred solution would be to designated an internet master time server in your environment, though that’s not always reasonable. In that case, the next best thing would be to modify the data source. I’ve recreated this data source with an override to the original monitor.

You can find that management pack here:

Comments

  • Anonymous
    December 28, 2017
    I don’t believe that this is usually a problem for the following reasons:1. The monitor (i.e. “Reliable Time Server Monitor”) targets a class (i.e. “Active Directory Domain Member Perspective”) whose discovery needs to be manually enabled to provide for “Domain Member Perspective” monitoring;2. It is my understanding that most AD admins will configure a master time server for their AD forest using the following switch:value associated with the W32tm.exe command: /Reliable:Yes
    • Anonymous
      January 04, 2018
      That's fair. I've worked in several environments with this issue, hence the post.
  • Anonymous
    September 11, 2018
    Hi, what version of SCOM is this override management pack for? When attempting to import into SCOM 2012R2 UR13 I get an error stating a dependant management pack is missing "Microsoft.SystemCenter.Library" version 7.0.8437.0. My SCOM 2012R2 UR13 version of this MP is 7.0.8433.0.Thanks