Wednesday, April 25, 2012

Windows share redirection using a DNS alias

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.


Tuesday, April 24, 2012

Symantec Ghost 11 - General Protection Fault at eip=39edcf

In an attempt to reduce our VLAN count, we're attempting to merge one and all it's devices into another. We've used Ghost countless times on the old VLAN but ran into an issue on the new VLAN.

In this example we have 2 VLANs:
1 - Router=192.1.1.1
2 - Router=192.2.1.1

The Ghostcast server (192.1.1.100) sits on VLAN 1 and the client is on VLAN 2. The client boots by CD into the PC-DOS Ghost application and is attempting to setup a unicast session to create a backup. When going to the Network>Unicast menu, Ghost immediately crashes when trying to get an IP address with:

General Protection Fault at eip=39edcf; flags=3016
(see the screenshot for the trailing error codes)

This error does not appear to be on Symantec's website and Google returned nothing (hopefully after this post it will).

This is because there was a mistake in the DHCP scope options. The "Router" address (option 003) was set to the VLAN 1 router instead of it's local VLAN 2. I don't know exactly where in the programming the crash occurs because the Ghostcast session isn't initiated yet, this happens during the DHCP lease process. Again, oddly even after changing the DHCP scope options to the correct address then running Ghost again from the command line without rebooting the program still crashes. Windows computers on the same network have been given this incorrect route and have been working fine, so I don't fully understand this. Once the DHCP scope option was corrected Ghost worked (after a reboot).

I figure this is a niche error because there's no reference to it anywhere and our network is likely unique.

Welcome

I've started this blog to post random tips and things that come to mind (usually technical subjects). I'm not a professor, but a friend of a friend saw me wearing a cardigan and said "Who's the professor?" One of those had to be there things.