2015-09-29
A Case Study in How NOT To Process Orders
Home »Windows»Multiple Hostnames
2015-09-29
A Case Study in How NOT To Process Orders
2014-02-08
Reading email SMTP headers to trace the origin of the message.
2014-02-07
Rants about the pains of performing what should be a simple package upgrade.
Your IP address is
3.238.111.130
Recently, there's been a server replacement project going on. All the old Windows 2000 Servers have been replaced with Windows Server 2003, and they've all got new names.
Therein lies the problem. If you migrate all your file shares from 'server1' to 'server2', you're going to end up having problems. You can change login scripts to reflect the new path for mapped drives - but what about drive mappings that users make themselves? What about applications with various UNC shares or hostnames or even IP addresses configured in a .INI file on each machine (I'm looking at you, Clinisys)? What about some weird and wonderful applications you've never encountered before, and applications which don't have easily mass-editable configuration files (I'm looking at you, Borland Paradox IDAPI32.CFG) or store the path to other data files in some horrid uneditable Borland database table (I'm looking at you, DGL and Vizual Business Tools)?
Well, we could get all these wonderful 3rd party suppliers to send a consultant to each site to reconfigure the applications, but that's just the ones we know about, and these people charge upwards of £500 per day.
Instead we're going to create a CNAME record to redirect requests for 'server1' to 'server2'.
Open up your DNS MMC Snap-In, and create a CNAME record.
Remember you need to give the fully-qualified domain name for the target.
Once you've done this, you should notice that pinging server1 will result in a reply from server 2, like this:
Ping server1
Pinging server2.example.local [192.168.79.2] with 32 bytes of data:
Reply from 192.168.79.2 bytes=32 time=100ms TTL=123
...
Unfortunately, that's not all you need to do. If you try to open a path such as \\server1\share, you'll find you're greeted with one of the following problems:
Or you might see this in your System log:
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
User: N/A
Computer: SERVER2
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/server2.example.local. The target name used was cifs/server1.example.local. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (EXAMPLE.LOCAL), and the client realm. Please contact your system administrator.
This is because Windows Servers like to be called by their own names, or by their IP addresses. In order to get around this, you need to add a registry key to disable 'StrictNameChecking' in the file server.
The key you need to add lives at:
HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
You'll need to add a new REG_DWORD value, called DisableStrictNameChecking, with the value set to 1.
Once you've done this, you'll need to restart the Server service on Server2, so best do this whilst nobody's using it.
If you're still getting one of the problems above, it could be caused by the fact that you still have a computer account in your domain for 'Server1'. You'll need to delete this, and wait for the change to replicate.
If Server1 was a domain controller or an Exchange Server, make sure you've properly dcpromo'd it out of AD and/or completely removed Exchange from the server, and that the changes have had time to replicate before you add an alias for it. If you don't do this, you'll end up manually clearing things up with ADSIEdit and swearing a lot.
If you're still using lots of WINS on your network, you might also like to 'tombstone' the records for server1 before you put in a DNS record that contradicts WINS.
CNAMEs have been picked in this example as a temporary solution. You should ideally not rely on them for too long. They're very handy to have if you're replacing a server in a hurry, and can't reconfigure 500 PCs with new addresses in a hurry.
The problem with CNAMEs is that every time you try to find the IP address for one, you end up making two DNS lookups instead of one.
Here's a grossly-simplified DNS conversation:
PC: Dear DNS server, what is the address for server1.example.local?
DNS: Ah! It's the same as the address for server2.example.local!
PC: Okay, smartarse - what's the address for that, then?
DNS: It lives at 192.168.79.2
PC: Why didn't you just tell me that in the first place???
And the answer to that question, is because that's not how CNAMEs work.
You could always just create an 'A' record instead of a CNAME, which would point the hostname 'server1' to the right IP address, but CNAMEs tend to be preferred for temporary fixes, as they usually stick out like a sore thumb in your DNS, and it's quite easy to see which server they're sending traffic to.
It's also worth noting that CNAMEs are frowned upon in Internet circles for use in things like MX records, for the same reasons outlined above. The use of CNAMEs in MX records is discussed in RFC 974.
If you're getting rid of the old server, you might like to think about assigning the old server's IP address to the new server. Fortunately this has been very easy to do since the days of Windows NT 4.
In your network connection properties, you'll find the ability to add extra IP addresses in your advanced TCP/IP properties. Just add in the extra address, and within a few seconds, Windows will begin to ARP for both addresses.
That's most things sorted now, with one glaring exception: Web Services.
If this server is hosting various IIS web sites (or Virtual Servers if you're running Apache), you'll need to tell IIS which names it should be responding to. This is because servers can contain multiple web sites with a single IP address. In order to work out which page somebody is looking for, the server looks in the HTTP HOST header.
In your IIS Manager MMC Snap-In, in the web-site properties, you can open the 'Advanced Web Site Identification' window, and add as many hostnames or IP addresses as you'd like.
Remember that this article has only mentioned TCP/IP and DNS. If you're still using NetBEUI or IPX/SPX (why?) as your default protocol, then none of the above is going to be of much use to you, unfortunately. I also haven't mentioned WINS, although you really shouldn't need to define any static WINS records if you're doing it in DNS.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.
Design by GetTemplate