Automate Windows networks with logon scripts

Windows NT logon scripts can make an admin's life much easier, providing simple ways to do regular tasks. This article from contributor Pedro Sousa discusses logon scripts and explains what they can do for you.

Pedro Sousa

In Windows NT/2000 networks, logon scripts can enable administrators to standardize the computing environment on client machines, quickly make updates and changes to machines throughout the network, and perform other actions to automate network tasks. In this article, we will look at some of the variables that make logon scripts so valuable and give some examples of both simple and advanced logon scripts.

Understanding logon scripts
By Microsoft’s definition, an administrator can use logon scripts to automate tasks that will be performed whenever a particular user or a member of a particular group logs on to a computer system connected to a Windows NT/2000 domain. These scripts can use Windows environmental variables and can also call other scripts or executable programs. Logon scripts are frequently used to map network drives, start background processes, and initialize various options in the user environment.

Logon scripts are typically created with a text editor and must be saved in specific directories on Windows NT 4.0 servers and Windows 2000 servers. For Windows NT, you need to save the logon script on a primary domain controller in the directory \winnt\system32\repl\import\scripts. For Windows 2000, you can save the script on any domain controller in the directory \winnt\sysvol\domain\scripts.

If you’re totally new to logon scripts, I would also recommend checking out these resources:

Simple logon script examples
Let's look at some examples of simple logon scripts. We’re going to look at tasks such as mapping network drives, mapping network printers, and synchronizing with time servers. The following example covers these three tasks:
net use y: \\srvpdc\data
net use LPT1: \\srvpdc\printer1
net time \\svrpdc /set /yes

In this example, we’ve mapped drive Y: on the local machine to a network share called data on our main server, SRVPDC. We’ve mapped printer1 to LPT1 on the local PC. We’ve also synchronized the time setting on the PC with the time server, also SRVPDC.

But what about tasks that need to be done only to some users or groups in particular? You can address that by using conditional statements that run specific commands depending on the user or group. Let’s look at two examples:
If %USERNAME%=Administrator net use z: \\srvpdc\admtools
If ifmember.exe “HR” net use t: \\srvpdc\hr

In the first example, we’ve mapped the drive admtools only to the user Administrator. In the second example, we’ve mapped a share called hr to our human resources group based on the output of a tool called ifmember.exe, which you can find in the Microsoft Windows 2000 Resource Kit.

Logon script options
You can find the logon script options described in depth in the article “Simplifying network options through logon scripts” (recommended above), but here’s a short summary of some of the most useful variables:
  • %USERNAME%—Displays the name of the user who’s currently logged on
  • %USERDOMAIN%—Displays the name of the domain that the user is currently logged on to
  • %HOMEDRIVE%—Displays the logged-on user’s home drive set on the Computer Management Tool
  • %HOMEPATH%—Displays the path of the user’s home directory
  • %HOMESHARE%—Displays the share name of the user’s home directory
  • %PROCESSOR%—Displays the type of processor in the user’s PC
  • %OS%—Displays the operating system the user is using

Let’s look at some examples of some of these variables:
net use h: /home /user:%USERNAME%
if "%OS%" == "Windows_NT"

The first example uses the %USERNAME% variable to map a home share using the username of the logged-on user. The second one verifies the user’s operating system, which can be used to apply (or not apply) a service pack in a mixed-mode environment, as we will see in the next example.

Advanced logon script examples
Let’s take our last example and see how we can use logon scripts to update our service packs or our antivirus definitions.

A service pack update script would look like this:
if "%OS%" == "Windows_NT" goto NT_OS
if ErrorLevel 1 goto END
net use /delete W:
net use W: \\srvpdc\service
cd nt4sp6
update -u -f -n -o
net use /delete W:

In this script, we verify the %OS% to see if the user is logged on to a Windows NT machine. After that, we set up a network share on the user’s machine that we want to map the service pack share to. Finally, we run the service pack.

Now let’s take a look at the following script for an antivirus definition update:
net use v: \\srvpdc\virus$ /yes
if exist "c:\vupdate" goto :next
md "c:\vupdate"
if exist "c:\vupdate\vupdate.exe" deltree /y "c:\vupdate\vupdate.exe"
if not exist "C:\Program Files\AntiVirus\program.exe" goto :END
if exist "c:\vupdate\march16.txt" goto :END
goto :update
deltree /y  "c:\vupdate\*.*"
copy v:\march16.txt c:\vupdate
copy v:\vupdate.exe c:\vupdate
echo _______________________________________________
echo           -=AND WILL NOW BE UPGRADED=-
echo _______________________________________________
ECHO _______________________________________________
echo            -==== INFORMATION ====-
ECHO             -=REMEMBER=-
ECHO              -=DO A FULL SCAN=-
ECHO _______________________________________________
start  "c:\vupdate\vupdate.exe"

This example uses a different strategy. We start by mapping a network share that contains the software update. Then, we see whether the user already has a folder with the update. If so, we delete it. After that, we check to see whether the user has the antivirus program installed and has the current update. If not, we copy the files to the local machine and run the update. We know that we could run the update from the remote share, but this is a way to ensure that we apply the correct update and that we only do it once.

Logon scripts are a simple way of automating many network administration tasks. In this article, we have shown you a little bit of the power of these scripts. In my next article, we’ll look at how to build even more powerful scripts using Windows Script Host.
We look forward to getting your input and hearing your experiences regarding this important topic. Join the discussion below or send the editor an e-mail.

Editor's Picks