As most tech’s know, Time is important to be synced across all servers and workstations on a network. After working many years in the field, you find incorrect server time can cause major issues. Queue my problem! My company recently added a new office in Brazil that needed servers here. So, we blew up a VM and everything seemed to be working correctly until we received a ticket for an issue regarding the time on said server and a new app that needed time to be accurate. I RDP’d the Brazil server and it was 3 hours ahead of our time and should have only been 2 hours ahead. Here’s what it took to get working correctly!
In command prompt I ran: w32tm /query /source
Which revealed that the server time source was our secondary domain controller. I wasn’t sure of the Brazil NTP servers so after a quick google search I found them (0.br.pool.ntp.org-3.br.pool.ntp.org). The natural next step was to configure this pool as our main time source for this server.
So I ran:
- w32tm.exe /config /manualpeerlist:”0.br.pool.ntp.org 1.br.pool.ntp.org 2.br.pool.ntp.org 3.br.pool.ntp.org”
This “completed successfully”, however, after running a query on the source again it still showed our secondary domain controller as its time source. Drats! After this failed attempt, I parsed through Group policy and the netlogon folder to see if there was a script or policy forcing it but this search came up inconclusive. Then I realized, that it was on a VM and sometimes the host time clock affects it’s virtual machines. I set the time correctly and the proper NTP servers on the host. I ran a “w32tm.exe /config /update” and the time sadly didn’t sync to the right time applied on the host server. I went back to the original command and tried adding a few extra flags and after some trial and error I found the winning combo!
- w32tm.exe /config /manualpeerlist:”0.br.pool.ntp.org 1.br.pool.ntp.org 2.br.pool.ntp.org 3.br.pool.ntp.org” /syncfromflags:manual /reliable:YES /update
Hooray! I had done it. After running the query again it now showed br.pool.ntp.org as its time source and the correct server time! All was well, until a few hours later when we received another ticket noting that the new app was again not functioning because of a time difference. I hopped back on that server and again the time was 3 hours ahead instead of 2 hours. I browsed through some settings to finally find the true issue, the clock was set to automatically adjust to daylight savings time. Since, US and Brazil daylight savings time are not in sync it was forcing the server to get this extra hour time difference no matter the time source it was pointed to. Once I disabled the auto adjust for daylights savings the clock went to the appropriate time on the server and remained on the correct time. The only issue with this is that we will have to manually adjust the time when Brazilian daylight saving time starts and begins.
It was just one of those stereotypical cases where the resolution to my problem was much simpler than perceived! This seems to happen often in the IT world. But it sure is an accomplishing feeling when you find the solution to your problem!