Our answer has always been that we love all our customer's devices equally. In the case of Windows, our answer to the above question was that:
- It's complicated to get the equivalent data out of Windows (more on this later)
- Windows does a good job of logging events about time issues, and LogicMonitor will, by default, pick up and alert on these events.
Why the problem?
Keeping accurate time across all devices is essential for many reasons (trying to correlate issues across systems with different clocks is a nightmare. Let your clocks get out of sync enough, and even HTTPS will fail.)
While Windows does run time services that use NTP to synchronize time accurately, it doesn't run a full NTP client. So unlike Linux, or most networking or storage gear, you cannot issue an NTP query against a Windows server to determine what it is synchronized with, and its time offset.
The Windows-y way to monitor time is to use w32tm. But, there are some complications with generalizing this. One nice way to monitor time may be to compare a server's time to that of the domain's time source. However, while running w32tm /query (to determine the configured peers for a server) and w32tm /stripchart (to determine offsets from that peer) would work, it won't work for servers where time services are not set up, as they are not in a domain or for other reasons (it will exit with a service error code). It also requires remote powershell to be enabled, in order to run the w32tm commands remotely on all servers (not to mention special handling to deal with Domain controllers that are acting as time sources.)
So... the solution?
A nice general solution, that works for all Windows servers, regardless of whether they are in a domain, or are not running time services, is to compare the server's clock time to that of the collector. The server's date and time is accessible via WMI using the LocalDateTime property of the Win32_OperatingSystem class, so no special remote privileges are required to collect this. A simple embedded groovy script to correct for timezones, and compare the collector's time, and voila!
We now alert on differences between a monitored server's time, and the collector's. And more importantly, we make nice graphs, to reassure people that we are doing this monitoring - a weakness of the event monitoring approach, where you can only see that we are watching for things to go wrong after we have caught the event.
New customers will have this monitoring by default. Existing customers can easily import the Windows_TimeOffset datasource from our core repository. (We don't typically push out new datasources, to avoid triggering unexpected alerts.)