My PDC was cutting edge—5 years ago. With time, resources that I once had in excess became bottlenecks. (I remember getting my first 500MB hard disk and thinking that I'd never use all that space.) Replacing an inadequate Windows NT PDC requires careful planning and a deliberate approach. Although my situation won't be the same as yours, understanding how I replaced my aging PDC might help you when you face a similar situation.
Prepurchase Planning
Before you decide what kind of system to purchase, you need to estimate what your PDC needs to be able to handle. My old PDC supported RAS, DHCP, WINS, directory shares, and printer shares, and I wanted my new PDC also to provide home directories. With those requirements in mind, I calculated my storage and memory needs.
I needed 5GB of hard disk space to support the storage needs of the old PDC. When predicting how much storage my growing network would demand beyond this base figure, I considered user-storage needs, system needs, and new applications (e.g., Microsoft SQL Server) I expected to add. I had collected disk-storage figures for 6 months and was able to predict how fast my PDC's storage needs were likely to grow. Historically, my storage needs have increased by about 5 percent per year. To meet these growth needs over the next 3 to 5 years, including expected program additions, I estimated I would need an additional 5GB of storage. Half of the 40 users on my network use only email. I estimated that my PDC would need another 20GB of storage to provide home directories for the remaining 20 users. I planned to configure my system and boot partitions with a generous 15GB IDE drive and set up five SCSI-based RAID 5 drives (four 5GB drives for storage and one 5GB drive for fault tolerance).
I ran Performance Monitor and analyzed the results of the memory counters to figure memory requirements for the new PDC. The results showed my old PDC's 128MB of RAM to be inadequate, so my new PDC would have 256MB of RAM. I also decided to upgrade from a 266MHz Pentium II processor to a 500MHz Pentium III processor. When you calculate your network needs, remember to consider any peripherals, such as RAS modem banks and CD-ROM towers, that you might need to upgrade or add.
Prechangeover Planning
After I ordered the hardware, I needed to decide which methods to use to move to the new PDC. Many methods require a BDC, which I didn't have. If you have a BDC or your system configuration requires you to reestablish trust relationships, replicate directories, reapply DNS, and reschedule jobs, then modify or add to the list of steps I followed.
Before I began the installation, I documented the services (including startup settings and any special accounts the services run under), programs (and their configuration settings), and network protocol settings on my old PDC. I used the Microsoft Windows NT Server 4.0 Resource Kit Sclist utility to list the services.
As I documented the old PDC's programs, I located the installation disks for these programs and copied the disks to a share on the old PDC. I also checked for updated drivers on vendor Web sites and copied to the share all the drivers I would need. In addition, I used the network protocol documentation to compare each server's protocols and bindings between protocols and services.
Making the Move
I let the users know that the domain would be down temporarily, and I did the job on a weekend night so that the transition would affect as few users as possible. Before I made the move, I backed up my old PDC and did a partial restore to ensure that the backup was reliable.
Step 1
Install the new PDC as a BDC. When I installed NT Server 4.0 on the new server, I chose the option to install the server as a BDC and gave the new server the name NEWPDC. I also installed all the protocols that the old PDC was running.
If your new PDC has NT Server preinstalled, you'll need to reinstall the OS to add the new server to your domain as a domain controller (DC) and recreate the domain SID. Consider requesting that the OS be preinstalled as a member server. You then can use Algin Technology's UPromote to add the server to the domain as a BDC without reinstalling the OS.
Step 2
Install services. I referred to the documentation I compiled in preparation for my PDC changeover and installed the services my new PDC would need, such as WINS and RAS. I also installed Service Pack 6a (SP6a) and used Control Panel to verify the installations.
If you want to run any services under special accounts, use the Control Panel Services applet to change the services' startup configurations on the new PDC at this time. Select the service whose startup configuration you want to change, then click Startup. Enter the account and the account's password in the Log On As section.
I opened Server Manager on the new PDC and manually synchronized the domain by selecting the old PDC's name and selecting Synchronize Entire Domain from the Computer menu. This precaution ensures that the SAM databases on the old and new servers are synchronized and the protected channel between the DCs is established properly.
To compare the services now running on the two servers, I used the Sclist utility again to list services and service status information:
I compared the two lists to ensure that the services were running properly on the new PDC.
Before you proceed, determine when you want to change the name of the new server to the name the old server had. When you change the name depends on which programs you'll install on the new PDC. For example, if the new PDC runs Microsoft Exchange Server or SQL Server, set the permanent computer name now so that you don't need to make manual program configuration changes later.
Step 3
Install programs. From the new PDC, I connected to the share on the old PDC that contained my applications and drivers and installed them on the new PDC. Be sure you reboot whenever installations prompt you to, and don't install more than one program at a time. That way, if something goes wrong in your installations, you'll usually need to look only to the last program you installed to identify the source of the problem. Remember to reinstall SP6a after you install your applications.
Step 4
Move shares. I wrote a batch file to copy directory shares from the old PDC to the new PDC. The batch file used several resource kit utilities to minimize my involvement in copying shares.
For more information about these and other utilities, see "Related Articles in Previous Issues." Figure 1 shows shares .bat, an example of a batch file for moving shares and permissions.
Attaching both the old PDC and the new PDC to the same hub or switch and using 100Mbps NICs will maximize transfer speed when you run your batch file. I ran the batch file from the new PDC and double-checked a few share folders, subfolders, and files by confirming their share names, share permissions, and NTFS permissions.
Step 5
Move nonshared files. I decided which files I wanted to move to the new PDC (these files might include anything from logon scripts to log files). Nonshare.bat, which Figure 2 shows, illustrates how you can use a batch file to copy specified files to the new PDC. This batch file uses essentially only one command—Copy—because the batch file doesn't transfer shares or permissions. (If you need to copy subfolders, you also will use the Xcopy command with the /s switch.) You can automatically create a target folder for a file by adding a line to the nonshare.bat file. For example, I could create a folder for my archives by adding the line
before the first Copy command in nonshare.bat.
Step 6
Move the printers. Before you move the printers, remember to stop the spooler service. I used regedt32 to transfer the printers' registry keys to the installation share on the old PDC. Then, I restored the registry keys to the new PDC. For a step-by-step process for moving printers from one server to another, see Bob Chronister, Tricks & Traps, "Ask Dr. Bob Your NT Questions," December 1998. After I moved the printers, I checked them by printing test pages from the new PDC.
Step 7
Export DHCP information. I first stopped the DHCP Server service and disabled it on the old PDC. Then, I copied the DHCP directory tree to a temporary location on the new PDC. On the new PDC, I stopped the DHCP Server service. I deleted the \%systemroot%\system32\dhcp folder's contents and copied the DHCP directory tree from its temporary location to this folder. I started regedt32 and restored the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Configuration registry subkey. Then, I restarted the DHCP Server service on the new PDC and reconciled the database with the registry. See the Microsoft article "How to Move a DHCP Database to Another Windows NT Server" (http://support.microsoft .com/support/kb/articles/q130/6/42.asp) for more information.
Step 8
Promote the PDC. My new PDC could now take its place at my network's helm. I started Server Manager on the new PDC and, from the Computer menu, selected Promote to Primary Domain Controller. Promoting the new PDC automatically demotes the old PDC to a BDC. After the promotion and demotion, I turned off the old PDC. I then could hard-code the IP address and associated data from the old PDC on the new PDC.
If you didn't set the permanent computer name on the PDC immediately after Step 2, do so now. I used the old PDC's computer name on the new PDC so that my users didn't need to change mappings or shortcuts to any resources housed on the server (e.g., shared directories, shared printers). I transferred the peripherals I wanted on the new PDC from the old PDC and rebooted the new PDC. I also made an Emergency Repair Disk (ERD).
Step 9
Create home directories. To create home directories (aka user directories) for my network's users and to set share and NTFS permissions for the directories, I wrote a batch file like the one Figure 3 shows. My network has both NT and Windows 95 users. The batch files you write to create home directories for NT users will be different from those you write to create home directories for Win9x clients. Both files use the resource kit's Rmtshare and Cacls commands. (Rmtshare creates the share name for the home directories; Cacls adds NTFS permissions to the directories.) Both batch files give administrators and individuals full access (which callouts A in Figure 3 and Figure 4 show) to the individuals' subfolders.
Connecting Win9x users to their home directories is more complicated than connecting NT users. Figure 3 shows home.bat, which models the creation of users' folders as hidden shares. Win9x clients can't recognize the %username% variable, so if you have many Win9x users, consider also writing a batch file by using the /homedir switch and the Net User command to specify each user's home directory path. Otherwise, after you execute your batch file, you need to use User Manager for Domains to set up each Win9x user's account so that it connects only to that user's share.
To perform this step, I opened User Manager for Domains and selected the first Win9x user account that I wanted to connect to its home directory. From the User menu, I selected Properties. In the User Properties dialog box, I clicked Profile. In the Home Directory box in the User Environment Profile dialog box, I selected Connect, chose the drive letter H, and entered \\newpdc\user1$ in the To text box, as Figure 5 shows. I repeated these steps for each Win95 user account that would have a home directory. When my Win95 users connect to the Users folder, they won't see anyone's folder but theirs. You also need to edit Win9x users' logon scripts to include the following line:
net use H: /home
Figure 4 shows nthome.bat, a sample batch file that creates the user shares for NT users and sets their NTFS permissions so that only the individual user and administrators have access to the individual's folder. If you don't run home.bat before you run nthome.bat, you'll need to add commands to nthome .bat to create the User folder on the new PDC. After you run nthome.bat, the %username% variable lets you assign NT clients to their home directories all at once instead of one at a time. Open User Manager for Domains and highlight all NT user accounts. Navigate to the User Environment Profile dialog box, as you would to edit Win9x user accounts. To connect all NT users to their directories, you only need to choose the drive on which to connect the directories and enter \\newpdc\ %USERNAME% in the To text box, as Figure 6 shows.
Step 10
Update the ERD. I used the Rdisk command to open the Repair Disk utility. To create an ERD for the new PDC, I selected Update Repair Info. I also did a full backup on different tapes from those that I used to back up the old PDC before I began the changeover process.
After I completed the changeover, I discovered a detail or two I had overlooked. I had kept the old PDC, though, so I could bring the old PDC back online as a BDC, rename it, and retrieve any scraps I needed.
Finally, I celebrated. My network meets my users' needs once again—at least for now.
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com. DARREN MAR-ELIA "Remote Resource Kit Roundup," May 2000, InstantDoc ID 8430 MARK MINASI This Old Resource Kit, "File-Server Migration: Scopy Becomes Xcopy," February 2001, InstantDoc ID 16459 This Old Resource Kit, "Permcopy and Share.vbs File-Server Migration Tools," January 2001, InstantDoc ID 16252 This Old Resource Kit, "Rmtshare," June 1999, InstantDoc ID 5426 |
