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.