Time sync, synchronization on an Azure App Service

An Azure App Service is PaaS and synchronizes the clocks based on the hosting platform.  As per this request, the drift may be up to 2 seconds and are synced once per week.  That request was made some years ago when an App Service was running on Windows Server 2012 and IIS 8.  With the introduction of Windows Server 2016 there have been some improvements in regards to the Windows Time Service and NTP.

You can view this post, “How to check Azure App Service OS version, what version of IIS” to see which Windows Server version your App Service is running on.  You should find that the version is now Windows Service 2016 and IIS 10.

Read here as well to find out why is time important.

I have read that the clocks are synced more often than once per week now and that the total clock drift is still within the tolerance for PCI-DSS purposes.  I would expect the clocks to be synched as per the setting in UpdatePollInterval of ~64 seconds.

*There are no App Service mechanisms for syncing the the clock yourself and if you require a more precise level of synchronization then you can consider an IaaS Azure offering.

I was able to run the W32TM command and check some stats and configurations on the App Service VM.  I didn’t try them all but this one looked interesting.  It displays a strip chart of the offset between this computer and another computer.

 
w32tm /stripchart /computer:time.windows.com /dataonly /samples:5

This has an output showing that in Figure 1.

Figure 1, time drift, time synchronization Azure App Service

You can also check the configuration of the W32Time on an Azure App Service using the following command in KUDU/SCM:

 
REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config"

I have discussed other details you can find out using the REG QUERY, check these out:

• Visual C++ Redistributable Packages for Visual Studio Azure App Service
• How to determine the installed .NET version in Azure App Services
• How to see the cipher suites on an Azure App Service

When I dumped out the W32Time configuration I learned a few things:

• The App Service VMs are apparently configured for High Accuracy as described here.
• Managing time and the synchronization between servers is hard
• There is a w32time.log file in the D:\Windows\ directory, as seen in Figure 2, have a look through it.

Figure 2, how to troubleshoot time synchronization and Azure App Service

Here is what I could find about some internals of the configuration of the W32Time synchronization feature.

AnnounceFlags	0x0000000a  (10)	Specifies whether this computer is a time server or a reliabletime server. A computer will not be classified as reliableunless it is also classified as a time server.
ClockAdjustmentAuditLimit	0x00000320  (800)
ClockHoldoverPeriod	0x0000c350  (50000)
EventLogFlags	0x00000002  (2)	Specifies the events that the time service logs.
FrequencyCorrectRate	0x00000004  (4)	Affects the rate at which the time service corrects the clock.This value, in units equal to the reciprocal of the rate atwhich the clock is corrected, is multiplied by the numberof clock ticks in 64 seconds, to produce the base gain in thephase-locked loop (PLL) of the clock correction algorithm.
HoldPeriod	0x00000005  (5)	Specifies the period of time for which spike detection isdisabled in order to bring the local clock into synchronizationquickly. A spike is a time sample indicating that time isoff by a number of seconds, usually received after goodtime samples have been returned consistently.
LargePhaseOffset	Specifies the time offset, in seconds, by which times greaterthan or equal to this value are to be considered suspiciousand possibly erroneous.
LastKnownGoodTime	0x
LocalClockDispersion	0x0000000a  (10)	This setting, expressed in seconds, is applicable only whenthe Network Time Protocol (NTP) server is using the time ofthe local CMOS clock. The LocalClockDispersion value indicatesthe maximum error in seconds that is reported by the NTPserver to clients that are requesting a time sample.
MaxAllowedPhaseOffset	0x0000012c  (300)
MaxNegPhaseCorrection	0xffffffff        (4294967295)	Specifies the time, in seconds, of the largest negative timecorrection that the Windows Time service is allowed to make.If the service determines that a change larger than this isrequired, then the service logs an event instead.
MaxPollInterval	0x0000000f  (15)	Specifies the longest interval (in units of 2n seconds, wheren is the value of this entry) that is allowed for systempolling. While the system does not request samples lessfrequently than this, a provider may refuse to produce sampleswhen requested to do so.
MaxPosPhaseCorrection	0xffffffff        (4294967295)	Specifies the largest positive time correction, in seconds,that the Windows Time service is allowed to make. If theservice determines that a change larger than this isrequired, then the service logs an event instead.
MinPollInterval	0x0000000a  (10)	Specifies the shortest interval (in units of 2n seconds,where n is the value of this entry) that is allowed forsystem polling. While the system does not request samplesmore frequently than this, a provider may produce sampleswhenever it wants.
PhaseCorrectRate	0x00000001  (1)
PollAdjustFactor	0x00000005  (5)	Controls the decision to increase or decrease thesystem-recommended poll interval. Larger values mean that asmaller amount of error will cause the poll interval to bedecreased.
SpikeWatchPeriod	0x00000384  (900)	Specifies the amount of time, in seconds, that a suspiciousoffset must persist before it is accepted as correct.
TimeJumpAuditOffset	0x00007080  (28800)
UpdateInterval	0x00007530  (30000)	Specifies the number of intervals, .01 seconds in length,between phase correction adjustments.
UtilizeSslTimeData	0x00000001  (1)	Determines the approximate current time from outgoing SSLconnections. This time value is used to monitor the localsystem clock and correct any gross errors.