Server Clock Drift (Powershell)

Version 13

    The canned Clock Drift monitor required enabling PSRemoting and adding the polling engines to the trusted clients list, which IMO is a huge PITA. I set out to re-invent this wheel to be something that was a little easier to deploy. This script uses both WMI and w32tm to gather time data from a remote time server, such as time.NIST.gov. For PCI zones, you can also designate a local server to grab the time (w32tm) instead of using an external source if it is serving up NTP.

     

     

    (10 14 2015)

    I'll update this monitor shortly. I noticed the WMI collection runs in the ISE, but not when plugged into Orion. I've added a catch for that as well, which I will update when I work through the WMI polling issue I found. For the time being, this monitor only works on the local polling server, when polled by itself...

     

    (10 15 2015)

    Support was able to run this in their tests, but I wasn't in mine. It only worked when pollers were checking themselves. I had to modify the WMI update like this:

    $gitServerTimeHour      = (get-wmiobject win32_localtime -credential $username -computername $ip).Hour

     

    You have to remove -credential for any polling engine monitoring itself.

    _______

    This works great now, and I've identified a handful of drifting clocks now (finally).

     

    _______

    One thing to consider with this is how long it takes to run this script due to Orion or the environment. It's a good idea to benchmark, the runtime of the script, and remove that from the statistic. I added a $clockStart and $clockStop ($clockStart = Get-Date), and then I'm taking the New-TimeSpan -Start $clockStart -End $clockStop. I have these at the beginning, and right after grabbing both clock values. This seems to have improved the measurement, but I'll be monitoring it for a couple of days. We're having to monitor this at a very tight tolerance, which makes this effort all the more difficult.

     

    _________

    (04, 2016) - Ultimately, I went a different route. The LINUX servers seemed to handle this kind of measurement much better than the windows servers. What I did instead was to look at the log for the utility we are using to check clock drift. We're using NetTime, so instead of trying to measure the delta, I'm looking to the log for answers. If you're interested in seeing the NetTime log monitor, PM me. The log monitor checks the log, and is looking at the last entry timestamp, as well as the last good entry, and reports both the log age as well as the last good entry adjustment.