I've always preferred to use hostname for things like network shares, SQL Server instances, etc. I usually find hostnames to be more descriptive and easier to remember.

However, recently one of our file servers died. It's IP was tied to the network adapter on another server, shares were re-created and almost all jobs that used IP address kept working as nothing happened.

For the jobs where I used hostname I had to go through several dozen of configuration files to change hostname and next day I found out I actually missed a couple. Note that this time I actually used IP address so that when replacement server is online I wouldn't have to change anything again :D

I realize there is probably a way to create another DNS entry in domain controller and/or network router (instead of re-assigning IP to another server) but it wasn't done that way in this case (not my decision).

Are there some kind of recommended guidelines about how this should be done? What do you do in your environment?

  • I'm a little unclear, but it sounds like you're not using AD; is that correct? If that's the case, then that would be your recommended guideline: implement AD, correctly. – Adrien Apr 8 '13 at 17:49
  • We are using AD. – Joe Schmoe Apr 8 '13 at 17:53
  • Then how are you not using DNS? – Adrien Apr 8 '13 at 17:54
  • We are using DNS. That is it is implemented on domain controller. I can't explain why other people still use IP addresses instead of host name. – Joe Schmoe Apr 8 '13 at 17:57
  • Yeah, see @Chopper3's answer. Your problems are deeper than are going to be fixed here ... – Adrien Apr 8 '13 at 18:00

In the case of file servers like you mention, you should be using DFS Namespaces, even if you only have a single file server. This will allow your shares to be referenced by \\domain\share instead of \\server\share. In the event of a failure, you just restore the files to another server and add it to the namespace in place of the original server. The path doesn't change, since it's domain-based.

It also makes file server migrations super easy.

In your case where you had a failure and didn't already have DFSN configured, you should have disabled strict name checking, created a CNAME in DNS with the name of your dead server and point it at the A record for the new server (or just create an A record), and continued happily on with your day.


The problem probably wasn't the name or the ip address. If you assigned the ip address to another server then any calls to the failed server name should have resolved to the ip address re-assigned to the replacement server. The problem was more than likely due to strict name checking, which means that the replacement server didn't answer authoritatively for the failed server name, which can affect network share access and SQL server access.

Q: What IP address does failed_server resolve to?

Answer from DNS Server: failed_server resolves to x.x.x.x

Q: What MAC address is x.x.x.x at?

Answer from Replacement Server: x.x.x.x is at xx-xx-xx-xx-xx-xx

Q: OK. Can I access the share at \\failed_servername\share

Answer from Replacement Server: I'm not failed_server, sorry.


  • Oh, I see. So what you are saying is that re-assigning IP is still recommended way to go in conjunction with using using the same host name ans changing that DisableStrictNameChecking registry key? Did I get this right? And the reason it fails with default settings is because MAC address didn't match? – Joe Schmoe Apr 8 '13 at 18:06
  • I don't see how your comment to Chopper makes sense. When you add the IP of the old server to an existing server, that server is going to perform a secure dynamic update and register that IP address under its hostname. The old A record will be around until it is scavenged as well. Either way, without creating a CNAME or A record with the old name pointing to the new name, you won't magically get to the new server. Have I misunderstood something you've said? – MDMarra Apr 8 '13 at 18:19
  • What you did by re-assigning the ip address is a perfectly good method and is also the easiest and preferred (IMO) method. The DNS name to ip address resolution worked fine and the ip address to MAC address resolution worked fine but Windows says "I'm not Failed_Server". That's what the DisableStrictNameChecking registry key is for. It allows the replacement server to answer for the Windows computer name of Failed_Server. – joeqwerty Apr 8 '13 at 18:19
  • So is setting DisableStrictNameChecming to 1 a recommended setting? The problem I see with this is that one needs to reboot file (or SQL) server which is never desirable. I would prefer something done, say, on Domain Controller that also wouldn't require a restart. – Joe Schmoe Apr 8 '13 at 18:22
  • MDMarra - With all due respect, you know what I'm saying makes sense but you've rightly pointed out something I missed. It's not that my answer doesn't make sense, it's that I've left an important piece out of it. That being said, it doesn't matter if the new server registers the ip address with its name as long as the old server A record remains intact. What you correctly pointed out is the fact that if scavenging is enabled on the DNS server and the zone then the old server name is going to be purged, which is what a static A record or CNAME record will address, as put forth in your answer. – joeqwerty Apr 8 '13 at 18:27

Are there some kind of recommended guidelines about how this should be done? What do you do in your environment?

Yes, always use DNS/hostnames where possible, anything else, if done properly, is folly.

I realize there is probably a way to create another DNS entry in domain controller and/or network router (instead of re-assigning IP to another server) but it wasn't done that way in this case (not my decision).

This is the way way to do it, generally in a Windows world by using Active Directory - if it requires some rework by these other people then so be it, if they give you any trouble tell them that they need to catch up with the '90's as anything else got old way before then.

  • Do you mind pointing out for me where on Domain Controller one would create new DNS entry? Is there just one way to do this or multiple? Thanks. – Joe Schmoe Apr 8 '13 at 17:55
  • You don't need to create a new DNS record. See my answer for why. – joeqwerty Apr 8 '13 at 17:56

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.