Scripting Your Way Through an AD Migration
Save time (and hassles) with these scripting tips.
I just finished completing an Active Directory migration for a
client where we merged two NT domains—with a two-way trust
relationship—into a single Active Directory. As if that wasn't
enough, we upgraded to Exchange Server 2003 and put all the users
on Outlook 2003. This client had been putting off the upgrade to
Windows Server 2003 and Active Directory for a variety of reasons,
but one of the main ones was, as we say in the south, "If it
ain't broke, don't fix it!" The Windows NT 4.0 servers were
humming along nicely and there was no reason to change.
Then two things happened. The first was that NT had recently required
several security hotfixes—the client thought that after eight
years, NT should be secure by now. Second, Microsoft has been steadily
phasing out support for NT 4. Combine the two and you have a compelling
reason to upgrade. Might as well move to the latest and greatest,
Scripting Eases the Pain
I don't want to turn this into a screed about the trials and tribulations
of AD migration. Rather, I thought I'd take the next few months
and share some areas of the migration process where scripting is
particularly helpful. This month: automating the creation of computer
accounts in the domain.
Since we were joining two domains into one, all of the computers
in one domain had to join the other. So if your AD migration consists
of a single domain, you may think you have no need for this script.
Not true! There are still times when this script is helpful. Perhaps
you have just acquired a bunch of new workstations and need to install
Windows XP and add them to the domain? See, I knew you'd think of
Adds computer accounts to the domain
Dim objADSI, objContainer,
objRS.CursorLocation = adUseClient
objRS.Open "SELECT * FROM Computers",
Do Until objRS.EOF
= GetObject _
objComputer = objContainer.Create _
strComputer & "$"
The script is simple enough. It reads a list of computer names
from a data source (remember the ADO scripting we did over the past
two months?) and creates computer accounts in the Active Directory.
This keeps you from having to walk to every machine and enter the
domain admin account and password to create the computer accounts
one at a time. Depending upon how many machines you're migrating
to the new domain, this can be a real time-saver.
As the data source for the list of computers, I've simply used
a generic DSN. For the script to work, you'll need to create this
DSN in your ODBC Control Panel applet and point it to an appropriate
data source. I used an Access .MDB, but you can use whatever you
want. Just make sure that either: the data source contains a table
named computers with a column named computer that holds the individual
computer names to add to the domain; or you change these references
in the script to point to the appropriate table/column.
When adding this script to your collection, be sure to make some
improvements to it. First, it's a good idea to put in some validity
checking to see if the computer account already exists—just
in case. Along those same lines, you might want to add some simple
error handling in case one or more accounts fail during the creation
I'll Do You One Better
Pre-creating the computer accounts for an AD migration or for adding
a bunch of new machines can be a real time-saver, provided you're
using this script with an automated installation or migration, and
the installation/domain change is operating under the security context
of a domain admin. There may be times, however—particularly
during a migration—where this process will be somewhat manual.
In these cases, it's possible to create a computer account in the
Active Directory and allow a user to add his workstation to the
domain without requiring your "administrative assistance."
That is, you get to: set up the account for a particular computer
name; specify the person allowed to add a computer with that name
to the domain; and continue working at your desk rather than walking
all over the office entering your admin password at each machine.
Of course, you'll want to use this option carefully (perhaps only
allowing power users to do this).
Rather than reprint the entire script here (it's quite large), we've made it available for you online. You can download it here.
Next time: More scripting aspirin for your migration headaches.
Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to firstname.lastname@example.org.