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_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig"
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 at which 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 is disabled in order to bring the local clock into synchronization quickly. A spike is a time sample indicating that time is off by a number of seconds, usually received after good time samples have been returned consistently. |
| LargePhaseOffset | Specifies the time offset, in seconds, by which times greater than or equal to this value are to be considered suspicious and possibly erroneous. |
|
| LastKnownGoodTime | 0x | |
| LocalClockDispersion | 0x0000000a (10) | This setting, expressed in seconds, is applicable only when the Network Time Protocol (NTP) server is using the time of the local CMOS clock. The LocalClockDispersion value indicates the maximum error in seconds that is reported by the NTP server to clients that are requesting a time sample. |
| MaxAllowedPhaseOffset | 0x0000012c (300) | |
| MaxNegPhaseCorrection | 0xffffffff (4294967295) | Specifies the time, in seconds, of the largest negative time correction that the Windows Time service is allowed to make. If the service determines that a change larger than this is required, then the service logs an event instead. |
| MaxPollInterval | 0x0000000f (15) | Specifies the longest interval (in units of 2n seconds, where n is the value of this entry) that is allowed for system polling. While the system does not request samples less frequently than this, a provider may refuse to produce samples when 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 the service determines that a change larger than this is required, 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 for system polling. While the system does not request samples more frequently than this, a provider may produce samples whenever it wants. |
| PhaseCorrectRate | 0x00000001 (1) | |
| PollAdjustFactor | 0x00000005 (5) | Controls the decision to increase or decrease the system-recommended poll interval. Larger values mean that a smaller amount of error will cause the poll interval to be decreased. |
| SpikeWatchPeriod | 0x00000384 (900) | Specifies the amount of time, in seconds, that a suspicious offset 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 SSL connections. This time value is used to monitor the local system clock and correct any gross errors. |