I was recently diagnosing a time drift issue for a client located in a different city.
Their workstations were having issues accessing the Windows 2019 server due to this drift.
Based on the age of the device, my initial instinct was a dying CMOS battery. I thought maybe AIDA64 might provide those details, but it did not.
Another user on here recommended using a program called hwinfo, which after trying on my own device, I found works great, but being unable to install unapproved software on this device, I was unable to use it for my purposes..
SOO.. I first changed the time in the GUI, then continued my other tasks. Over that 1 hour, the clock again drifted by almost 1 min.
..CMOS
I ran some cmds, mostly w32tm and saw CMOS as the clock source, but being very far away from the server, and not trusting anyone onsite to change the battery, I reassigned the source to pool.ntp.org and changed related settings, with help from this walk-thru:
https://icookservers.blog/2014/09/12/windows-ntp-server-cookbook/
I cannot verify the voltage, but based on
-
the observed drift over 1hr
-
reg entry: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfigAnnounceFlags set to 10 (this tells the server to sync time to local CMOS clock)
3.the results from w32tm /query /source (Local CMOS clock)
4.the results from w32tm /query /status /verbose (the computer did not resync because no time data was available)
5.Buncha other things
it seemed undeniable that all configs pointed to be dependent upon a failing source…
Questions: how reliably will this work as a workaround, for how long, and does anyone know any methods using CMD or PowShell or built in utilities that will provide a V reading on the battery?
I personally would love an on-the-clock, out of town trip to change a small cell battery as much as the client would hate it, but in the meantime…
Thanks
