h0bbel.p0ggel.org

It all started a while back, when I agreed to do some freelance consulting for a local firm here in Bergen, Norway.
It seemed like a pretty basic job, but it involed a bunch of steps to ensure data integrity and availability. To summarize, the customer wanted to migrate an existing Active Directory forest/domain structure into a new forest located abroad. This is being done to implement a Europe-wide Active Directory with a common Exchange infrastructure for all of the sites/domains.

At first this seemed to be a fair enough task to do, as I was only going to be involved in the Bergen location, and migrating their domain into the existing forest. Plans were made, VPN-tunnels established, and then the fun began...

Since we were going to install a new domain controller, we decided to go with Windows 2003 Server. Our first attempt failed miserably, since the existing Active Directory forest wasn't Windows 2003 Server ready, as the schema wasn't upgraded. We postponed the install for about a week, and let the IT guys in Europe do their thing with upgrading the Forest-schema.

Today we were starting fresh, but discovered that there was some problems running the adprep commands extending the schema. This basically ment that we would have to troubleshoot something that should have been a walk in the park. The adprep process is pretty well documented by Microsoft, so we weren't expecting too much trouble. The only thing that concerned us at first, was a ominously named Knowledge-base article, called "Windows Server 2003 adprep /forestprep Command Causes Mangled Attributes in Windows 2000 Forests That Contain Exchange 2000 Servers. We went through that document, looking for mangleable objects, and realised that none were to be found.

So far so good, and the adprep process began. At first, we thought everyhing was fine, and we shouldn't encounter any big suprises along the way. Man, we were wrong!
The first attempt of running adprep on the main DC in the forest root domain, failed miserably. We did not have the full Windows 2003 Server server CD present in the datacenter hosting the DC, and we were missing some dll's and other necesarry files from that CD (I guess you've never heard of something simliar before?). Luckily we got hold of someone in the vicinity of the datacenter, that actually had the Windows 2003 Server CD at hand. He popped in, and put the physical media into the server. At last, we could actually run the adprep command!

Sadly, this was not the end of our endevour into extending the Windows 2000 Active Directory Scema. We ran the command as prescribed, but this yielded a bunch of weird errors, including "Failed to transfer the schema FSMO role: 52(unavailable)." - This in itself was pretty weird, since we were running (as recommended by Microsoft) on the Schema master FSMO role holder, and we had all the permissions in the world! Why the h**l can't the server contact itself?!

After a lot of debugging, trying different permissions settings on the Schema objects itself, we had a epiphany! We had shut down the replication partner DC in the root forest domain, to be sure that we could roll-back to the Active Directory state we had, before running adprep. This caused the Schema Master (without telling anyone) to not allow changes to the Schema, since there were pending replication attempts.

So, we had to re-start the other DC in the root-domain, force a full Schema replication, re-run the adprep /forestprep command and force a new replication again. Now, the waiting game began, again. After waiting for the new Schema to propagate to existing subdomains and Domain Controllers, we ran the adprep /domainprep command for the top domain in the forest. And, voila, adprep did it's thing again - This time with, no errors! We were in business, and ready to create a new subdomain in the forest at last. Now, the local Windows 2003 Server DC decided that joining a forest, and creating a subdomain was a bad idea. It got ~95% done, and then exited with "RPC server unavailable". Now, all of a sudden, our server was unable to talk to the server I had been remotely controlling all day. As this is Windows, we decided to let the Windows thing happen (Which basically is a reboot. :) ).

After we booted the server, it managed to join the domain as planned! We were finally up'n'running with a new subdomain, on a local server!!! And, what do you know, we were only about 7 hours delayed! Not to shabby....

So far so good, we decied to call it a day, and continue on Sunday. The comforting thing now is that we know we can contact the old domain, and we are online with the new domain. This is a big relief, as we are going to use ADMT to migrate all the old user/computer accounts into the new domain. That should make things a bit easier tomorrow.

To be continued...

Written while listening to: