What do you do if you are seeing a VPN client failure reason like this, or applications such as Microsoft Outlook or Microsoft Teams are not connecting may indicate a system clock issue. Here’s how to fix it.
Microsoft applications are not connecting
I was recently contacted to help someone that was having the following computer symptoms:
- Microsoft Outlook was disconnected; couldn’t connect
- Microsoft Teams couldn’t connect
- Azure VPN Client was failing to connect with the following Failure Reason:
Server did not respond properly to VPN Control Packets.
Session State: Reset sentThe computer had a working Internet connection, and I was able to use our remote support tool to connect successfully.
I reviewed the user’s Azure AD sign-in logs to see if there were sign-in failures, but there were none; all logs were successful.
Do you have the (Windows) time?
As my eyes scanned across the problem computer’s desktop, I saw the problem: the Windows time was wrong. It was currently set to not only the wrong time (10 hours later) but also the wrong day (2 days in the past).
In a distributed computing world, time synchronization is critical for network communication and security control processes. A system with an out of sync time can have all sorts of problems.
The computer was Active Directory domain joined, configured to sync to an on-premise domain controller. However, because the time had gotten out of sync, it couldn’t connect to VPN to reach the domain controller to get the correct time (an IT Catch-22).
Set Windows Time with PowerShell
To resolve the immediate issue, I needed to manually correct the Windows time, which requires Windows administrator rights.
I right-clicked Windows PowerShell and clicked Run As Administrator. I signed in as the computer’s local administrator account (which we manage with Microsoft’s Local Administrator Password Solution, or LAPS).
First, I needed to set a PowerShell variable to a date/time value as close as possible to the current time. Accurate to the minute is sufficient:
$dt = Get-Date -Date "2/14/2022 12:30:00"Then, I use Set-Date to update the Windows time using the stored value:
Set-Date -Date $dtThe Windows clock now had an accurate time. We were able to successfully connect the Azure VPN Client. Microsoft Outlook and Microsoft Teams successfully reconnected.
We confirmed the computer was able to successfully do a time sync against the domain controller. However, you can see what a problem an out of sync computer time can cause, including preventing VPN from connecting to sync the time.
Configure an NTP backup server to domain time sync
In 2020, when people started consistently working remote, Microsoft published some guidance to help avoid this issue by enabling a backup NTP sync option using time.windows.com.
The following command line sequence configures the backup time server time.windows.com on an infrequent polling interval. This should prevent computers from completely falling out of time sync if they can’t communicate with a domain controller (WARNING: test this in your lab before doing a wide scale configuration deployment):
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters /v Type /t REG_SZ /d “AllSync” /f
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters /v NtpServer /t REG_SZ /d “time.windows.com,0xB” /f
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config /v MaxPollInterval /t REG_DWORD /d 15
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config /v MaxAllowedPhaseOffset /t REG_DWORD /d 1
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient /v SpecialPollInterval /t REG_DWORD /d 32768For simplicity, I recommend using time.windows.com as your NTP server not only for Windows, but any other devices/applications that support time sync.
- It is the default time server for all Windows installations
- It resolves to a single highly available IP, backed by Microsoft Azure’s Traffic Manager service
- While it is a Stratum 2 server, it lets you specify a single time server instead of relying on multiple Stratum 1 servers. In my own experience using NIST Stratum 1 servers, I saw time sync discrepancies between different servers. Per ntp.org, “Stratum 2 time servers are not significantly less accurate than stratum 1 time servers.”