SwingIt Pain and Suffering

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

I purchased a SwingIt Kit from Jeff Middleton back in March or April of this
year (2007) but the migration project got delayed until just this week. So I
studied the procedures thoroughly and even though I understand very little
about the intracies of AD, the SwingIt theory made perfect sense and I
anticipated very little trouble.

I'm now into my third day of hair-pulling, head-banging, teeth-gnashing,
***-kicking pain. Up until this morning I could not get my migration DC to
come up as a good DC and GC. Unfortunatley, I didn't discover this the first
time until after I'd also transfered AD to my new server, then realized it
was toast from an AD perspective.

Several reloads from scratch on both machines. Followed all procedures
meticulously and to the letter. No luck. So I started digging and doing
indepth research on AD (i.e. spending time and effort to reveal information
that the SwingIt method was supposed to handle for me) and eventually
realized that my AD was only partially migrating. AD users, computers,
sites, services etc, were coming over. But the computer was not advertising
itself as a DC or GC, and Sysvol and Netlogon volumes were not getting
created. This lead me to realize that replication was only partially
successfull.

Only by more digging did I discover that the problem was the default
installation/activation of the Windows firewall in Server 2003 SP1. This was
preventing AD replication from completing successfully. Once the firewall
was disabled, everybody got happy and AD on my migration DC is now fully
functional.

My copy of Jeff's documentation is well past SP1 so I would have thought
that there would have been a big, bold caveat some where that said "YOU MUST
FIRST DISABLE THE WINDOWS FIREWALL ON THE PRIMARY NIC!!!!!!!" Would have
saved me a whole lot of time and trouble. I've now spent more time and
effort on this than if I'd just done the migration the old fashion way and
installed a new AD instance on the new server and then fixed up the client
machiens afterwards. Oh well, at least the end users will still get the
benefit in the long run.

Jeff's method and description seems to bank on the technician having a very
deep understanding of AD and how to identify and fix stuff when it goes
wrong. Not so in my case. At a minimum, it definitly needs to be beefed up
with some more robust procedures for how to verify a functional AD. Just
saying "wait for 15 minutes for replication to complete and look for errors
in the event log" isn't sufficient. I waited for hours with out replication
completing.

A good description or at least some discussion of the dcdiag and nltest
tools is definitly in order. In fact, my Google search is what led me to
those, and their use in turn led to the discovery that replication was
partially failing. They also were instrumental in me being able to verify a
fully functional AD once I got rid of the firewall.

In closing, there are couple of other oddities I noted that caused me
problems, all related to having a second NIC installed. On my first pass
through, even though the second NIC was marked DHCP, many of the Windows
services kept binding to a default 169.xx.xx.xx address on that NIC rather
than on the NIC I was running with the static IP as my main interface. This
caused a number of other problems with DNS.

So I highly recommend anyone doing a SwingIt migration make disabling of the
secondary NIC and disabling of the Windows Firewall on the primary NIC be the
very first thing you do after getting a base Server 2003 OS install on both
the migration and destination computers.

Now that I've got my migration DC humming, I'm going back today to reload
the destination DC (again) and hopefully effect a successful AD transfer to
it. I'll post back again later to let everyone know how it goes.

That's my two cents worth...
.

Quantcast