DOWNLOAD THE CODE:
Download the Code 22537.zip

Use scripting to manipulate your NT domain

Administrators encounter this scenario all the time: You show up on Monday morning, and the human resources (HR) department has a dozen new user accounts for you to set up. This setup doesn't include just accounts, either, but the new users' home directories, dial-in permissions, and more. Instead of spending the morning checking on your Microsoft Exchange Server or catching up on the latest news on the Web, you're stuck entering new-user information from a spreadsheet.

Scripting to the rescue! This type of task is not only well suited to scripting-based automation, it's also a great way to demonstrate several different scripting capabilities. Let me show you a script that can automate the task of adding new users to your Windows NT 4.0 domain.

Getting Started
For this example, let's assume you're working with an NT domain called Corporate that has a PDC called NT4PDC. You must set up a basic infrastructure to let your script work. First, create a Microsoft Excel spreadsheet such as the one that Figure 1, page 32, shows. The spreadsheet should include information for each user that you're adding to the domain. In this example, I've included columns for the user's ID, full name, description, and home directory Universal Naming Convention (UNC) path, a column for a comma-separated list of user groups to which the user should belong, and a column for indicating whether the user needs to have dial-in permissions. You can distribute your spreadsheet to HR department personnel and ask them to use it when they submit new-user requests. (Notice that the list of user groups doesn't include the Domain Users group because, by default, all users belong to Domain Users.)

Next, create a System ODBC Data Source Name (DSN) that points to the spreadsheet, as Figure 2, page 32, shows. (I recommend that you create a System DSN rather than a User DSN. Otherwise, if another user logs on to the same machine to run the script, the script will fail.) The DSN points only to the spreadsheet's location, so you can save new spreadsheets to the same location and the DSN will find them. In this example, I've created a DSN called Excel that uses the Excel ODBC driver to point to my spreadsheet. If your computer doesn't have an Excel driver, you must install the latest version of Microsoft Data Access Components (MDAC), which you can download from http://www.microsoft.com/data.

Finally, make sure that Windows Script Host (WSH) and Active Directory Service Interfaces (ADSI) are available on the computer on which you'll run the script. (Both are present on Windows 2000 Professional, Win2K Server, Win2K Advanced Server, and Win2K Datacenter Server computers.) Note that you must install ADSI even if you're going to be working with an NT domain. If you want to set up these components on an NT workstation, you must install WSH from the Microsoft Windows NT 4.0 Option Pack and ADSI from the Windows Platform software development kit (SDK), which is available from http://www.microsoft.com/msdownload/platformsdk/sdkupdate.

Writing the Script
When all the preliminary pieces are in place, you can get the script ready. Listing 1 shows the complete bulk-users.vbs script. Because a lot is going on in this script, I'll describe each section.

Part 1 of bulk-users.vbs uses ActiveX Data Objects (ADO) to create a connection to the ODBC DSN called Excel. Because that DSN points to my Excel spreadsheet, I have a database connection to the spreadsheet. Next, I use the Connection object's Execute method to retrieve all the information on Sheet1 of the spreadsheet. This information resides in an ADO Recordset object.

Part 2 of bulk-users.vbs uses ADSI to obtain a reference to the PDC. To use this script, you must replace NT4PDC with the name of the PDC in your environment. Changing the PDC name is easy because I've defined it in a variable rather than in each statement that requires the PDC name. Because the PDC's SAM is the source for the domain's account list, this reference lets me work with the domain accounts.

Part 3 of the script uses the Scripting Runtime Library's FileSystemObject object to open a new text file called passwords.txt. I use this .txt file to store the passwords I create for the new user accounts. The CreateTextFile method returns a reference to a TextStream object, which I store in the oTS variable. This step essentially makes the oTS variable represent the open text file, which in turn makes writing information to the file later easy.

The Work Begins
Now, all the preliminary scripting work has been done, and Part 4 of bulk-users.vbs can begin to create user accounts. The first few lines of Part 4 simply declare the variables that the script uses. The script then sets up the base path to the server on which the user's home directory will be created. Note that this path connects to the C$ administrative share.

The main work of this script is accomplished within the Do...Loop statement, which handles the record set one line at a time. The first six lines of code within the loop retrieve the new user's information from the record set and store that information in variables. (This step isn't strictly necessary, but it makes the information easier to work with.) Notice that the field names in the Recordset object correspond to the column names in the Excel spreadsheet. Next, I create a pseudo-random password by combining the first two characters of the new user's ID, the minutes from the system clock, the Julian date (i.e., a number from 1 to 365 indicating the day of the year), and the seconds from the clock. You can also create a password based on the username, Social Security number, or other information.

   Prev. page   [1] 2     next page



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

How about setting permissions on the user directories? Your script leaves everyone with full control over all home directories. (There are various methods, from using WMI to shelling out to CACLS.)

Richard

I would be really interested in how you would add a step to name the users logon script.

Jonathan Lackman

how do you make this work in a windows 2003 active directory tree

rick patsula

 
 

ADS BY GOOGLE