We Migrated To W2K Active Directory
Well, we finally did it. This is our journey to Active Directory. The
article was written by Greg Kras, our Tech Wiz, and hacked around by
"For a year or so we have been threatening to upgrade Sunbelt's internal
network to an Active Directory but never had the resources to make
it happen. Finally a month ago we discovered that we actually had
time to plan such and upgrade and beg for the funds needed... and
so we began our journey.
We feared that upgrading a single domain to AD would be a chore but
after much research on Microsoft's site it became apparent that it
did not have to be. The first process would be some extensive testing
in our test lab. We built a new BDC for our production network and
synced him up to the domain. We then pulled him off the production
network and moved him to a test network where we promoted him to a
PDC. We built up an Exchange server, a SQL server, a BDC/fileserver,
and 5 workstations which we joined to the copy of our production
domain. This gave us an effective microcosm of our real environment
that was ours to destroy as needed.
Using Microsoft's document titled "Upgrading a Windows NT Domain to
Windows 2000 Active Directory" we took the plunge and upgraded the
test PDC to W2K. We also pulled the BDC off the network so that we
would have a backup of the SAM in the event things went horribly awry.
After going through the typical upgrade procedure of W2K it got
to the wizard which prompted our way through making a new Domain in
a new Forest. It prompted to install DNS which we let it do during
the setup procedure. It then cranked its way through a DCPROMO and
finished about 30 minutes later. DNS didn't seem to be working very
well and we realized that the machine wasn't set to use itself as
a DNS server, can't register with DNS if you have the wrong name
server specified. Amazingly everything else seemed to be fine, we
inspected every account, every group, each mailbox, user shares,
etc... nothing appeared to be out of place.
So far, so good. However, we really didn't want to have a production
server operating an upgrade to W2K server. As one of our techs
commented, "That's just dirty". So we built up another machine to
be a domain controller in the test network. Simple procedure, just
install W2K, make it a domain controller, install DNS. Cool, now
we have two domain controllers. Now lets move the Global Catalog
to the new server... Surprise, the second item in Windows help is
"Global Catalog" and near the bottom is a link on how to move the
GC using Active Directory Sites and Services. At this point all
the techs involved started to feel that we were in some sort of a Twilight
Zone as *nothing* ever goes this well. Over the next 2 weeks we
did the same process 3 more times with similar results, no problems.
During all the testing we managed to get budgeted for 2 new Dell
2550's to become our AD controllers, score! That was an interesting
project in and of itself, perhaps I'll write an article titled "Asking
Multiple Times Per Day For Several Days Really Works!" in the future ;)
[Editor's comment: I was at the receiving end of this. If you want
to keep your job, do not try this at the office ;-) ]
We now had all the testing, experience and equipment needed to
do the upgrade. We built our snazzy new servers up as W2K Servers
and just left them as member servers for the time being. Since
our existing PDC and BDC's were rather antiquated we built a new
BDC so that the upgrade to W2K would go quickly. After the new BDC
was online we turned the DC's off and promoted it to the PDC.
We set this server to use itself for DNS before the upgrade to W2K
so that the machine would register properly with DNS after the
install. Bang bang bang, we upgraded it to W2K and everything
seemed to work fine. We tested with various workstations and
servers to make sure. Next we then grabbed the servers that we
had built earlier and ran DCPROMO on them to make them DC's in the
domain, no problems there either.
Moved the GC off of the upgraded server onto one of the clean
servers and then unplugged the upgraded server from the network...
now we had problems. The clients couldn't authenticate any more
and DNS wasn't getting updated. Looking over the event logs it
became clear that we hadn't waited long enough after moving the
GC to unplug the original server. We plugged him back in and
everything came back to life. Ok, simple enough, the Chinese
food we had ordered had just got in so we took a lunch break.
After we finished we looked into Sites and Services to verify
that the GC had in fact moved over to the new server and that
the other servers also agreed that this was the case. Lastly
we ran DCPROMO on the machine that we had upgraded and made
him a standard member server with no further role in the AD.
After about a week of watching everything like a hawk we found
a few items in the event log that needed to be addressed. The
machine that we had originally upgraded to W2K was listed
as the licensing server in Site and Services even though we
had removed it from the AD using DCPROMO. Simple enough, we
modified the record to point to one of the other servers and
that handled that.
We had a few rogue workstations that had at some point been
hard coded to some arbitrary DNS servers, we noticed them as
they hadn't been registered in DNS. And the last problem that
really caught us off guard was that our Terminal Server stopped
allowing connections. After doing some research we found that
if you license a Terminal Server on an NT4 domain and make the
Terminal Server itself the Terminal Server Licensing it will
not work after upgrading to AD.
Per the data we got from Microsoft you need to have the Terminal
Server Licensing on one of the AD controllers. We did this
and the Terminal Server started working once again. It's now
been two weeks and things are running like a top with the AD.
In retrospect, this was one of the smoothest upgrades I've seen.
Now we are working on our Exchange 2000 migration and you should
be reading about that in the next few weeks :)
Greg Kras MCP+I MCSE
Sunbelt Software Technical Services Manager