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 reliable time server. A computer will not be classified as reliable unless 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 number of clock ticks in 64 seconds, to produce the base gain in the phase-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 | ||
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. |