Of ~140 PCs, a few PCs (no determined pattern) are consistently unable to resolve the AD DS domain name during boot and intermittently unable to resolve AD DS DNS names post-boot. This can be temporarily resolved by restarting the Windows service DNS Client / dnscache and/or rebooting the PC until it works.

My diagnostic progress:

  1. Once the resolution is in place, both domain controllers are contactable (verified in multiple ways) and Group Policy does apply but some policies require a reboot, hence this problem.
  2. The NIC's DNS configuration (servers, etc) are correct.
  3. Command nltest /DSQUERYDNS outputs I_NetLogonControl failed: Status = 50 0x32 ERROR_NOT_SUPPORTED.
  4. Command Test-ComputerSecureChannel outputs True.
  5. Updating the network device Realtek PCIe GBE Family Controller's device driver from version 7.86.508.2014 / 2014/05/08 to version 7.107.323.2017 / 2017/03/23 didn't make a difference.
  6. \\<%logonServer%>\NETLOGON\ is accessible.
  7. Enabling local policy Computer Configuration\Policies\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon didn't make a difference.
  8. No traffic is blocked by the firewall during reboot.

As far as I'm aware, this only started happening since the site migration onto a new, restricted, VLAN-ed network so I can't help but suspect the Sophos XG 210 UTM but that doesn't make sense because it was firewall- / routing-related then I'd expect the problem to be much more consistent and widespread.


Update 2017/07/07 16:26

My diagnostic progress:

  1. Updating the Sophos XG firmware from version 16.05.3 MR-3 to version 16.05.5 MR-5 didn't resolve the problem.
  2. Created a network firewall rule to allow LAN-to-any, PC's IP address-to-any using any ports / services didn't resolve the problem.
  3. Disabling IPv6 on the NIC and rebooting didn't resolve the problem.
  4. Executing elevated command netsh int ip reset reset.log and rebooting didn't resolve the problem.
  5. Logging on using a freshly-generated local user profile didn't resolve the problem.


Update 2017/07/12 11:23

The problem has changed on the test PC that I'm using. Post-boot, pinging the AD domain name and any server hostname successfully resolves and transmits but RSoP still reports that computer-side (not user-side) Group Policy Infrastructure failed to apply because The specified domain either does not exist or could not be contacted.

My diagnostic progress:

  1. Reconfiguring the NIC setting almost the exact same configuration (IP address, subnet mask, default gateway, and DNS servers) statically, rather than dynamically, consistently resolved the boot, computer-side Group Policy problem on two of the affected PCs. I'm going to leave this static config in place for a few days to see if it resolves the intermittent DNS resolution problem too.


Update 2017/07/13 13:28

The intermittent DNS resolution problem recurred

My diagnostic progress:

  1. Pinging FQDNs with trailing .s didn't make a difference.
  2. Reconfiguring the NIC setting the exact same configuration (IP address, subnet mask, default gateway, DNS servers, and connection-specific DNS suffix) statically resolved the problem, albeit probably temporary.
  3. I've posted a V7 USB3-to-Ethernet adapter to test whether it's an incompatibility between the onboard NIC and the switches or something. Results tomorrow.


Update 2017/08/03 14:51:

10+ hours of diagnostics later, the root cause seems to be MAX RemoteManagement's / MSP Remote Management's RMM agent (likely sub-component Advanced Monitoring Agent Network Management) as we uninstalled it on a few affected PCs on 2017/07/25 and the problems haven't recurred since.

  • What event id's did you get? Maybe you have a problem with autoneg, what says the switchport? Is portfast enabled?
    – duenni
    Jun 29 '17 at 9:14
  • @duenni The event IDs that I took notice of were 8021, 1055, and 5719. The switches are actually managed by a different third-party so I don't have much information on that but they said that they can't see anything untoward in the logs or configuration. Jun 29 '17 at 9:45
  • Check that your dhcp lease time matches with your scavenging settings. Your DNS server may not be allowing updates for a certain period of time as well. Are the dns servers on a different VLAN than your PCs? Are VLANs being allowed to communicate with each other?
    – veel84
    Jun 29 '17 at 9:45
  • @veel84 This particular PC actually has a DHCP reservation. Yes, the DCs and PCs are on different VLANs but the firewall allows the required ports as confirmed with packet captures. Jun 29 '17 at 9:46
  • Can a PC with the problem ping the IP of DNS? If it can Open a telnet session on one with the problem to check that the DNS port is accessible. Or use nmap on a problem pc to scan DNS for open ports.
    – veel84
    Jun 29 '17 at 9:48

I'm fairly confident in saying that this was caused by MAX RemoteManagement's / MSP Remote Management's RMM agent as uninstalling it has resolved a wide variety of DNS- / network-related problems on different PCs in different locations.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.