Checking for Existing Accounts
You can't create an account if it already exists, so the QueryForUser subroutine makes sure a user account doesn't exist for the specified username. You can query either a domain or Active Directory (AD) for a user account. Querying the domain works for both Windows NT 4.0 and AD domains, so the QueryForUser subroutine, which callout A shows, queries domains rather than AD.
The QueryForUser subroutine uses ADSI to determine whether a certain user account exists. The subroutine first uses the WinNT namespace to connect to the domain that the sDomainName global variable specifies. The subroutine then uses the IADsContainer interface's Filter property to obtain all the user accounts, which the subroutine puts into an array. The subroutine examines each user account in the array to determine whether the username associated with the account (which the IADs interface's Name property returns) matches the username in the sUserName global variable. VBScript's LCase function lowercases the username in the sDomainName global variable and the username returned by the Name property so that the comparison isn't tripped up by case discrepancies. In most situations, VBScript is case insensitive. However, comparisons made with the = operator are case sensitive because this operator compares the ASCII codes of the involved characters. If a match occurs, the subroutine informs the administrator that the specified user account already exists, then quits.
Because sDomainName's username and the Name property's username are the same case, the script won't overlook a username capitalized differently from the way you supplied it to the script. However, because Windows logons are case sensitive, this script won't work properly if you have two user accounts with the same name but different capitalizations. Christa, christa, and CHRISTA are the same to VBScript but not to Windows.
Although you can use the WinNT namespace for any NT domain type (i.e., NT 4.0 or AD), the namespace is inflexible in that you can search only an entire NT domain and not a particular section of it because SAM domains don't recognize organizational units (OUs). If you have AD, you can use the Lightweight Directory Access Protocol (LDAP) namespace, which lets you refine the search or extend the search.
Creating a User Account
If the specified user account doesn't already exist, the CreateUser subroutine creates the account. This subroutine takes advantage of the administrator's input collected earlier to put the account in the proper domain.
As callout B shows, the CreateUser subroutine again uses the WinNT namespace to connect to the domain that the sDomainName global variable specifies. Next, the subroutine uses the IADsContainer interface's Create method and the username in the sUserName variable to create a user account. The subroutine uses VBScript's Set statement to link, or associate, the new user object with the oUser variable.
Now that an object represents the user account, the subroutine assigns the account a password with the IADsUser interface's SetPassword method. (Although assigning a password in this manner is unrealistic in the real world, this sample code demonstrates how to set the user object's properties.) The subroutine then uses the IADs interface's SetInfo method to write the new user object to the directory. When you work with ADSI, you're not actually manipulating the directory; you're manipulating the cache. You must use the SetInfo method to write to the directory.
The last step in creating the account is to enable the account by setting the account's AccountDisabled property to FALSE. You must use the SetInfo method before you enable the account. If you reverse those steps, you'll get the error message, The specified Active Directory object is not bound to a remote resource.
Assembling the Script
After you've written and tested all the pieces of code, you can assemble those pieces into a script. Relatively speaking, this task is the simplest part of the scriptwriting process, as long as you follow these guidelines:
- Before assembling the script, double-check that each piece works as you expect it to. Troubleshooting a short module or procedure is much easier than troubleshooting an entire script. Knowing that the individual pieces work as expected doesn't eliminate the need to test and debug the assembled script. However, if you encounter a problem with the assembled script, you've narrowed down the possible sources of the problem considerably. If you're having trouble making a piece of code or the entire script work, use the WScript.Echo method to send the output to the screen so that you can see what the code is doing.
- Put all procedures at the beginning of the script. For execution purposes, the procedures' location doesn't matter. As I mentioned previously, procedures won't run until you call them. However, putting them at the top of the script can help remind you what the script should be doing. This placement also makes determining whether a variable should be global or local easier.
- Think about whether to use global or local variables. Local variables make reusing a procedure easier because the associations between the variables and the objects they represent are contained within the procedure. If the value of a global variable changes in the course of a script's execution, a procedure can fail if it uses that global variable and the new value doesn't work. However, associating a variable with an object every time you need the object can slow a script's execution. In CheckNCreateUser.vbs, sUserName and sDomainName must be global variables because their values come from input that the script obtains outside the QueryForUser and CreateUser subroutines. However, oDomain and oUser are local variables in both the QueryForUser and CreateUser subroutines, which makes the subroutines easy to reuse in other scripts.
An Important Step in the Scripting Learning Curve
As CheckNCreateUser.vbs demonstrates, you can use ADSI to not only test for the existence of a user account but also to create an account. This script also demonstrates how to use procedures and how to collect input from administrator-supplied arguments. The latter ability will come in handy as you begin to create administrative scripts that can't gather all the necessary data from a computer or a directory.
End of Article
Prev. page
1
2
[3]
next page -->
