Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, July 19, 2016 3:42 PM
Hi,
I have a problem with three domain joined Windows 10 Pro systems that were all upgraded from either Windows 8.1 Pro or Windows 7 Pro. I have 10 other domain joined Windows 10 Pro systems that I upgraded from Windows 7/8.1 and they don't exhibit the problem.
The primary DNS server is a Windows Server 2012 (192.168.1.3). The secondary DNS server is a router (192.168.1.1). The primary DNS server is intended to locate systems on the domain with the secondary DNS server to resolve external names.
The problem is that the three computers will lose the ability of using the primary DNS server to resolve names. Instead, the systems use the secondary DNS server which ends up with resolving to some public IP address. What's important to note is that the other non-affected systems can resolve the name using the primary DNS server. So, I know that the issue isn't with the primary DNS server and it's localized to the three systems. I detect this DNS issue by running "ping local_system" where the local_system is the name of one of my machines in the domain.
When I run ipconfig /al on the affected systems, I can clearly see that the DNS entry are in the correct order of192.168.1.3 followed by 192.168.1.1.
I can easily fix the issue on the affected systems by opening up a command prompt with administrative privileges and running the following:
ipconfig /flushdns
ipconfig /registerdns
ipconfig /release
ipconfig /renew
NETSH winsock reset catalog
NETSH int ipv4 reset reset.log
NETSH int ipv6 reset reset.log
Exit
Reboot system
However, running that is only a temporary fix. After 1, 2, or 3 days (seems random), the systems will lose their ability of using the primary DNS server. Also, the systems don't even need to go through a reboot cycle to lose the ability...though they do go through a sleep cycle. As expected, on an affected system, if I do a reboot without running the above commands, the problem persists after a reboot.
I've never had issues like this on any of the three systems before the Windows 10 Pro upgrade (I upgraded them last week), so, any help in enabling a permanent fix would be appreciated!
Thanks
All replies (5)
Wednesday, July 20, 2016 6:28 AM
Hi growler1,
The main issue is that only specific Windows 10 machine won`t use the primary dns server, right? Are there any related error messages recorded in the Event Viewer? Is it available to ping the primary dns server when the issue occurred?
Please take the following steps to have a test.
1.Reinstall the network adapter driver from the device manager.
2.Run the built-in troubleshoot tool to have a diagnostic.
Control Panel\All Control Panel Items\Troubleshooting\All Categories\Network Adapter
3.Try to remove the machine from the domain and re-add it to the domain to have a test.
Best regards
Please mark the reply as an answer if you find it is helpful.
If you have feedback for TechNet Support, contact [email protected]
Friday, July 29, 2016 8:33 PM
> The main issue is that only specific Windows 10 machine won`t use the primary dns server, right?
Correct. Only Windows 10 machines. All machines were upgraded from win7 or Win8.1.
> Are there any related error messages recorded in the Event Viewer?
I only see LSA (LsaSrv) warnings. "The program svchost.exe, with the assigned process ID 1204, could not authenticate locally by using the target name HOST/.. The target name used is not valid. A target name should refer to one of the local computer names, for example, the DNS host name.
Try a different target name." But, I see many of these warnings when there are or are not issues with using the primary DNS server.
> 1.Reinstall the network adapter driver from the device manager.
I did the above on all systems.
> 2.Run the built-in troubleshoot tool to have a diagnostic.
Control Panel\All Control Panel Items\Troubleshooting\All Categories\Network Adapter
I did the above and no issues were found.
> 3.Try to remove the machine from the domain and re-add it to the domain to have a test.
I did the above. Also ensured that the server was rebooted.
Since doing the above, I've had three of the eight Lenovo-m72e, one of two Lenovo-m83t, and a Lenovo-T430 stop using the primary DNS server (Windows Server 2012). The Lenovo-m83t was affected about 6 hours after I did the 3 steps above. The Lenovo-m72e took approximately 70 hours. In fact, one of the Lenovo-m72e I had checked at 6am in the morning (I RDP'ed into the machine to check) and by 7am, it had lost the ability to use the primary DNS server. In between that time, the system was not restarted and the system had not gone to sleep/hibernate. As mentioned, all of these machines were updated from Win8 to Win10.
Anything else that I can try? I'm either contemplating rolling all of upgraded systems from Win10 back to either Win7/8 or creating a batch job that runs every morning to determine if the system has stopped using the primary DNS server and then having the system applying the fix.
Monday, August 1, 2016 9:32 AM
Hi growler1,
There is a possibility that local DNS server was slow responding to a query and the second one responded faster and the client switched to using it which is expected operation. The best troubleshoot method is to capture the network package to analyze the issue.
If it is possible, please try to set to only use the local DNS server.
Best regards
Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Friday, August 5, 2016 2:52 PM
I reconfigured the DHCP server on the server to only use itself as the local DNS server. So, when I now log into any of the workstation in the domain, there is only one local DNS server shown when running ipconfig /all (192.168.1.3). .
Each workstations were then rebooted. After about 36 hours, the Lenovo-T430 lost it's ability to resolve domain joined workstations/server. The remaining systems after 60 hours are okay. So at least for one system, the fix didn't work.
Partial output of ipconfig /all shown below:
C:\WINDOWS\system32>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : LENOVO-T430
Primary Dns Suffix . . . . . . . : mypublicdomain.ca
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : mypublicdomain.ca
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : mypublicdomain.ca
Description . . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
Physical Address. . . . . . . . . : *deleted*
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : *deleted*
IPv4 Address. . . . . . . . . . . : 192.168.1.105(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Friday, August 5, 2016 7:05:29 AM
Lease Expires . . . . . . . . . . : Saturday, August 13, 2016 7:05:29 AM
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.3
DHCPv6 IAID . . . . . . . . . . . : 237556292
DHCPv6 Client DUID. . . . . . . . : *deleted*
DNS Servers . . . . . . . . . . . : 192.168.1.3
NetBIOS over Tcpip. . . . . . . . : Enabled
Tuesday, August 23, 2016 1:05 PM
So, it turns out that the issue of resolving internal domain joined computer names is functioning even on those computers that can't resolve the server name that is configured as the primary DNS server. It's only the server name itself that can't be resolved! So every other domain joined computer I can ping from these 'affected' systems. Go figure...
So, the issue is still unresolved. To workaround it, what I did was to create a powershell script that runs at startup. The script checks to see if it's run more than 3 times consecutively and if it detects that, it aborts. If it hasn't run 3 times, it pings the primary DNS server and if it pings it, the counter is reset and the script ends. If the the server can't be pinged, it runs the commands at the top of the this thread, writes the output of the ping check to a log file on a network shared drive/folder and then exits. I have every Windows 10 domain joined computer wake up early in the morning and about an hour later, the computers restart so that this ping check script can run. Rational for doing it this way is that if a user finds that their system can't find the server, it only takes a restart of the system to apply the fix. Writing the output to a log file on the shared folder is handy as now I can definitely see how this issue is affecting different machines at least on a daily basis.