Windows 2000 is different enough from Windows NT 4.0 that some of your applications may not work after upgrading an NT network to Win2K. As a result, setting up a test network before upgrading from one OS to the next is a critical step.
Joe, an admin who doesn't want his real name used, is responsible for making sure everything will work after his company makes the upgrade to Win2K. He asked TechRepublic members for help figuring out what he needed to do to test his organization's apps. His questions are highlighted in the article "Can you help this admin plan for pre-Win2K migration testing?"
Brian Coverstone, MCSE, MCDBA, responded to Joe's questions. Coverstone has been working with Windows 2000 for more than a year and was willing to elaborate on his experiences. In "Preparing for a WinNT to Win2K upgrade," Coverstone explained how to set up a test network for Win2K, taking the process up through upgrading the first NT 4.0 PDC and describing the problems he had when his DNS broke after the upgrade.
Now it's time to wrap things up. In this article, Coverstone will describe:
- Upgrading the rest of the network's servers.
- Upgrading workstations and testing applications.
- Backing up production servers and doing the production upgrade.
Win2K spreads domain controller roles around
The first PDC that is upgraded becomes the root for the Win2K and Active Directory (AD) forest, Coverstone said. He emphasized that this should be done in Mixed Mode to provide backward compatibility. You can switch to Native Mode once everything is upgraded.
After the root is established, you can upgrade all of the network's PDCs and BDCs, and then member services. Keep in mind that PDCs and BDCs don't exist in the Win2K scheme. The root server is the main network server, and the functions of the former PDC can be spread out among the other domain controllers on the network.
Beyond the root domain controller, all domain controllers have essentially the same rank, but they can have one or more of five roles. Known as the Flexible Single Master Operation (FSMO, pronounced fizz-moe) role owner, two of the five roles are enterprise- or forest-wide, while the other three roles are domain-wide.
The two enterprise-wide roles are:
- Schema Master, which is on the root domain controller by default. It controls all the elements that make up AD.
- Domain Naming Master, which also defaults to the root domain controller. It maintains domain name integrity.
The three domain-wide roles are:
- PDC Emulator (or Advertiser), which is used for backward compatibility purposes. It acts like the NT PDC so older systems can exist on the network.
- RID (Relative-Identifier) Master, which generates a Security Identifier (SID) for every user, group, or computer on the network.
- Infrastructure Master, which maintains references to objects from one domain to another. These objects, which can be users, are called Phantoms.
Expect to have issues when you create new domain controllers on the network.
"I have yet to have multiple domain controllers install properly on the first try. Every time, I end up with a DNS configuration issue, and I have to do searches at Microsoft's Web site to find why the DNS is not being recognized correctly," Coverstone said. The problem typically has something to do with the DNS setup that prevents the domain controllers from working properly with the root domain controller.
"Remember, 2000 domain controllers use Active Directory to store everything, and Active Directory uses DNS to find everything," he said.
Upgrade workstations and let the testing begin
With the test network servers and domain controllers up and running properly, you can turn to the workstations on the test network. Like the servers on the test network, workstations and applications should mimic current configurations on the production network.
"Grab at least two workstations and give them a try in the lab with Windows 2000 Professional," Coverstone said.
He also suggested having a few employees who work with particular applications try to imitate what they do on a daily basis. This will help uncover specific problems with how the application works with Windows 2000.
One way to make sure there that will be no software surprises after you upgrade the production network is to work your way through the organizational structure. In each department, have department managers poll their staff for all software titles they use.
It is important that employees include all programs they use, even if they don't believe there is any impact on the network. At some point in the process, the results from local programs on the user's machine may need to traverse the network for inclusion in another program that may use network resources.
Working with departmental managers eliminates, or limits, the IT staff's culpability if a critical program doesn't work as expected after the upgrade. This is another reason that end users should attempt to imitate their normal usage of the program on the test network.
If problems appear with programs during testing, a seasoned developer may be able to troubleshoot them. The developer should have tools that track where the program is failing and be able to provide a quick fix, Coverstone said.
If the program defies troubleshooting, contact the software manufacturer.
"Chances are, you are not the first customer to try its software on Windows 2000, and it should have some tips," Coverstone added.
Once all applications successfully operate on the test network, upgrading the production servers can be scheduled.
Moving on to the production-box upgrades
Remember that the ultimate goal of the test network is to prepare for upgrading the production servers. Use the test network to customize and document a successful upgrade so that you can replicate the process in your production environment.
Schedule plenty of time for the actual production-server upgrade. Often, scheduling this task on a Friday after normal working hours will provide that night and the weekend to make the transition—and allow time to solve the inevitable complications.
Even with the best-laid plans, the upgrade may not work as expected. Create an image of every network hard drive so that you can restore everything to preupgrade status if the worst-case scenario happens.
If hard drives are ghosted, the recovery process will go faster, according to Coverstone. But admins who feel more comfortable with their usual backup and recovery process should use that instead of ghosting.
"If you are really paranoid, have a tape backup and a ghost image," he said. "You can never have too much backup when performing large tasks that can take a company offline if there is a snag."
Notes from the test network setup will be invaluable as the process of upgrading the production network begins. Coverstone suggested that admins marshal all the resources they can, including a computer with Internet access. That computer will probably spend its time at Microsoft's Knowledge Base so that any problems can be researched and solved quickly.
This is not the time to cut corners, take shortcuts, or stray from the experience that the test network captured in the documentation, he said. If the live upgrade goes as the test upgrade did, the production network will be able to go live quickly. If there is a problem and a solution can't be found, the production network will have to be restored to its preupgrade state.
After the upgrade
A sigh of relief may seem warranted, along with self-congratulations after the upgrade succeeds, but it isn't time to celebrate.
"You may want to mention [to managers] that the first couple of days following the upgrade might be a little rocky," Coverstone said. You'll also want to be available to solve problems immediately after the upgrade.
"It's much easier to fix a problem when someone is not breathing down your neck asking you why you never mentioned that there could be problems."