h0bbel.p0ggel.org

I just realized that I never did wrap up the Active Directory migration tale.
We did run into more trouble, I guess you won't be suprised to hear that. Everything went fine, until we tried disabling the DHCP server from the old server, and enabling/authorizing it in the new domain. Simply put, that didn't work. The event logged in the evenlog was: "Event ID 1051: The DHCP/BINL service has determined that it is not authorized to service clients on this network for the following domain: example.com"

The point is, that we tried authorizing it before that event was logged, but with no luck (yes, we were logged on with an Enterprise Admin account). We figured it was due to the old Windows 2000 domain and DHCP server we had left running while we were sorting out the replication issues. We decided to wait a few days, then we turned off the old DHCP server Friday night, and Saturday evening we tried authorizing the new DHCP server again. No luck. I tried searching and editing the Active Directory schema directly with ADSIEdit, but could not find any references in the schema-objects for the old DHCP server.

But then it suddenly dawned on me (suddenly, as in a few hours later. :) ) - The Infrastructure Master FSMO role holder, was also the Global Catalog for the local site. That is a Bad Thing^tm - Once we transfered the Infrastructure Master FSMO over to the other DC, the authorization attempts were succesfull and the new server was finally handing out the IP-goodness to it's clients.

So, to make a very long story short; make sure you have all replication issues sorted before even attempting a multi-site Active Directory implementation, NEVER place use the same server for both GC and the Infrastructure master FSMO-role.

Anyway, the whole setup works now, replicating away, servicing clients and working like it was designed to do. Yay!

Oh, and by the way, this was finished on the 27th of March 2004.

So, with yesterdays experience fresh in mind we were supposed to start migrating user/computer objects into the fresh domain.
The day started out with not getting the trust relationships in place between the old and the new domain...

After a lot of fiddling and debugging, it dawned on us. We had forgotten to designate a Global Catalog in the local site, and this was causing our domain server to go across the WAN link on every change in AD. I manually added the Global Catalog role to the local server, only to realize that there were replication errors in the forest. After about 1.5 hours we finally got a proper replication going.

We managed to get the trusts working, and started prepping for the ADMT process. This involved setting permissions in both domains for the trusted users. After loads of errors and migration tests we got it working. The domain computers (the ones running Windows 2000 and XP) were migrated, and so was the user accounts and groups. By the time we got this far, it was already so late that it was not likely that we would get the rest of the job done this weekend. So, yet again, the final migration is postponed.

We are now looking at finishing it next weekend, with some of the people involved working on copying files and other necessary services during next week. Hopefully next weekend will involve a few hours work on my part, and this whole process will be finished. Judging by the previous attempts on estimating how much time this would take, I'm not that hopefull that this will be the case in the end. Anyway, I think we will actually hit it on the nose this time, as the remainder of the job is purely file/permissions setting and enabling the new DHCP/WINS services. Also, this process will involve removing the old AD from one of the old servers, and promoting it again as a DC in the new Domain.

Time will tell ...

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:

A blog is a good place to shamelessly promote yourself, right?
I have been spotted! Have a look at this impressive feat of self ridicule. I'm sure that Brainco doesn't agree that this is good advertising, but I live by the fact that any pr is good pr.

I'm sure Bharat is happy too, after all he bought me the shirt. Thanks a lot Bharat!