Duplicate name exists error

coolsport00
coolsport00 used Ask the Experts™
on
Now, I'm pretty advanced I think on this subject (AD), but this particular issue has just got me baffled to no end! If I could give 1000pts I would! :)

Here's my AD environment & my issue - a simple single forest/domain, W2K3 SP2, 10 branch locations with sites/subnets configured for each. All run well...except at 1 branch. At this problem branch, everything is fine really, EXCEPT for the fact that upon bootup of my DC, I get the nice "Duplicate name exists on the network" error. Now, I certainly and by all means know what this is saying.....BUT, there is absolutely no device at this branch or on my entire domain with this same hostname. An extra caveat to note...the error only occurs at this branch on there subnet. We have different subnets (10.100.., 10.101...etc. This branch is a 10.108 subnet). If I place this server on a different subnet with its current hostname, it's fine. But, in the 10.108 subnet, I get this error. I've checked every PC, & printer at this location to verify they have different host names and they all do. I've run the "Find" feature in AD U&C and came up with NOTHING but this server name. When I ping this server name, it returns with it's current static IP address. If I rename the server and ping this problem name, I get no replies. We do not run WINS. Can someone direct me how to maybe run a query or something to find the problem? I've tried flushing the DNS cache on several machines and this server. Thing is, the server has been rebuilt and even replaced and still receive the error. When I did do a rebuild, etc., I ran the metadata cleanup NTDSUTIL and that didn't resolve it either.

And btw....this issue has actually been going on for over 2yrs!!!! (seriously; I inherited it..oh joy)

Thanks in advance!
~coolsport00-
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Commented:
http://support.microsoft.com/kb/248047

Sounds like you have metadata from that node.  Run DCdiag to see if there is any records of tombstones. It sounds like you checked DNS and AD.

Another possibility is both NICs have been registerd in DNS. Do you have a multi-homed computer that could be registering more than one set of DNS data?

Commented:
BTW:

This is what Microsoft had to say about it.
http://support.microsoft.com/kb/822659
Top Expert 2010

Author

Commented:
Thank you for the posts "Chief". I don't believe I have metadata.. DCDiag is fine. I have checked DNS/AD many times and am clean there. Have no multi-homed servers/PCs in our environment. As far as the MS article, I saw that some time ago, which prompted me to run  nbtstat...I found nothing. The MS article references using netdom for XP to do a rename...but that's not what I want to do. Let me say that yes, I could rename this DC to something else, but that isn't solving the root problem, which of course is a duplicate computer name somewhere seemingly only in this subnet. I'd like to somehow learn how I can find this PC with the same name as my DC and change its name. Thank you in advance.

~coolsport00
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Commented:
LET's NOT rename the DC:

I think you were on the right track with NBTstat.

WINS cache purge and LMhost files:
Try NBTstat -RR (This reparairs and refreshes the WINS cache). If this is truley a netbios problem, check your servers c:\windows\system32\drivers\ect\LMhosts file. You can open and edit this file by using a text editor, like notepad. Make sure the only address configured in there is the loopback address.

DNScache purge and HOST files
Simularly: Flush the DNS cache by going to the command prompt and typing IPconfig /flushDNS.
Also, check the c:\windows\system32\drivers\ect\hosts file and make sure nothing but the 127 loopback address is in it.

(MUP provider) You might have a cached MUP (multiple UNC provider) setting on the server. Rebooting the server doesn't get rid of these. So, maybe purging the MUPcache will remove this error: At the command prompt, you could try DFSutil /purgemupcache
__________________________________________________________________________
This is what I think your problem is. I think you have a multihomed domain controller. This is defined as a domain controller with two or more IPs. This could mean 2+ IPs on one NIC or 2+nics with IPs. If they are on the same subnet, bot NICs could be providing Netbios. So, you may get a "duplicate name exists" error because both NICs are saying "Howdy" when sending out netbios broadcast that say, "I am Here." Both IPs are picked up and you get "duplicate name exists" on the network.

Top Expert 2010

Author

Commented:
I will look at your suggestion a bit more tomorrow. One thing I can respond on is multi-homed. That can't be true. Why? As I originally posted, this error only happens in the 10.108 subnet. I have only 1 DC in that subnet. I have 1 DC in my other subnets (2 at my Main branch location). If I boot this server in any of those other subnets, I do not receive the dup name error.

Thank you for all your input "Chief". :)
Do you have any kind of smb gateway services running ? something similar to SAMBA on linux.
Top Expert 2010

Author

Commented:
No

Commented:
Do you have access to a tool to run a network trace of a bootup to see if it's really getting a conflict off the network, or if it's just something internal to the server?

Commented:
Coolsport:

According to the M$ article, this has to do with netbios names, not DNS.

Are you running WINS? If so, could this be a tombstoned WINS record or a left over WINS record. Those wouldn't show up on a DCdiag or netdiag test, I don't believe.
Top Expert 2010

Author

Commented:
Yeah...this really does has something to do with netbios. We're not running WINS (& I apologize, i hadn't attempted your previous post as yet...been away from the office). I ran many switches with the nbtstat util and came up empty. How do I find a tombstoned WINS record (even though we haven't ran that the past 2 1/2 yrs I've been here?

Thanks "Chief".
Top Expert 2010

Author

Commented:
"Dexro"...how do I do that? Again, this really can't be specifically server (only) related becuz I've rebuilt this server, and even replaced it at one point (but due to other issues, have since reinstalled the previous server). So, it's certainly something on the network, and even more specific, on this particular subnet ONLY. We don't run WINS on this subnet, nor the domain as a whole. The only thing we run on this DC is print services and DHCP.

Commented:
It might be more than you want to get in to.  If you have a team that supports the network directly, you might ask them about setting up a network trace.  

If you can recreate the error when the server is on-line, the easiest thing to do would probably be to set up Windows network monitor (serach microsoft.com for "network monitor" for the latest version download, or just install the built-in version from CD) and capture traffic that way.  If this only happens when the server is booting up, you might look at something like Wireshark (www.wireshark.org) running on another machine to trace the traffic.  

Once you have a tool set up to capture traffic, you repro the error, and then walk through the network trace packet by packet looking for evidence there of the error.

Commented:
http://compnetworking.about.com/od/windowsnetworking/f/duplicate_name.htm

Since everything I am reading on this subject leads to netbios, let's track down netbios records that are stored and cached on the server.

Wins/netbiosnames has many similarities to DNS/HostA records.

1) DNScache is like WINS cache. To delete Wins cache go to the command prompt and type NBTstat -rr

2) Client computers and servers have a C:\system32\drivers\ect\HOST file for DNS, and then a C:\system32\drivers\ect\LMHOST for WINS. You may want to remove all configured addresses except the 127 loopback address in the LMhost file. Or you could simply disable LMhost lookup.

3) The computer NetBIOS name is stored in the system registry at:Are there duplicate registry keys>
\CurrentControlSet\Control\ComputerName

4) If I remember right you can ping by hostname and it should resolve by hostname. Then, you can ping by hostname2 and it will supply the address to hostname2. Try that and see if you get a different resolution to the host IP.
_______________________________________________________________________________
5)  Do you have NetBEUI installed: I have read a post where NetBEUI was the culprite. They uninstalled NetBEUI and the problem went away. I am thinking you may have looked at this thread because you said you looked at printers.
http://forums.speedguide.net/showthread.php?t=65527&page=3

I was recommending you look for tombstoned WINS records. But, you haven't installed WINS and therefore shouldn't have a WINS database> (not having WINS narrows this down to pretty much any of the above:
http://technet.microsoft.com/en-us/library/cc759148.aspx
Top Expert 2010

Author

Commented:
Yes...everything I've researched leads me to believe it's netbios as well. But, this is NOT server-based. This server in question, if you recall, has been 1. rebuilt and 2. replaced with a different server. The problem is somewhere ON THE PARTICULAR SUBNET as this is the only place I get this error.

I tried deleting the cache, but only on the server; I guess I could try other workstations on this subnet. I checked most of their HOST/LMHOST file and they are clean.

NetBEUI can't be the issue because that protocol was discontinued with 2K3/XP (see: http://support.microsoft.com/kb/317507 and http://support.microsoft.com/kb/306059/). Pinging by hostname gives me the IP address of the server, which is correct. It doesn't give me the IP of the "duplicate" as well. My server is named "computer" (for posting purposes, keeping it simple here). Somewhere else ON THIS SUBNET ONLY I assume there is another computer name called "computer". So, I don't understand what you mean by pinging hostname then hostname2?

This is just ridiculous isn't it???

Commented:
I didn't expect this to be easy, as I have seen your skills in action. Knowing that you have been trying to track this down made me anticipate this one will be tricky.

Since these are most likely netbios broadcasts, have you considered something like wireshark to see who is spitting out that name?
Top Expert 2010

Author

Commented:
Hmm...not sure if that'll work. My netwk engnr uses that on occasion here at my org, and he says that it probably won't work as it captures things after getting to the OS, whereas this error occurs upon bootup. I'm not sure NETBIOS/this error is a broadcast type is it?

Commented:
Yes...everything I've researched leads me to believe it's netbios as well. But, this is NOT server-based. This server in question, if you recall, has been 1. rebuilt and 2. replaced with a different server. The problem is somewhere ON THE PARTICULAR SUBNET as this is the only place I get this error.

Then, this almost has to be a conflict with the browselist. The old DC that this server replaced may have a cached record on the server that holds the browselist. That should be your PDCe.

Go to the command prompt and type. Browstat /status. That should give you a list of master browsers and backup browsers for that site. Then, go to each one of those that carry the browselist and type NBTstat -rr. You may have to do this twice. I have seen NBTstat -rr not work the first time.




Go to the PDCe and the backup

Commented:
If the above doesn't work, with this problematic server unplugged, ping the name to see if it resolves to an IP address. If so. Go to your browser and look at the C$ admin shares of that comptuer that still exists to see if you can figure out what computer it is.
Top Expert 2010

Author

Commented:
I have 10 DCs, but only 1 (at our main branch) hosts all FSMO roles. So, run it there? Then run nbtstat on the servers that show what? I'm sorry "Chief"...I guess I need a bit more clarity on running this as I've never run browstat before.

Thanks a bunch for the continued support!!! It's MUCH appreciated!
Top Expert 2010

Author

Commented:
You know something I also forgot to add...when I go to the NIC on this server, I can uncheck Enable LMHOSTS lookup and the error doesn't happen. At least I think that was what I did (I did this a couple mos or so ago). But, that would only be a band-aid fix; I want to get to the root of this, ya know? What are the ramifications of leaving that setting unchecked? I assume nothing since we don't run WINS

Commented:
Well, there is the issue. There are two LMHOST records. If you enabled LMHOST lookup, your server will look in it's LMHOST file prior to looking for a WINS server.

There might be more than one LMHOST file. The one we want to edit, I think, is in C:\Windows\System32\drivers\ect\LMHOST.sam. You can edit it with a text editor.

Remove all records, including the loopback address of 127. I just looked at mine and they are no addresses in those.

LMHOST files were used if a WINS server was needed, but WINS server was not available. It is similar with DNS. HOST files can be manually configured if a DNS server is needed but not available on that site. SINCE YOU DO NOT NEED WINS, (unless you want both site A, and B to combine the browselist), then you don't need these LMHOST files.
Top Expert 2010

Author

Commented:
The server has no entries...and I checked several PCs earlier today (am at home now) and they were all empty as well. I didn't make it through all PCs, but could that be it...a PC with an entry in it conflicting with this server host name?
Top Expert 2010

Author

Commented:
All PC LMHOST files are "clean"...no entries; the HOST file only has the loopback addy. I'm stumped. :(

Commented:
On top of these "most common causes" of your error>
http://windowswideopen.com/blog/2007/09/10/event_id_7023_-_a_duplicate_name_exists_on_the_network_split_registration_behavior/

I also heard host based printers may cause this problem. Host based printers may be registering as the host computer name. I will have to look up the fix. Please review the above article to see if this resolves your problem, while I look up HOST based printer problems with Netbios registration.
Top Expert 2010

Author

Commented:
I don't even get an event in EV. I assume cuz this is error happens upon bootup. I tested the LMHOST setting again and that actually doesn't rectify this error. So I re-enabled the LMHOST setting and instead selected to "Disable NETBIOS over TCP/IP" and that is what makes the error not appear.
Commented:
I am working on two posts at one with a similar issue:
 (coolsport and completefear)
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/2003_Server/Q_23676145.html

I found a site that goes over some possibilities. There are two links you should look at> (duplicate name issue, and duplicate name exists).

http://www.chicagotech.net/netbios&wins.htm#Duplicate%20name%20issue

Futhermore, this could be a DNS CNAME issue on your DNS server. Or it could be well as a NETBIOS ALIAS issue, (with a wins server only). In other words, it doesn't have to be
for DNS CNAME: http://support.microsoft.com/kb/281308
For Netbios Alias: http://www.tek-tips.com/viewthread.cfm?qid=785689&page=10
________________________________________________________________________________
I would like to go over the chronology of a DNS query and how this is very similar to a WINS query. This helps track down records problems.

The client will try to resolve the query by itself:
1) The second place a client looks for is a cached entry. (To determine if this is the case, go to the command prompt of the client and type IPconfig /flushdns.) (For WINS cach, type NBTstat -rr)
3) Then if your client doesn't have the cached entry, it will look at the client's C:\Windows\system32\drivers\ect\Host file for resolution. (For WINS, you comptuer looks in the C:\Windows\system32\drivers\ect\LMHOST file(You can look at and edit the host file with word pad. Check and see that there are no entries, except 1.0.0.127 local host file in that file for the HOST file and no entries in LMHOST. These files are used if you don't have a DNS server or WINS server respectively. They can be configured to maintain a list of computers you want to contact via a DNS query or WINS query.)

After the client can't determine its own DNS query it will look at the prefered DNS server: (To determine the prefered DNS server, it will be the first on on the list in an IPconfig /all of the client). (For WINS, it will be the preferred WINS server)
1) The first place the server looks for DNS records is its own DNS cache. (You can flush the cash by again going to the command prompt and typing ipconfig /flushdns) (For WINS it you can flush it by purging the Server's WINS cache by using NBTstat -rr)
2) Then the server will look at its own C:\windows\system32\drivers\host file. (for WINS it will be the C:\windows\system32\drivers\LMHOST file
2)Then, the DNS server will have a list of Host A records, Alias records also known as CNAME records and SRV (service)records. (For WINS, it will look at the WINS record, Netbios Alias record, and other server records)
3) If the DNS server can't find the Host A, it will make an attempt to contact an outisde server. There are two types of contacts. One is a recursive and the other is an iteration query. There are also two types of lists to contact the outside server. One is called a forwarder and the other is called roothints.
---brief explaination of each:
---Recursive lookup: A recursive lookup is handled by the server. It will go out to a distant server and try to resolve DNS queries that it can't do on for the client. In other words, if the DNS server can't find an internal address, it will go out to other servers and ask them to look for it. If a resolution is provided. The resolution will be passed down to the client from the server. It is recommended to turn off recursive lookups for security reasons and performance reasons.
--Iteration: Iteration is done when the server can't resolve the query and tells the client, "I can't do it, ask another DNS server." The resolution comes from the remote server, not the local server. So, this is basically passing the buck.
---forwarders: forwarders are manually configured DNS servers that your server will forward queries to if your server can't make the resolution. (most folks configure the ISP's DNS server as the forwarders)
---Root Hints: Root Hints are a list of public DNS servers that your server forwards DNS queries to if your server can't resolve the DNS query

WINS is not needed to contact the web so, it just contacts other servers to see if it can find the netbios names of remote sites.

NOW, here is the issue:
For COOLSPORT, you disabled all LMHOST lookups and purged the WINScache until your eyes turne purple. You may have your computer name wrong in registry as the above article explained. Since you disabled Netbios, the CNAME records in DNS are not your issue.

Coolsport, you could use NBTSTAT to further troubleshoot.
You can look at the local computer's cache by: NBTSTAT -c
You can look at the remote computer's name table: NBTSTAT -A xxx.xxx.xxx.xxx
You can list the local netbios names: NBTSAT -N (These machines host your browse list and if you go to those computer and check the name table, it might show you the conflicting computer's IP.)
If you see a 03H in either of these, that is your duplicate computer. The ability to turn off netbios over TCP/IP and still not get this error tells me the netbios broadcasts are causing the problem. So, you may have a nic protocol that is spitting out the netbios broadcast twice, like NWlink.

For COMPLETEFEAR, we have a lot more things to check since you have WINS. You could have a computer on a remote site with the same name. You could have an alias record in either DNS (CNAME reord), or an alias in WINS (NBALIAS) that leads to the same server. You may have a multihomed server and both nics are being seen in netbios, (so you may have to disable netbios on one nic). You may have your registry key that has the wrong name for your computer. You checked the LMhost file on your server. You flushed your WINS cache on the server. I have heard of host based printer causing a conflict, but can't find the information on this. I will continue to search.

For both of you, see if you have WINS client enabled on the server.


DNS-query.gif
Top Expert 2010

Author

Commented:
"Chief"...no dice :(
I ran nbtstat -c and it displayed 2 devices (dev1234    <20> UNIQUE     10.10.10.10    123)
OK...as I'm typing this, I did another NBTstat command that is interesting. Let's use my name ID on here to refer to the conflicting/duplicate hostname to ease confusion.
I ran NBTstat -a  coolsport00 (using -A you have to use the IP, which I'm not having a problem with; only the hostname so I used the -a switch). What I got displayed was the following:
C:\NBTstat -a coolsport00
Node IpAddress: [10.10.10.10]
NETBIOS REMOTE MACHINE NAME TABLE
NAME               TYPE            STATUS
COOLSPORT00  (00) UNIQUE  REGISTERED
NTLXVIDEO       (00) GROUP   REGISTERED
MAC = XX-XX-XX-XX-XX-XX
Now, I have NO idea what NTLXVIDEO is. It's not the name of any host on our network or subnet. But, it seems (maybe) this is our problem?...not sure. And, the MAC addy is not the MAC of "coolsport00" (the server name). So, I find this quite interesting.
Top Expert 2010

Author

Commented:
And, when I run NBTStat -c  it actually displays that "device" (or whatever it is)
NetBIOS Remote Cache Name Table
NAME             TYPE              HOST ADDRESS       LIFE
NTLXVIDEO     (00) GROUP    10.10.10.11            123

Commented:
Well, I think we found it!!!

I looked up NTLXVIDEO, (google search):

The NTLXVIDEO is a component of American Dynamics Software Development Kit:

So, I looked at the manual for that:
http://www.americandynamics.net/WebApps/getDocument.aspx?filename=8200-0755-00%20A0%204.1%20API%20SDK%20User%20Manual.pdf

Where it says in the system overview:
That the device is a DVR and storage server for video data.  
The overview also says it is network compatible.

That could mean your CCTV (closed circuit TV or security camera computer/DVR) may have the same name as your server.
Top Expert 2010

Author

Commented:
Exactly. I spoke w/my director who is mostly responsible for this setup throughout our org (including the branch locations) and he mentioned this could be the case. They actually are not part of our domain but are on our network. A vendor actually is responsible for these devices. So, that being said, I will look at the "naming" on these DVR devices at this branch. Until I can get out there to verify, I will keep this open. THANKS A BUNCH CHIEF! :)

Commented:
Coolsport:

Since this was a netbios problem. I'm thinking this has to be the local CCTV system. Netbios is not routeable without WINS. In disabling the netbios over TCP/IP, you told me this is local because Netbios resolves off broadcasts. So, focus on your local CCTV (security camera) system.
Top Expert 2010

Author

Commented:
What I actually needed to run was "NBTSTAT -a problemhostname". ChiefIT commented on a lot of switches, but just had the wrong one displayed; BUT, he certainly got me pointed in the right direction.

Since I'm still waiting on the Branch Mgr to get in touch with me about this, I'm not going to keep this open, since it may be a while before I can actually check what I need to. If I need to re-address this, I'll open another question and reference this post. Thanks "Chief"!!!
Top Expert 2010

Author

Commented:
In my "closing post", I meant to say that I'm going to CLOSE this question....(not keep it open). Ooops :)
Top Expert 2010

Author

Commented:
Hey "Chief"...just wanted to give you an update (finally) on this, even tho this is closed. This WAS due to the DVR equipment as we assumed it was. I had the ADT team go to the branch and rename both DVRs. I haven't had a chance to actually be at the branch to reboot the server to see if the error has gone away, but I certainly assume so since 1 of the 2 DVR names were called the same as my server.  Thanks again for all the work/troubleshooting!

Regards.

Commented:
Excellent:

As a side note, as soon as I saw your name on this, I knew this wasn't going to be easy. I think you have excellent skills and hope to see you around more often.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial