Simplifying Network Options Through Logon Scripts

By Brien M. Posey, MSCE

Published in TechRepublic's Windows Support Professional (TechRepublic.com)

Whether your network consists of a few PCs or thousands of computers, your workload will be a lot lighter if you standardize things as much as possible. This process can mean using a standard format for such items as paths and drive mappings. One easy way of setting parameters is through logon scripts. In this article, we'll show you how to create logon scripts and we'll explain the various options you can use with them. We'll also explain how to replicate logon scripts.

On This Page

What are logon scripts?
Writing a logon script
Logon script options
Enabling logon scripts
Why don't logon scripts always execute?
More about directory replication
Network speeds
Conclusion

What are logon scripts?

Logon scripts are short programs that execute each time a user logs in. Typically, a logon script will set the user's parameters, such as drive mappings and file locations. However, a logon script can run any executable program or batch file.

If you have more than a few users, you probably don't like the thought of writing a separate program for each user. Fortunately, logon scripts support the use of several variables. By using these variables, you can write one generic logon script that works for everyone, rather than hard-coding information and having to write a separate logon script for each user.

Writing a logon script

We mentioned that a logon script can run special commands or any executable program, but that doesn't really tell you a lot. Typically, a logon script is a batch file that contains appropriate commands. You can use any MS-DOS command, the special logon script variables we'll discuss later, and (when necessary) calls to other executable programs. If you've migrated from NetWare to Windows NT Server, you can even process NetWare logon scripts without modification.

We should mention that although you can call executables via a logon script, it's usually considered bad style to launch application software in this way. Unless the program in question runs quickly and then closes—for example, a program that displays a security banner—you should usually launch software in the usual manner rather than through a logon script.

Logon script options

As we mentioned earlier, you can use several variables with logon script commands. Keep in mind that, when typed directly from a command prompt, these variables won't work. They work only when embedded in a batch file. Following is a list of these variables and their function. It's also handy to know that you can use these variables in any batch file, not just in logon scripts.

%PROCESSOR%

The %PROCESSOR% variable is supposed to change to a value equal to the type of microprocessor in your PC. However, in our testing we've been unable to make this variable function the way it's supposed to.

%HOMEDRIVE%

The %HOMEDRIVE% variable is linked to your home hard disk. By default, your home hard disk is C. However, you can change this value through User Manager for Domains. To do so, simply open User Manager for Domains and double-click the user account. When you see the User Properties sheet, click the Profile button. You'll see the User Environment Profile dialog box, shown in Figure A.

Figure A: The User Environment Profile dialog box allows you to change several environment variables.

As you can see in the figure, we've elected to map the Z drive to a network path rather than using a local path. %HOMEDRIVE% becomes Z instead of C.

%HOMEPATH%

The %HOMEPATH% variable contains the path of the user's home directory. Notice in Figure A that we're connecting the Z drive to \\titanium\h$\USERS\Administrator. In such an example, the home path would be the path on the network share, or in this case \USERS\Administrator. This is the directory where the operating system will attempt to save all files unless you tell it otherwise.

%HOMESHARE%

%HOMESHARE% is the variable that contains the other part of the path to the user's home directory. Using the example shown in Figure A, the %HOMESHARE% variable would contain \\titanium\h$.

%OS%

The %OS% variable represents the operating system you're using. %OS% is handy for mapping a network drive to a public directory that contains resources for your specific operating system. For example, suppose you have directory called PUBLIC that everyone has read access to. You could create subdirectories below the PUBLIC directory named after the various operating systems. Each subdirectory could contain service packs and other patches for its respective operating system. You might then include a line similar to the following in a logon script:

NET USE Q: \\TALAINIA\E$\PUBLIC\%OS%

When users log on, the logon script would automatically map a drive to a folder containing all the latest patches for their specific operating system.

%USERDOMAIN%

The %USERDOMAIN% variable represents the name of the domain that the user is currently logged onto. %USERDOMAIN% is handy for mapping network drives in situations where you may have resources with common names, but in different domains.

%USERNAME%

The %USERNAME% variable displays the name of the user who's currently logged on. If you wanted to map a network drive to a path that included a directory name matching the user name, you could use this variable in a command similar to the following:

NET USE Q: \\TALAINIA\E$\USERS\%USERNAME%

Sample syntax

Although this isn't a real-world example, Figure B shows an example of the correct syntax for each logon script variable. You can see this batch file's output in Figure C. You'll notice that in this case we executed the batch file directly rather than calling it from a logon script. Because you can execute such a batch file directly, it's often handy to create a similar batch file and place it in a public directory. That way, if you were working and couldn't remember which account you logged on with, you could execute the batch file to find out. If you really wanted to get creative, you could name such a batch file WhoAmI.bat, because it offers the same functionality as the NetWare command WHOAMI.

Figure B: This batch file shows the correct syntax for each logon script variable.

Figure C: Here's the output from the batch file shown in Figure B.

Enabling logon scripts

The keys to enabling a logon script are placing the script file in the correct directory and telling Windows NT the name of the file. The correct location for the logon script file is the \Winnt\System32\Repl\Import\Scripts directory on your primary domain controller.

Once you've copied your logon script file to this directory, open User Manager for Domains. Next, double-click on each user to open his or her properties sheet. When you see a user's properties sheet, click the Profile button. Type the filename of the logon script in the Logon Script Name text box, as shown in Figure D. The logon script should execute when a user logs on. Keep in mind that depending on the speed of your network and the commands in the script, the logon script may execute too quickly to see much more than a blur of an MS-DOS Prompt window.

Figure D: Specify the name of the logon script in User Manager for Domains.

Why don't logon scripts always execute?

There's a good chance that you may run into a situation in which a logon script executes sometimes but doesn't execute at other times. If you're puzzled by this behavior, keep in mind that it isn't always the primary domain controller that validates logons. If the primary domain controller is busy, a backup domain controller may perform the validation. When this happens, Windows NT looks to the \Winnt\System32\Repl\Import\Scripts directory on the backup domain controller for the logon script file. If this file doesn't exist, Windows NT ignores the request to process a logon script.

Replicating logon scripts

The solution to this problem is to make Windows NT replicate the logon script to each backup domain controller. You can accomplish this task by using Windows NT's Directory Replicator service. Before you can use this service, you must create a special Windows NT account that's used exclusively for directory replication. You can call this account anything you want, but it must be a member of the Backup Operators and Replicators groups. You should also set this account's password to never expire.

When you've created a replication account, you're ready to begin configuring the Directory Replicator service. To do so, open Server Manager and select your primary domain controller. Next, select the Services command from the Computer menu. When you do, you'll see the Services dialog box. Double-click the Directory Replicator service to open the Services Properties sheet for the Directory Replicator service. Click Automatic and This Account and fill in the information for the account you created earlier, as shown in Figure E.

Figure E: Enable the service and provide your account information.

Click OK to close the properties sheet and click OK again to clear the message that the account has been granted rights to log on as a service. Now, with the Directory Replicator service selected, click Start. After about a minute the service should start. Click Close to close the Services dialog box.

Now that the service is running, make sure that the primary domain controller is still selected and select the Properties command from the Computer menu. When you see the primary domain controller's properties sheet, click Replication. The Directory Replication dialog box will open, shown in Figure F.

Figure F: The Directory Replication dialog box lets you control which directories are replicated.

As you can see, this dialog box is divided into two sections. The left side is for exporting information, and the right side controls importing information. Click Add on the export side and add all the servers to which you want to export directory information. A single server can act as both an export and an import server. If you want to import directory information, add to the import side the name of the server from which you want to import, as shown in Figure G. Otherwise, click Do Not Import. Click OK to continue.

Figure G: Configure the servers you wish to import to and export from.

At this point, you should still have Server Manager open. Select a backup domain controller and then choose the Services command from the Computer menu. Now, enable the Directory Replicator service the same way you did on the primary domain controller. When you've enabled the service and supplied the service account and password, close the service's properties sheet and start the service.

When the service starts, click OK to close the Services dialog box. Now, double-click on the backup domain controller and click the Replication button. Unless you want to export files on your backup domain controller, click Do Not Export. Next, add your primary domain controller to the From List, as shown in Figure H. Click OK to close the service's properties sheet, and click OK again to close the backup domain controller's properties sheet. Repeat this procedure for each backup domain controller.

Figure H: Add your primary domain controller to the From List.

Replication should begin shortly. You can verify replication by checking the \Winnt\System32\Repl\Import\Scripts directories on your import servers.

More about directory replication

You may wonder about the Directory Replicator's uses and what its limitations are. Let's answer those questions.

What can directory replication be used for?

You can use the Windows NT Directory Replicator Service to replicate any information between servers, as long as you're aware of the service's limitations. You should only replicate information that's read-only or that rarely changes. For example, you could consider replicating a directory containing electronic copies of the various forms that your company uses. You could also replicate user profiles.

What are the limitations of the Directory Replicator service?

As with anything in the world of computers, you've got to play by the rules if you want the Directory Replication Service to work. However, Microsoft has confirmed a number of bugs in the Directory Replicator Service, so there's a chance that even if you play by the rules and set up everything correctly, it still may not work. The best way to ensure that your replication will work correctly is to make sure Service Pack 4 is loaded on all servers involved in replication. With that said, let's discuss the service's other limitations.

Open files

The Directory Replicator Service isn't capable of replicating open files. You should make sure that any files you're planning to replicate don't change very often, because heavily used files may not be replicated during the day if they're in use.

Synchronization

The Directory Replicator Service only replicates information—it doesn't synchronize data. For example, suppose you export information from Server A to Server B. Now, suppose that someone changes the copy on Server B. The changed information won't be replicated back to Server A. Instead, Server A will overwrite the changed information with the original data during the next replication cycle.

File systems

Directory replication can occur only between like file systems. This means that if your export server is using FAT, your import server must also use FAT. Likewise if your export server is using NTFS, your import server must also use NTFS.

Computers that can replicate

You can only use Windows NT servers to export data. However, you can import data using either NT Server or NT Workstation.

The replication directories

Figure I shows the structure of the \Winnt\System32\Repl directory. As you can see, we didn't place our logon scripts directly into the Export or Import directories, but rather into a Scripts directory beneath them. That's because the Directory Replicator service can only export directories (and their contents) from the Export directory. It won't export files placed directly into the Export directory. For example, if you wanted to export the file Readme.txt, you couldn't place it directly into the \Winnt\System32\Repl\Export directory. However, you could create a directory called Docs and place the file into it. NT could then export the \Winnt\System32\Repl\Export\Docs directory and your file with no problem.

Figure I: If you place a file directly into the \Winnt\System32\Repl\Export directory, the file won't replicate.

Network speeds

You should avoid replicating large amounts of information between servers connected by a slow network link. Doing so can place a large volume of traffic on the link and bring productivity to a screeching halt.

Conclusion

In this article, we've discussed how using logon scripts can help you standardize some parameters on your network. We also explained the importance of having a copy of all logon scripts on each domain controller. Finally, we demonstrated the process of replicating logon scripts to your domain controllers.

Brien M. Posey is an MCSE and a freelance technical writer. He also works as a network engineer for the Department of Defense. You can contact him via E-mail at Brien_Posey@xpressions.com. (Because of the large volume of E-mail that he receives, it's impossible for him to respond to every message. However, he does read them all.)

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.