In order to simplify this case, I've reduced the number of objects. In this example, there are 4 servers and 2 clients. The DNS/WINS system is Windows Server based and replicated between 1 other domain controller. The situation requires the retirement of one server and all of its shares migrated to another server. Specifically, the need for the DNS redirection is based on the requirement (the problem) that there are hundreds of files (Excel etc) that contain links to other documents using the full UNC path to the old server instead of a mapped drive.
Server A ("SA.network.com" / 10.1.1.2 Server 2003) - Running DNS & WINS
Server B ("SB.network.com" / 10.1.1.3 Server 2008) - Running DNS & WINS
Server C ("SC.." / 10.1.1.4 - Server 2003) - Old (to be retired) file server
Server D ("SD.." / 10.1.1.5 - Server 2008) - New file server
Client A ("CA.." / 10.1.1.6 - WinXP x86) - any user workstation with mapped drives
Client B ("CB.." / 10.1.1.7 - Vista x64) - any user workstation with mapped drives
SC is sharing \\SC\share1. In preparation, SB has the same share created and permissions assigned. DNS has dynamic forward lookup zone entries for each server (as does WINS-which is linked to DNS. I will explain this later).
In our first attempt, the files were copied from SC to SD. As a side note Microsoft provides a utility for this called MS File Server Migration Tool which is very easy to use and carries over the share and file permissions. In our case this worked fine on the first server and on the second move we used BackupExec to restore the full and incremental backups which was twice as fast as using FSMT. The DNS entry for SC.name.com was changed to a static entry to the IP of SD - 10.1.1.5. Once DNS replicated between SA and SB then updated on the clients (either by it's normal time schedule or by manual flush) the new server would respond to ping on the old server's name, but would not work by UNC browsing by name (I believe using the IP worked but what good is that in this case?) Windows would report the error "a duplicate name exists on the network". Microsoft and other forums have tons of questions and responses about this error.
Our next step involved removing SC from the domain from the server by using System>Computer Name - NOT by deleting it from AD) This got us further, but not yet to a working state. Oddly, CB running Vista x64 was able to browse by share name. Why it worked there but not on CA I don't know. We then manually deleted SC's computer account from AD. It seemed that somehow the AD computer account was doing some sort of reverse lookup to the IP bypassing DNS but reflecting back on this case it was probably DNS to WINS. I'm no AD expert but this it what appeared to be the case.
At this point CA and SA still could not browse by name. The next process involved discovering that DNS was referencing WINS for entries it wasn't aware of. This is a setting somewhere in the DNS server properties. I can't recall how this fit into our situation but we had to manually delete (graveyard) the WINS entries. If you don't have WINS this doesn't apply.
After searching around this article (http://support.microsoft.com/?id=281308) came up which referencing share aliases and a registry entry for strict name checking. I don't have any technical details on what this function actually does but it ended up being the last step to resolve our problem. On SD, the registry change was made, restarted and browsing by name worked on all clients.
1. Copy files from old to new server
2. Disjoin old server from domain, then manually delete the computer account in AD.
3. Set static DNS entry using old server's name to new server's IP
4. Optionally ensure WINS isn't referencing any of the servers.
5. Make the registry change on the new server, restart.
6. Ensure DNS/WINS replication happens between any DCs or DNS server roles.
7. Wait for DNS to update on clients, or manually flush.
No comments:
Post a Comment