Mr. Script

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, eh?

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 something!


  Adds computer accounts to the domain


  <> id="objConn" progid="ADODB.Connection" Reference/>
  <> id="objRS" progid="ADODB.Recordset" Reference/>
  <> language="VBScript">
  Dim objADSI, objContainer, objComputer
  Dim strComputer
  objConn.Open "DSN=CompList"
  objRS.CursorLocation = adUseClient
  objRS.Open "SELECT * FROM Computers", _
     objConn, _
     adOpenStatic, _

  Do Until objRS.EOF
     Const ADS_UF_PASSWD_NOTREQD=&h0020
     Set objADSI = GetObject("LDAP://rootDSE")
     Set objContainer = GetObject _
       ("LDAP://cn=Computers," & _

    Set objComputer = objContainer.Create _
    ("Computer", "cn=" & strComputer)

   objComputer.Put "sAMAccountName", strComputer & "$"
    objComputer.Put "userAccountControl", _

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 process.

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.

About the Author

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


  • Gears

    Top 10 Microsoft Tips and Analyses of 2018

    Here are the year's most popular explainers and how-to columns -- along with some plain, old "Why did Microsoft do that?" musings thrown in.

  • Sign

    2018 Microsoft Predictions Revisited

    From guessing the fate of Windows 10 S to predicting Microsoft's next big move with Linux, Brien's predictions from a year ago were on the mark more than they weren't.

  • Microsoft Recaps Delivery Optimization Bandwidth Controls for Organizations

    Microsoft expects organizations using its Delivery Optimization peer-to-peer update scheme will optimally see 60 percent to 70 percent improvements in terms of network bandwidth use.

  • Getting a Handle on Hyper-V Virtual NICs

    Hyper-V usually makes it easy to configure virtual network adapters within VMs. That is, until you need to create a VM containing multiple virtual NICs.

comments powered by Disqus
Most   Popular

Office 365 Watch

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.