User-account management is one duty all administrators share. Microsoft encourages the use of User Manager (or User Manager for Domains) to add, modify, or delete an account. The more often you need to manage accounts, however, the more you realize how time-consuming User Manager is. For example, the tool requires at least eight clicks to disable or rename an account. To create a new account with a few group memberships, a home directory, and a profile path, you might need to click more than 20 times—that's too many clicks.
Command-line methods are much easier and faster than User Manager. You can find such utilities—including Addusers, Xcacls, Nltest, Sleep, Rmtshare, and Cusrmgr—in the Microsoft Windows 2000 Server Resource Kit and the Microsoft Windows NT Server 4.0 Resource Kit. When you understand how these management utilities can work together, you'll be in a better position to simplify account management and your environment.
New User Accounts
The most basic component of user-account management is creating new user accounts. As part of this process, you probably also need to create the accounts' home-directory and profile paths, set permissions on the home and profile directories, and set shares on the home directory.
Command-line tools can speed up the creation process, but manually running each tool to create each user account would detract from the utilities' timesaving benefits. To easily avoid this problem, you can write a simple batch file, called newu.bat, that incorporates the code for each tool and each step in the account-creation process.
To show you how this batch file works, let's create an account for a new user named Jennifer Hansen. Her username is jhansen, and her account description is management. Her home directory settings point to the H drive on a local file server named servera, and she has a roaming profile on servera. Her home and profile folders are both in her name. Her password is temppwd. Her account runs logonscr.bat as a logon script. (Figure 1 shows the newu.bat file in its entirety.)
Create the account. Your first task is to actually create the new user account. The resource kits' Addusers tool is ideal for this purpose, especially if you map drive letters for home directories. (If you'd rather not use a resource kit tool, you can use the Net User command to complete this step, although Net User doesn't work when you connect with Uniform Naming Convention—UNC—paths for home directories. For information about using Net User, see the sidebar "A Simple Command.") Addusers is useful for creating single user accounts but is also a great tool for creating multiple accounts simultaneously.
The tool involves a two-part process: First, you must create an import text file to use with addusers.exe; second, you must run addusers.exe. The text file must follow a standardized format:
username,first_name last_name, password,account_description, home_drive_letter:,home_drive_ path,profiles_path,logon_script_name
You can give this file a simple name, such as username.txt, where username is the name of the user for whom you're creating the account. For Jennifer, create the following file named hansen.txt:
\[User\] hansen,Jennifer Hansen,temppwd, management,H:,\\servera\hansen$, \\servera\profiles$\hansen,logonscr.bat
To create hansen.txt on the fly, begin the newu.bat script with the following code, which reads in parameters from the command line:
echo \[User\] > \\adminhostscripts\newusers\%1.txt echo %1,%2 %3,%4,%5,H:, \\servera\%1$,\\servera \profiles$\%1,logonscr.bat >> \\adminhost\scripts\newusers\%1.txt
After you create the text file, run Addusers to create the new user account. You can use Addusers to create user accounts on a local accounts database or on the domain SAM. When you use Addusers to create accounts on a domain, be sure to specify the PDC. To create a nondomain account, specify the remote computer instead. To create Jennifer's account on a domain with the PDC pdcserver, add the following line to newu.bat:
addusers \\pdcserver /c \\adminhost\scripts$\newusers \%1.txt
The /c switch signals Addusers to create a new account. (You can also use Addusers to delete accounts. For more information about Addusers, see Mark Minasi, This Old Resource Kit, "AddUsers," May 1998.)
The new user account that you just created might not exist on all domain controllers (DCs). Therefore, you'll want to use the resource kits' Nltest utility to force a synchronization of the account database with all DCs:
nltest /server:pdcserver /pdc_repl
The /pdc_repl option forces a change message to all BDCs, informing them that an update has occurred on the User Accounts Subsystem. The message travels through a pulse that contains the serial number for each database. The message contains information about changes or updates only.
Consider throwing in a Sleep command (yet another resource kit tool). The following sleep.exe command instructs the batch file to wait 30 seconds for the DCs to sync before continuing:
sleep 30
Review your DC's event logs to get an idea of how many seconds of sleep your PDC needs to synchronize with the BDCs.
Create a home directory and profile path. After you create a user account, you usually need to create the accounts' home and profile directories as well. Creating these directories is easy. For Jennifer's user account, add the following commands to the newu.bat file:
mkdir \\servera\users$\%1 mkdir \\servera\profiles$\%1
Notice that this example hides the shares. This action prevents users from browsing top-level directories. (The new directories take advantage of existing higher-level shares.)
Set permissions. Next, I need to set permissions on the directories. Permissions for user directories can vary depending on the level of security in your company.
Time for another resource kit utility: Xcacls, which lets you modify NTFS permissions to the folder. (The resource kits' Cacls utility can also accomplish this task, but Xcacls is more powerful because you can be more specific with permissions and can disable confirmations.) To run Xcacls, I'll add the following lines to my newu.bat script:
xcacls \\servera\users$\%1 /g "domaina\%1":C /y xcacls \\servera\users$\%1 /e /g "domaina\domain admins":F /y xcacls \\servera\profiles$\%1 /g "domaina\%1":F /y xcacls \\servera\profiles$\%1 /e /g "domaina\domain admins":F /y
On the first line, the /g option by itself wipes out all previously applied access control entries (ACEs), then gives Jennifer's account Change permission for the home directory. On the second line, the /e option maintains existing permissions and the /g option gives domaina's Domain Admins Global group Full Control for the home directory. The /y option tells Xcacls to automatically answer yes to all prompts. The third and fourth lines repeat the process—this time specifying permissions for Jennifer's profile directory. (For more information about the Xcacls utility, see Mark Minasi, This Old Resource Kit, "XCACLS," March 1998.)
Create shares. Now that you've created the home directory and set the permissions, you can set shares on the folder. Savvy NT users typically use Server Manager or Windows Explorer to create shares, but to stick with the command-line mode, I'll use the resource kits' Rmtshare utility:
rmtshare \\servera\%1$=d: \users\%1
Although you can also use Rmtshare to set permissions on shares, I strongly suggest against setting permissions at the share level. You should use NTFS to set permissions at the file-system level. (For information about Rmtshare, see Mark Minasi, This Old Resource Kit, "Rmtshare," June 1999.)
Everything Changes
Addusers and Net User are excellent scripting methods for creating a new user account. But what do you do when account information changes (e.g., a user changes his or her last name, which is part of the user's username)?
To modify an account through User Manager, you need to rename the user, change the Full Name, and probably redefine the user's profile path and home directory path. Other necessary changes might include modifying Microsoft Exchange Server information (e.g., mailbox name, SMTP information). In the past, the command-line options for changing a user account have been extremely limited; you were typically restricted to renaming user accounts. Most of the functions that you could set when you created an account with Addusers or Net User weren't modifiable from the command line.
This situation has changed with the inclusion of Cusrmgr in the Win2K Server resource kit. (For information about this and other new resource kit utilities, see Michael Otey, "New Resource Kit Utilities," September 2000.) George Zanzen of Microsoft Consulting Services (MCS) wrote the tool in early 1998, but before Win2K, Cusrmgr was available only to MCS and Microsoft Product Support Services (PSS). Cusrmgr uses official APIs to communicate with the user account database. You can use the tool in a pure NT or a mixed-mode environment. The utility provides several switches to modify just about anything that you can use User Manager to change. The tool works on domains as well as member servers' and workstations' local accounts databases. The tool can remotely modify any database to which you have permissions. For an example of how to use Cusrmgr, see the sidebar "The Name Game."
If you use Win2K Server Terminal Services, you'll notice a lack of command-line support for account management. If you force specific profiles on Terminal Services users, you'll need to manually set those profile paths in User Manager from the Terminal Services server. At this time, Microsoft has no plans to modify Cusrmgr for Terminal Services.
Change Is Good
If you're still using User Manager to create all your user accounts, consider rethinking your approach. You can use several command-line tools from the Win2K and NT resource kits, in combination with some good scripting on your part, to reduce the number of steps you must take when managing user accounts. Scripting also ensures that accounts or groups are created the same way no matter who creates them. Make the switch, and make your company's account management scripted, standardized, and simple.