I recently started a job to upgrade a client's network from Windows 2000 and Windows NT to Windows Server 2003 and Microsoft Exchange Server 2003. The company currently uses Microsoft Outlook with a POP3 account provided by its ISP for Internet mail. The Exchange 2003 server will handle the mail internally after the migration is complete. It’s been some time since I’ve worked on NT machines, and the upgrade path has changed slightly. Although this client has several Win2K servers, they're only member servers of an NT domain. Unfortunately, the entire network is still under an NT domain with only one NT domain controller (DC). As you know, when you introduce the first Win2K or Windows 2003 DC, it must be the primary DC. I used to work around this restriction by installing NT on a new server as a BDC, promoting it to a PDC, then performing an in-place upgrade to Windows 2003 or Win2K. Unfortunately, the server didn't support NT, so I needed to use the Active Directory Migration Tool (ADMT). You can download this tool at http://www.microsoft.com/downloads/details.aspx?FamilyID=788975b1-5849-4707-9817-8c9773c25c6c&DisplayLang=en. In my opinion, using the ADMT is slightly more work than performing the in-place upgrade of NT to Windows 2003 but easier than manually migrating the domain from NT to Windows 2003. I typically install the ADMT on a DC that belongs to a Windows 2003 or Win2K domain in native mode. Unfortunately, after I installed the tool, it became clear that the current network wasn't in very good shape. I couldn’t even see the NT domain from the new Windows 2003 servers. I also received a “Duplicate name exists” error whenever I restarted the new Windows 2003 servers. I performed some troubleshooting and determined that the WINS wasn't working properly on the NT network. The entire network was configured the old "NT way" with DNS servers pointing directly to the client’s ISP DNS servers with one Win2K member server installed and running WINS. Name resolution was hit or miss, with some of the existing servers able to resolve servers and some not. I looked at the WINS service running on the Win2K server, but I received an error stating that the WINS service was unavailable whenever I tried to view the WINS entries in the database. The problem continued even after I uninstalled and reinstalled WINS, then reapplied the latest support pack and fixes. I was able to get WINS working again by completing the following steps:
1. Uninstall WINS.
2. Remove all network services, including protocols, network card, and other network services, from the server.
3. Obtain the latest network card driver.
4. Reinstall all network services.
5. Reinstall WINS.
6. Install the latest service pack and patches.
After performing these steps, the servers were able to reliably name resolve other servers on the network. Unfortunately, the person that was previously performing network support for this client was fixing name-resolution problems by adding entries into the LMHOSTS file to get the network working again, instead of fixing WINS on the server. Thus many servers and workstations had LMHOSTS files that needed to be deleted. After WINS was working again, I was also able to resolve the “Duplicate name exists” error message that was appearing on the Windows 2003 servers. When I installed the Windows 2003 server, I configured the network card to automatically obtain an IP address from a DHCP server. WINS registered this address in its database, and when I changed the IP address to a fixed IP address, it conflicted with the entry in the WINS database. It took a while to figure out the problem because WINS was broken and I couldn’t see the database entries. After I fixed WINS, I was able to delete the incorrect entry in the WINS database for the Windows 2003 server and the “Duplicate name exists” error went away. I established a 2-way trust between the NT and Windows 2003 domains to ease the transition to the new Windows 2003 domain. I then reconfigured the DHCP server to point workstations to the new Windows 2003 servers for name resolution after verifying that root hints were properly configured on the Windows 2003 DNS server. Because I was unsure of the status of the workstations, I visited each workstation to install Symantec AntiVirus Corporate Edition and Microsoft Office Outlook 2003, then moved the workstation from the old NT domain to the new Windows 2003 domain. I’m glad I decided to visit each computer (40 total), because I found machines that were low on memory (64MB to 128MB), and quite a few machines were infected with viruses and spyware. I also configured clients to obtain mail from the new Exchange server in addition to their POP3 accounts from their ISP.
After all the workstations have joined the new domain, I’ll change the MX record for the client’s Internet domain to point to the internal Exchange 2003 server. I’ll retire the NT DC first, to remove WINS from the network and eliminate any additional name resolution issues.
Utility for Locking Down Public Computers
Microsoft has released a utility for locking down publicly accessible computers. Check it out at http://www.microsoft.com/windowsxp/sharedaccess/default.mspx.
