Logon scripts can be useful tools for configuring desktop environments for users. Some of the things such scripts can be used for include mapping network drives, connecting to shared printers, gathering system information, synchronizing system clocks, and so on. In fact, just about anything you can do from the command-line can be done using a logon script.

Logon scripts have been around for a while and most administrators of Windows-based networks have had occasion to use them. On Windows NT domain-based networks things were simple: if a user needed to have his environment configured using a logon script, the administrator would first write a logon script using the batch programming language, which has been around since the days of MS-DOS. Once written, this script was saved using a .bat extension to make it executable, but to make it work for a particular user the script needed to be found in the NETLOGON share of the domain controller to which the user’s account was authenticated. In Windows NT this NETLOGON share corresponded to the %systemroot%\system32\repl\import\scripts folder, and by placing the script in this folder on the PDC it was automatically replicated to all BDC’s in the domain. Once this was done, the administrator only had to add the name of the script to the Logon Script Name field on the User Environment Profile dialog box using User Manager for Domains...

Then Windows 2000 came along, with its support for assigning logon scripts using Group Policy and its built-in support for Windows Script Host (WSH) as an alternative for traditional batch scripts. While WSH lets you create much more powerful logon scripts and Group Policy lets you manage logon scripts more easily, a problem arises when your networking environment has a mix of desktops that include legacy platforms like Windows 95/98 and Windows NT 4.0 Workstation. The rest of this article provides some suggestions for managing logon scripts in both a mixed (Windows 2000/XP/2003 and legacy Windows 95/98/NT) environment and a pure Windows 2000 (or later) environment.

Using Logon Scripts in a Mixed Environment

By “mixed environment” I mean a mixture of Windows clients that support Group Policy (Windows 2000/XP/2003) and those that don’t (Windows 95/98/NT). Managing logon scripts in environments that include Linux/UNIX or Mac desktops is beyond the scope of this discussion. For simplicity, we’ll focus here on Active Directory environments that have domain controllers running Windows 2000 Server and/or Windows Server 2003 and a mix of current and legacy Windows desktops.

Let’s say you want to use a logon script in a mixed environment to configure users’ desktop environments by mapping a drive letter to a network share. A simple batch file logon script that does this might be this:

@echo off
net use x: \\filesrv\budgets

To use this script, type it into Notepad and save it as logon.bat or something similar. Then put the script into the NETLOGON share on a domain controller, which if your domain controllers are running Windows 2000/2003 can be found at %systemroot%\sysvol\sysvol\<domain_DNS_name>\scripts as shown in Figure 1:

Figure 1: Location of NETLOGON share on Windows 2000/2003 domain controllers

Once this script is placed in the NETLOGON share it will automatically replicate to all domain controllers in the mynewforest.com domain.

The next step is to assign the logon script to the user accounts of users who need to have the script run on their desktop machines. To get the script to run on Bob Smith’s machine, for example, use Active Directory Users and Computers to open the Properties sheet for the User object representing Bob Smith and select the Profiles tab. Then simply type the name of the script in the Logon Script field as shown in Figure 2 below. Note that if you store your logon script in a different share than NETLOGON, you should type the full UNC path instead to the script in the Logon Script field below but make sure the script replicates to all your domain controllers.

Figure 2: Assigning a logon script to user Bob Smith

If you want to leverage the power of Windows Script Host in a mixed environment, you can do so two ways:

• Download and install the appropriate Directory Services Client (DSClient) for Windows 95/98 or Windows NT. DSClient allows these legacy Windows platforms to participate in an Active Directory environment and they include support for WSH and VBScript. To obtain DSClient for the appropriate platform, see article 288358 in the Microsoft Knowledge Base.
• Download and install Windows Script Host for Windows 95/98/NT. Doing this lets you run VBScript scripts on these platforms, but it doesn’t give you ADSI functionality so this limits the usefulness of WSH for scripting purposes. You can obtain WSH for Windows 95/98/NT from the Microsoft Download Center.

Either way, once your legacy Windows desktops support WSH you can write your logon scripts in the more powerful VBScript language instead of the limited batch programming language. Unfortunately, in a mixed environment you can’t directly assign a .vbs script to a user account on the Profile tab as shown in Figure 2 above as this won’t work on legacy Windows clients. The workaround to this problem is to do the following:

1. Write your logon script using VBScript and save it with a .vbs extension, for example logon.vbs.
2. Store your logon.vbs file in the NETLOGON share on your domain controller.
3. Use the batch programming language to write a traditional logon script that calls your logon.vbs script and save it with a .bat extension, for example logon.bat.
4. Store your logon.bat file also in the NETLOGON share on your domain controller.
5. Assign logon.bat on the Profile tab of each user account as described previously above in Figure 2.

A simple logon.bat script that calls a logon.vbs script would be the following:

@echo off
wscript %0\..\logon.vbs

And a simple logon.vbs script that maps the x: drive to the \\filesrv\budgets share would be:

Dim wshNetwork
Set wshNetwork = CreateObject("Wscript.Network")
wshNetwork.MapNetworkDrive "x:", "\\filesrv\budgets"
WSCript.Quit

Now when Bob logs on to his machine, logon.bat executes and calls logon.vbs which maps x: drive to the budgets share as desired. And this will work on both your legacy Windows 95/98/NT desktops and your newer Windows 2000/XP desktops.

Using Logon Scripts in a Windows 2000 or Later Environment

If all your desktops are running Windows 2000 or later, then the first thing you should do is forget the Profile tab as far as logon scripts are concerned. In fact, forget the Profile tab entirely as the fields on this tab are provided only for downlevel (Windows NT or earlier) environments. Instead, use Group Policy to assign your logon scripts, which is a far more powerful and flexible approach than what the Profile tab provides. Furthermore, forget the batch programming language and use VBScript to write your logon scripts as this lets you create far more powerful scripts than batch scripts. If you haven’t yet learned VBScript.

Let’s use our logon.vbs script above that maps a drive and assign it to all our company employees in Winnipeg. The beauty of Active Directory is that you can create organizational units (OUs) for different locations or departments in your company and then create Group Policy Objects (GPOs) and link them to each OU. In Figure 3 you can see that we have three OUs in our mynewforest.com domain: Toronto, Vancouver, and Winnipeg:

Figure 3: Users in the Winnipeg OU need a logon script assigned to map a network drive

To assign logon.vbs to the users in Winnipeg, right-click on the Winnipeg OU and select Properties. Then select the Group Policy tab, where you can see we’ve already created a new GPO named WinnipegGPO and linked it to this OU (Figure 4):

Figure 4: The WinnipegGPO is linked to the Winnipeg OU

Click Edit to open the WinnipegGPO and navigate to User Configuration\Windows Settings\Scripts as in Figure 5 below:

Figure 5: Policy settings for assigning logon and logoff scripts

Now right-click on Logon in the right-hand pane and select Properties (Figure 6):

Figure 6: Assigning a new logon script using the WinnipegGPO

Click the Show Files button to open the default folder where logon scripts assigned using Group Policy are stored on your domain controller (Figure 7):

Figure 7: Default folder where logon scripts assigned using Group Policy are stored on a domain controller

Note from this figure that logon scripts assigned using Group Policy are stored in a subfolder of the SYSVOL share on your domain controllers. This subfolder of SYSVOL is named \sysvol\<domain_DNS_name>\<policy_GUID>\user\scripts\logon and the contents of this folder (being in SYSVOL) are automatically replicated to all domain controllers in the domain.

Now, using Windows Explorer, find the logon.vbs script we created earlier and press CTRL+C to copy it to the clipboard. Then return to the folder in Figure 7 above and press CTRL+V to copy logon.vbs into the folder where it needs to be. Close the folder window and return to the Logon Properties screen in Figure 6 previously and click the Add button to open the Edit Script dialog box, and in the Script Name field type logon.vbs, the name of the script you want to assign (Figure 8):

Figure 8: Assign the logon script

Click OK twice and the script has been assigned. Now once Group Policy refreshes on Bob’s machine, the next time he logs on to his machine he’ll see X: drive when he opens My Computer or Windows Explorer.