I need a script and a monitor that:
1. Automatically manages the time on servers to make sure it's in sync with NTP
2. If it finds a server where the time service has stopped - try to auto fix the problem by attempting to restart/sync time service. If fail - try again.
3. If it will not start send an email.
Please give your valuable suggestions.
Monitoring the w32time service itself is easy. That's a simple service monitor set, and you can apply it to domain controllers configured to email your NOC/helpdesk if the service pukes.
Problem is, w32time can be running but the time sync itself can be horribly awry. I don't know of a way to test time sync itself.
There are commands you can run to tell the DC to use one or more NTP sources. Maybe create a policy that applies the monitor set and a procedure which runs that command? And another periodic procedure that runs the re-sync command?
Thanks for the suggestion mate.i already created a monitor to restart time service but i am just left with automatically check the sync status condition of the server with NTP.
There is a way to get a readout of the time sync with w32tm /stripchart, it's possible you could have it output to a text file, and monitor the text file using log parsing for a variance larger than what you're expecting. Or there is probably a way to pass the stripchart results directly to a monitor for review using a procedure (I wouldn't know how to go about setting that up).
There's 2 ways you can do this. If you don't mind having a cmd prompt running all the time, you can have this cmd going all day. "w32tm /stripchart /computer:time.windows.com /period:3600 /dataonly >C:\ntplogger.txt" it'll write an entry once an hour. Change period to configure how often.
Keep in mind I did a > instead of >>, the single > will overwrite in the log. The reason I do that is because if you append to a log (keep old data and add more) with >>, the log in this case never seems to add a carriage return, so it writes every entry on the same line and your parser would never work. There's ways around that with a batch script (like a loop that would also append a carriage return between every stripchart result) but that's getting into the weeds for this question. The only benefit is you'd have an hourly or at whatever interval log of every time variance.
The other way would be to just run the script windows task scheduler and do it something like "w32tm /stripchart /computer:time.windows.com /samples:1 /dataonly > C:\ntplogger.txt" so it'll collect 1 sample and then sleep again. In my mind that's more ideal, but does involve the extra step of configuring it in Task scheduler (which is usually pretty straightforward).
You'll get an output like this, Tracking time.windows.com [18.104.22.168:123].The current time is 8/24/2018 8:50:45 AM.08:50:45, +00.0180116s
Just build a log parser around it and examine the variance in the last field (+00.0180116s) for whatever your tolerance is in a parser set.
Checking time is one of our standard "Smart Monitors" - and it works like so:
Check the system type
Workgroup ? - check time against the ??.pool.ntp.org - if off, verify/update the config (time.windows.com) and run w32tm /resync. Nothing fancy for standalone systems.
Domain Member (including non-PDCe domain controllers) ?
Verify the time configuration is NT5DS - update configuration if not.
Check time against the PDCe, run w32tm /resync, wait, then re-check. Alert if still off by more than 2 minutes. (we can optionally warn if off by 30-119 seconds, but generally don't except in application server environments, where the time thresholds are set MUCH lower). We can define these overrides from the KServer on a machine or machine.group basis.
PDCe Server ?
Verify the time configuration is NTP and that no fewer than three separate ??.pool.ntp.org hosts are defined (unless overridden by something like GPS or RADIO).
Compare the local time to a public NTP server (??.??.pool.ntp.org - these are set by region) - if the PDCe time doesn't match NTP, we run w32tm /resync. There's also an option to allow "time warp" if the time is off by more than 15 minutes, forcing the time to be set to the correct time, otherwise we allow the service to "creep" back into sync.
There are 5 thresholds available to generate two levels of warnings and three levels of alarms, but these trigger only if the time can't be fixed by the Smart Monitor. Time Warps always generate an alert to let you know things were pretty bad, but these come in as an informational event unless the time resync wasn't successful.
This has virtually eliminated time sync issues across our MSP practice customers since we implemented them 2+ years ago.
These Smart Monitors run daily on every managed system. See the Automation Exchange or our website (www.mspbuilder.com) for more info on our Smart Monitor technology.