0

Due to a badly written interface, I have a need to ensure that server A is always a few seconds ahead of server B. (Yes I know this is a horrible thing to do) I have three broad solutions so far:

  1. (preferred) alter W32Time to set the clock X seconds ahead when it does its time NTP sync.

  2. install a different (modified?) NTP time service (I see Meinberg being mentioned for Windows) but prefer not to change the server so drastically.

  3. (the hackiest) a scheduled task tied to the W32Time event log. This would mean every time Win32Time set the clock, a script would run to skew it (Yuck). I am stopped here by the fact that the log MS says exists for the service on Windows 2016 is not there. All I can see from MS support is how to check your server version because it "must be there"

Update: Ok I may be new here but a LONG time user of StackOverflow with a high rep.
If you vote me down that is ok, but would like to know why, so I can adjust.

I cannot think of a way to make this any more precise.

Mathew Frank
  • 119
  • 3
  • 1
    I hadn't voted it down, but I can understand those who did that. This site is about reasonable business IT practices and, guess what, you need to have a very deep reason to screw your clock for the whole server. No reason given. Fix an interface, or at least write an adapter (a proxy) to that interface that adjusts clock readings, that looks much more reasonable than breaking clock for the whole system with all messy consequences that follow for admins and everybody. Don't be one of those stupid devs who require insane system settings because they don't know how to make good software. – Nikita Kipriyanov Jun 08 '23 at 03:48
  • The reason is in the first sentence. "due to a badly written interface" - all I left out is one forced on us by an external vendor - not uncommon when working in Ops. I was sure to mention this was a bad idea because I agree with you that it is a bad idea.. I have been on the ops side for about 8 years now. – Mathew Frank Jun 08 '23 at 23:23

1 Answers1

1

Ok so happily I got the vendor to see sense and fix their interface (enough). Since I hate to leave things unanswered, there is a simple solution, if you are unfortunate enough to need to do this:

  1. set the w32time to manual (instead of automatic)
  2. create a scheduled task to sync the clock, and skew the time on the very next line

If you are on a domain you are probably using a Domain Controller (automatically) as the time source. So you need to ask the domain for the time server, to be able to put it in the call to w32time.

For the remainder of this text, example.com is the domain, and time.example.com is the time server.

To get the time server for a typical domain (example.com):

nltest /dsgetdc:example.com

Grab the "DC: ..." value. It will be your time server.

To set your time sync to manual run this command:

w32tm /config /syncfromflags:manual /reliable:YES /update

Then restart 'Windows Time' service.

to get time skew w32tm /stripchart /computer:time.exaample.com /samples:3 /dataonly

Take the data in the second column, and average the three numbers. That is how far ahead or behind server is compared to the time source.

to add time to the current clock using powershell

Set-Date -Date (Get-Date).AddSeconds(1.03)

Note: this will add a few milliseconds more than the "1.03" in the example. You could call it several times to measure how many milliseconds are added, and build this into how you calculate the values for the function call. Depending on how accurate you need to be, you may want to check time skew again after setting this.

To set your clock sync back to automatic run this command:

w32tm /config /syncfromflags:domhier /update

Then restart 'Windows Time' service.

So Putting it all Together

  1. Set the Windows Time (W32tm) sync to manual
  2. Create a scheduled task to regularly call a script to manually sync the time.

The Script Steps

This assumes you are need to have the local clock X an amount of time ahead(/behind) another server's clock. If you just need it skewed from the time server, you can simplify this script.

  1. If needed, determine the time source
  2. sync the clock
  3. measure time skew of the local clock
  4. Check if the server is already ahead/behind enough your other server's clock:
    1. use remote powershell to execute the command to measure time skew
    2. compare the time skew of the local and remote server so see how far ahead the server currently is.
  5. if determined that the server time needs adjusting:
    1. sync the local clock
    2. run the command to check the time skew
    3. compare the actual skew to the required skew
    4. if required, run a command to add X.yyyy amount of seconds to the local clock.
Mathew Frank
  • 119
  • 3