There we were, surrounded by cold cuts and veggies neatly arranged on serving trays. The food was forgotten, though, as we stood by, waiting for the crucial moment. No, it wasn't New Year's Eve—it was one of many evenings spent working on an Active Directory (AD) implementation. Yeah, you know all about it: long days, late nights, bad food—the whole package.
We were on day four of an upgrade from Windows NT 4.0 to Windows 2000 AD. Everything was going well, and we'd accomplished a lot during the preupgrade process. Then disaster struck, and the cold cuts and veggies started flying around the room like mobile homes in a tornado. What went wrong, and how did we fix the problem?
Preparation
The environment we were dealing with included 30 domain controllers (DCs) in one NT 4.0 domain that spanned multiple locations. We'd gone through all the important upgrade preparation tasks: design meetings, testing the upgrade, creating a backup plan, taking an NT 4.0 DC offline, and everything else that goes into a good upgrade to Win2K and AD.
By the time the snacks arrived, we'd installed two Win2K DCs—DC2 and DC3—in the Phoenix central office and had 28 NT 4.0 BDCs left to upgrade in various locations. For the next phase of the upgrade, we planned to migrate a BDC in Delaware—DC1—to Win2K so that we could take advantage of AD's site capabilities when we reinstalled the Windows 95 clients in Delaware with Windows XP Professional Edition. A crew of two handled DC1 in Delaware; another techie and I sat at control central in Phoenix.
Each DC is different, so you need to consider each one individually when attempting a migration. Our team had rigorously examined how to migrate DC1 with the least amount of pain. Our options included performing a common upgrade, performing a scorched earth upgrade (i.e., using Fdisk or Symantec Ghost's GDisk feature to clean the hard disk and start over), or installing a new instance of Win2K on top of the existing \winnt directory. We wanted the cleanest Win2K installation possible, so we immediately ruled out the upgrade scenario. We didn't want to scorch the entire system because DC1 was a Microsoft Systems Management Server (SMS) Client Access Point (CAP) and thus contained more data than we wanted to remove and restore. Therefore, we moved forward with the third option.
Installation
Before we began installing Win2K on DC1, we ensured that the system and all files were backed up. The Delaware crew then maneuvered through Win2K's fresh installation options as we sat tight and sampled the cold cuts.
The remote team installed Win2K on DC1, specifying the system as a member server. After the system rebooted, the remote team ran Dcpromo and selected DC1 as a replica DC for the domain. AD synchronization began, and life seemed wonderful. The system rebooted after replication. We waited for the DC to show up in the Microsoft Management Console (MMC) Active Directory Users and Computers console, the MMC Active Directory Sites and Services console, and DNS; it did so, as planned. One problem remained: DC1 was in the wrong site. We (the Phoenix team) used the Active Directory Sites and Services console to move DC1 to the correct site—and things started to go wrong. The AD relationship between DC2 and DC1 failed, and DC1 seemed to fall off the face of the earth. (This was the point at which the veggies started to fly.)
After we tried a few reboots that had no effect, we analyzed our situation. We had a Win2K server that wasn't communicating with the domain as a Win2K DC. We ran Dcpromo on DC1 to try to demote the DC to a member server and clean up the database, but the demotion failed. DC1 had no connections to the domain and was drifting alone.
Previous
Register
