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!


  

  AddComputerAccount.wsf
  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, _
     adLockOptimistic

  objRS.MoveFirst
  Do Until objRS.EOF
     strComputer=objRS.Fields.Item("Computer")
     Const ADS_UF_PASSWD_NOTREQD=&h0020
     Const ADS_UF_WORKSTATION_TRUST_ACCOUNT=
     &h1000
     Set objADSI = GetObject("LDAP://rootDSE")
     Set objContainer = GetObject _
       ("LDAP://cn=Computers," & _
       objADSI.Get("defaultNamingContext"))

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


   objComputer.Put "sAMAccountName", strComputer & "$"
    objComputer.Put "userAccountControl", _
        ADS_UF_PASSWD_NOTREQD Or ADS_UF_
        WORKSTATION_TRUST_ACCOUNT
    objComputer.SetInfo
    objRS.MoveNext
  Loop
  objRS.Close
  objConn.Close
  
 

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 [email protected].

comments powered by Disqus
Most   Popular