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.

image

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"

image

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

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.

image

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.
Comments (0)

Skip to main content