Posey's Tips & Tricks
How To Troubleshoot Bogus Duplicate Computer Name Errors
Brien troubleshoots how to fix a naming error when the error is the actual problem.
A couple of weeks ago, I upgraded some of my lab servers to Windows Server 2016. Although the upgrade process seemed to work flawlessly, my hectic schedule prevented me from doing an exhaustive post-upgrade review until a few days ago. I won't bore you with all of the details of my review process, but there was one step in the process that yielded some unexpected results.
I wanted to check the server's System log to see if it contained any serious errors. I therefore opened the Event Viewer, clicked on the System Log and then used the Filter Current Log option to show any errors that had occurred. Most of the error messages were no big deal, but surprisingly I found numerous instances of NetBT error 4319. A closer examination of this error revealed that the system had detected a duplicate computer name somewhere on my network.
My immediate assessment was that the error message had to be erroneous. I work out of my home and only have about a dozen physical and a few dozen virtual machines on my network. I am the only one who ever makes any configuration changes, and I knew that I had not renamed any computers lately. Besides, the computer name (Hyper-V-2) has been dedicated to a specific physical server for the last five years.
I knew that the error was false, but I also knew that I needed to verify that no computer name conflicts existed on my network. I was also going to have to find a way of making the error message go away.
My first step in the resolution process was to take a look at the event properties. As you can see in Figure 1, the Event Properties dialog box indicates that a duplicate name has been detected on the TCP network. It also confirms that the server's name is Hyper-V-2.mgmt.com, which is exactly what it is supposed to be.
[Click on image for larger view.] Figure 1. Windows indicates that a duplicate computer name exists on my network.
If you look at the event description in the figure above, you will notice that it says that the IP address of the computer that sent the message is in the data, and that you can use nbtstat -n to see which name is in a conflict state.
I therefore opened an elevated Command Prompt window and executed the nbtstat-n command. Upon doing so, I was presented with a list of three occurrences of the computer name that was in question. Each of these occurrences was listed by network adapter name and by IP address, as shown in Figure 2.
[Click on image for larger view.] Figure 2. This is the information that was returned by the nbtstat command.
As I looked at the information in the figure above, two things quickly became apparent. First, the last address on the list was the server's own IP address, so that listing wasn't an issue. Second, the other two IP addresses that were shown are part of my DHCP address scope. Clearly, these addresses were not statically assigned.
Still wondering how I could have a computer name conflict, I entered the IPConfig /all command. This command displays an exhaustive list of the computer's IP address configuration. The resulting data confirmed that all three of the IP addresses that had been cited within the nbtstat results were assigned to the local server. In other words, the server has three network adapters, each of which has its own unique IP address. For whatever reason, Windows did not like the fact that my server had three network adapters.
Of course it is totally normal for a physical server to have multiple network adapters, so I wasn't completely sure why an error was being triggered. As I further considered the problem, I began to think about how the computer name is used within the Windows networking stack. To make a long story short, I traced the problem to the File and Print Sharing for Microsoft Network component, which you can see in Figure 3. This component was enabled on all three of my network adapters. Disabling File and Print Sharing for Microsoft Networks on all but one of my network adapters caused the error to go away.
[Click on image for larger view.] Figure 3. Disabling File and Print Sharing for Microsoft Networks on all but one of the server's network adapters fixed the problem.
As you can see, there was a simple fix to the problem. Even so, I had never seen this particular issue before, so troubleshooting the problem took some time.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.