When connecting using RDP to a Windows 2016 server, you may receive an error message which seems clueless to you: Windows 2016 Remote Desktop cannot verify the identity of the remote computer because there is a time or date difference between your computer and the remote computer.
When you manage to connect to the host, using the console or a Powershell session, you immediately check the time and you see no discrepancy between that machine and the one you’re connecting from. When you investigate further you notice warning and errors for the DNS Client service stating it could not register the server. The GPO client side fails to be applied because no Domain Controller is to be found. However if you troubleshoot the connectivity between the Domain Controller/DNS Server and your machine, you see no error in the firewall, just that the DNS Service isn’t answering, whereas other clients don’t have any issue. On the machine, you are likely to encounter the event 8015 of source DNS Client Events. “The system failed to register host (A or AAAA) resource records (RRs) for network adapter”
If you look carefully at the event viewer, you’ll see however an error from the TCP/IP stack, saying that there is no UDP Ports left. If you issue an netstat -a -b -n command, you’ll see they are all eaten up by the WMIPrvSe.exe process. KIlling this process doesn’t help. If you restart the machine everything is of course cleared up. The message (Source: TCPIP, event 4266) you get before the DNS issues is “A request to allocate an ephemeral port number from the global UDP port space has failed due to all such ports being in use”.
If you are able to force Kerberos over TCP before the next issue, you would see that you don’t have trouble to connect, but that the UDP port exhaustion is still present. But how come that the WMI subsystem eats all those ports? The clue is not on the machine but in the domain.
According to the Microsoft Premier Support, there is a bug under Windows 2016: when applying WMI Filtered GPOs, UDP Ports are not released enough by the Policy provider when using the WMIPRVSE process. Then you’re ending up in this situation. A work-around is to have other services relying on TCP (such as Kerberos with the proper registry entry), but a better work-around is to have the WMI process isolated for this consumption.
If you face this issue, the no-reboot solution is then:
- Connect to the machine using a PSSession
- Execute the following code to isolate the provider in its own process:
$a = [WMI]'root\policy:__Win32Provider.name="PolicSOM"' $a.HostingModel = "NetworkServiceHost:Debug1" $a.put() - Restart the WinMgmt service (Restart-Service WinMgmt -Force will do the trick as there are dependencies)
- No need to reboot to re-issue a RDP connection
- If you want to revert back to test the behavior, issue the following snippet:
$a = [WMI]'root\policy:__Win32Provider.name="PolicSOM"' $a.HostingModel = "NetworkServiceHost" $a.put()