May 16th, 2006

How Can I Use a Script to Create a Sequential Series of User Accounts?

Hey, Scripting Guy! Question

Hey, Scripting Guy! For purposes of testing, I often need to create multiple user accounts like this: pgeorge01, pgeorge02, etc. How can I write a script that automatically creates the next account in the sequence; that is, pgeorge03?

— RG

SpacerHey, Scripting Guy! AnswerScript Center

Hey, RG. You know, after our last experiment went horribly, horribly wrong, we vowed never to get involved in anything that even smacked of human cloning ever again. (In case you’re wondering, creating an army of uncontrollable zombies that rise up and terrorize the countryside does not look good on your performance review.) Still, we’re not really cloning people here, we’re just kind of cloning user accounts. That seems safe enough.

Besides, you know what they say: you can’t keep a good man (or woman) down.

Turns out, you can’t keep the Scripting Guys down, either.

Although there are several different ways we could approach this task we decided to stick with an old favorite: an Active Directory search. What we’re going to do is search Active Directory for all the user accounts that have a samAccountName beginning with the letters kenmyer. We’re then going to count the number of users we get back from this search. Why? Well, suppose we get back 3 users. Assuming we’ve stuck to the naming convention (something that our script hinges on) that can only mean that we already have these three user accounts in Active Directory:

kenmyer01

kenmyer02

kenmyer03

That also means that all we need to do is increment the record count by 1 and we’ll know which user account to create next: kenmyer04. Again, assuming you stick with the naming convention, everything should work just fine.

Note. What do we mean when we say “stick with the naming convention?” Well, suppose you manually create two users accounts: kenmyer and kenmyer03. Is that a problem? As a matter of fact, it is. When we search Active Directory we’ll discover that there are two accounts that have samAccountNames beginning with the letters kenmyer. The script will thus assume that the next account to be created should be kenmyer03. Unfortunately, though kenmyer03 already exists. Admittedly, there are ways that we can handle that problem, but we won’t worry about it today. If there’s enough interest in this, we’ll return to it in a future column.

Let’s take a look at the script:

On Error Resume Next

Const ADS_SCOPE_SUBTREE = 2

strName = “kenmyer” strSearchName = strName & “*”

Set objConnection = CreateObject(“ADODB.Connection”) Set objCommand = CreateObject(“ADODB.Command”) objConnection.Provider = “ADsDSOObject” objConnection.Open “Active Directory Provider” Set objCommand.ActiveConnection = objConnection

objCommand.Properties(“Page Size”) = 1000 objCommand.Properties(“Searchscope”) = ADS_SCOPE_SUBTREE

objCommand.CommandText = _ “SELECT AdsPath FROM ‘LDAP://dc=fabrikam,dc=com’ WHERE objectCategory=’user’ ” & _ “AND samAccountName = ‘” & strSearchName & “‘” Set objRecordSet = objCommand.Execute

intRecordCount = objRecordset.RecordCount intRecordCount = intRecordCount + 1

If intRecordCount < 10 Then strNewName = strName & “0” & intRecordCount Else strNewName = strName & intRecordCount End If

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”) Set objUser = objOU.Create(“User”, “cn= ” & strNewName) objUser.samAccountName = strNewName objUser.SetInfo objUser.SetPassword “password” objUser.AccountDisabled = False objUser.SetInfo

As you can see, we start out by defining a constant named ADS_SCOPE_SUBTREE and setting the value to 2; we’ll use this constant to tell the script to search all of Active Directory. Having said that, that’s pretty much all we will say about the code we use to conduct an Active Directory search. If you’re unfamiliar with Active Directory search scripts then you might want to take a look at our two-part Tales from the Script feature Dude, Where’s My Printer?

After defining the constant we then assign values to a pair of variables:

strName = “kenmyer”
strSearchName = strName & “*”

You can probably figure out what we’re going to do with the variable strName: that variable contains the string of letters (kenmyer) we’re searching for. It might not be so obvious, however, why we’re assigning the value kenmyer* to the variable strSearchName. Oh, right: considering the fact that we named the variable strSearchName it actually is kind of obvious, isn’t it? Well, you’re right: strSearchName is simply the search string we’re going to use; as we noted earlier, we want to get back a collection of all the user accounts where the samAccountName begins with the letters kenmyer. To do that we simply specify the letters we want to search for and then tack on an asterisk to use as a wildcard character.

Note. When searching Active Directory the wildcard character simply represents “anything,” meaning that, in this script, we’re searching for all samAccountNames that begin with kenmyer followed by anything (or even by nothing).

After assigning values to our two variables we then encounter a big block of code that actually performs the Active Directory search. Like we said, we won’t discuss that code in any detail today; all we’ll do is point out the query we use for retrieving the user accounts:

objCommand.CommandText = _
    “SELECT AdsPath FROM ‘LDAP://dc=fabrikam,dc=com’ WHERE objectCategory=’user’ ” & _
        “AND samAccountName = ‘” & strSearchName & “‘”

We’re just searching for all the user accounts (objectCategory = ‘user’) that have a samAccountName equal to the search variable strSearchName. Pretty simple, really.

That brings us to this part of the script:

intRecordCount = objRecordset.RecordCount
intRecordCount = intRecordCount + 1

In the first line of code we’re setting a variable named intRecordCount to the value of the RecordCount property; it probably comes as no surprise that RecordCount simply tells us the number of records in the returned dataset (or, more specifically, the number of users with a samAccountName that begins with kenmyer). In the second line of code we then increment the value of intRecordCount by 1. Why? Well, suppose we get back two records. That means the next account we create should be kenmyer03. Because 2 + 1 = 3, we increment the current record count by 1.

And, yes, all those years of high school and college math have resulted in this: we know that 2 + 1 = 3. Time and money well-spent!

Note. What if the record count equals 0? That’s OK: that just means we don’t have any kenmyer* accounts at the moment. That also means that when we increment the record count by 1 we’ll get, well, 1; thus the next account we create will be kenmyer01. Which is just as it should be.

In the next section of code we then create a name for the new account:

If intRecordCount < 10 Then
    strNewName = strName & “0” & intRecordCount
Else
    strNewName = strName & intRecordCount
End If

What we do here is first check to see if the record count is less than 10. If it is, we create a user account using these three elements:

The user name (kenmyer), as stored in the variable strName.

A 0.

The record count.

Why do we toss the 0 into the middle? That’s easy: that gives us accounts like kenmyer02 and kenmyer03 rather than kenmyer2 and kenmyer3. That maintains consistency, and also makes it easier to view and sort the account names. If the record count is 10 or more we create the user name using only the variable strName and the record count. For example:

kenmyer + 11 = kenmyer11

And now we’re ready to create the account:

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
Set objUser = objOU.Create(“User”, “cn= ” & strNewName)
objUser.samAccountName = strNewName
objUser.SetInfo
objUser.SetPassword “password”
objUser.AccountDisabled = False
objUser.SetInfo

This really isn’t the time or place to discuss the ins and outs of creating user accounts in Active Directory. If the preceding code looks a bit mysterious to you, don’t fret; instead, check out the Active Directory Users chapter in the Microsoft Windows 2000 Scripting Guide.

And that’s it: each time we run the script we’ll create a new, properly-incremented kenmyer* account. Turns out that this human cloning thing isn’t that big of a deal after all.

Note. Nonetheless, we do need to set the record straight on one thing. The army of clones we created didn’t actually go around terrorizing the countryside. Instead, being clones of the Scripting Guys they pretty much lounged around the office all day, surfing the Internet, taking coffee breaks, and then going home early in order to coach baseball. Or at least they said they were going to “coach baseball ….”

Author

0 comments

Discussion are closed.