For the sake of this demonstration, my sample WAN has three locations: a headquarters in Chicago, a branch office in Los Angeles, and a branch office in New York City. I've given each office a three-character location code: CHI (for Chicago), LAS (for Los Angeles), and NYC (for New York City). The sample WAN is built on one NT 4.0 domain with a PDC and BDC in Chicago and BDCs in both branch offices. All servers referenced in the sample scripts have a primary function of file server and a role of DC. The primary file servers in each location use the following naming convention: location code + primary function + role + a two-character numerical ID. The Chicago PDC is named CHIDC01 (and performs only authentication services), the Chicago BDC is CHIFSDC02, the Los Angeles BDC is LASFSDC01, and the New York BDC, which isn't referenced in the sample scripts, is NYCFSDC01.
I used a similar approach when naming NT security groups and shares. Few administrators use the ability to assign a primary group in Win2K or NT environments. (The user account Primary Group attribute was originally designed to support Macintosh clients and POSIX compliance.) By default, all users are part of the Domain Users group, which becomes their default primary group. However, the KiXtart macro @PRIMARYGROUP can return this attribute, so when you assign each user a specific primary group, you can use that group to gain insight about users. For this example, I set the primary group for each user to the appropriate location and department, according to the naming convention location code + department. For example, users in New York's Sales department have the primary group _NYC_dptSales. The first set of characters specifies the location, and the second set specifies the department. The dpt prefix in the second set specifies that this group is a departmental group; an additional prj prefix in the second set would specify a project group.
I created a structure for data on each server. The structure lends itself to effective scripting and simplifies administration. If your company uses a different standard, you probably can alter the sample scripts to account for that standard. If your company doesn't have a standard for the location of user data or the location and name of network shares, consider creating one. The sample data structure establishes the following folder hierarchy:
Driveletter: Data Departments Sales\ [shared as dptSales]
Engineering\ [shared as dptEngineering]
HumanResources\ [shared as dptHumanResources]
Accounting\ [shared as dptAccounting]
Finance\ [shared as dptFinance]
Projects Projectname1\ [shared as prjProjectname1]
Projectname2\ [shared as prjProjectname2]
Users UserID1\ [shared as zhmUserID1$]
UserID2\ [shared as zhmUserID2$]
Etc.
Placing this structure below a data subfolder creates a simple mechanism for locating and moving information, if required. I created shares on subdirectories, as specified in brackets, then used the appropriate group to set security on each share. For example, the dptSales share's permissions would permit access only to the _LOC_dptSales group (where LOC is the location code pertaining to the server). If I needed to give each location's Sales group access to the sales share on each server, I could give access to a local domain group containing the global groups. Still using a location-specific group, however, let me determine each user's home server. I used this information later to map each user's user share and primary departmental share. Although Win2K and NT let you create a user's home directory in the user's profile, actually creating the individual user's share is helpful. Using the zhm prefix ensures that all user shares show up together in Server Manager (or any alphabetized list). Because user shares are specific to a user, I didn't want to encumber the browse list with several hundred names. Therefore, I appended the dollar sign ($) to the name to hide the share. This methodology might not be well suited to extremely large environments because of the number of user shares required, but utilities are available to help automate the creation of user-specific shares.
Web Listing 1 (http://www.winscriptingsolutions.com, InstantDoc ID 25276) shows the sample script kixtart.kix. This script first defines the key variables used throughout the script. I store KiXtart macro values in variables for two reasons. First, the KiXtart macros reference and use information from the NT SAM database, so referencing them only once requires the least amount of traffic between client and server. (I've heard, however, that the benefit on a switched network is negligible.) Second, using variables is good form for application development. Although KiXtart isn't a full-fledged application-development tool, a good practice is still a good practice.
The script implicitly declares each variable, so the variables have Global scope (see "KiXtart Scripting Basics" for more information about variable scope). From the primary group, the script derives the variables that define location code, primary group, and home server. The script then uses this information to create variables containing the user's home share and department share. Next, the script begins mapping drives, according to the information stored in the variables. In each case, the script uses the EXIST() function to test the existence of the required resource. The script then calls msoffice.kix, which Web Listing 2 (http://www.winscriptingsolutions.com, InstantDoc ID 25276) shows.
Like kixtart.kix, msoffice.kix begins by setting necessary variables. Msoffice.kix then ensures that each user has a My Documents folder, with subdirectories for Microsoft Word, Excel, and PowerPoint, on his or her user drive. If these folders don't exist, the script creates them. The script then edits the registry, pointing the Microsoft Office applications to the appropriate folder. In this script, I've hard-coded the base drive to correspond to the drive mapped to the user share in kixtart.kix. Control is then returned to kixtart.kix, which presents a message box containing information about the logon session.
Working in Your Environment
Your environment might differ from my example, but you can modify and effectively use these scripts. (For suggestions, see the Web-exclusive sidebar "5 Tips for Scripts" at http://www.winscriptingsolutions.com, InstantDoc ID 25434.) I've used KiXtart for such projects as enabling DHCP on statically addressed workstations and assisting in the post-processing of imaged workstation deployment; I've also used the tool as a batch-command processor on my company's servers. KiXtart is an excellent resource for network administration and desktop automation.