In a Windows NT 4.0 domain
environment, assigning scripts to users was more or less restricted to
simple logon scripts. Not particularly flexible, but generally enough to get
the basic jobs done - mapping directories, printers, environment variables,
and so forth. For all intents and purposes, however, you were still in a
simple batch file environment. In order to get into any more advanced
scripting, you needed to use an additional scripting language such as
Kixstart. In a Windows 2000 domain, however, the power of Group Policy
unleashes script deployment capabilities that make NT 4.0 pale in
For those who like their networks a little old school, you can still deploy logon scripts in the properties of a user account in a Windows 2000 domain. While this is still acceptable, it constitutes a waste of a wonderful opportunity. With Group Policy, not only can you deploy scripts to multiple users in a single step, you can also define scripts settings in a hierarchical fashion. Scripts can be assigned not only to all users in a domain, but also according to sites and OUs. In cases where multiple GPOs affect a user, multiple scripts can be applied. This capability represents a powerful feature that shouldn't be overlooked by system administrators.
Logon scripts aren't the only type that can be defined with Group Policy. GPOs can be used to apply Logon and Logoff scripts to Users, and Startup and Shutdown scripts to computers. As the names suggest:
- Logon scripts are applied once a user logs in
- Logoff scripts are applied once a user logs off
- Startup scripts are applied when a computer boots
- Shutdown scripts are applied when a computer shuts down
The ability to define scripts in these different ways provides an additional level of functionality not experienced in previous versions of Windows. Furthermore, you are no longer limited to simple batch scripts - more powerful VBScripts can be used to further extend the abilities of the administrator.
Before taking a look at how scripts are added to Group Policy Object settings, it is important to recall the order in which GPO settings are applied. The hierarchy will impact which settings will ultimately apply, based on the container that a GPO is linked to. The order of application is:
In this way, scripts assigned at the Site level are always applied first, followed by those associated with domains, and then OUs. As such, a setting that is applied at the Site level via a script may subsequently be overwritten by conflicting settings at the OU level. Just something to keep in mind before you decide to go crazy assigning scripts. As with all GPOs, you can always use the No Override and Block Inheritance settings to control which settings will actually be applied to users.
In the same way, it is also possible that multiple GPOs may be applied to the same object, for example an OU. In this case, just remember that GPO settings are always applied beginning with the lowest GPO on the list, followed by the next-highest GPO. In that way, Policy 3 would be applied first, followed by Policy 2, and finally followed by Policy 1 in the example below. Each successive policy will be overwritten by the one applied next in cases where conflicts exist.
Assigning a script to a GPO can be a little tricky, especially if you haven't done it before. The reason is that the script needs to be stored not just anywhere, but in the Group Policy template associated with the GPO. This is a special folder that is named according to the GUID of the GPO. If you follow a few simple steps, however, assigning a script and placing it in the correct location is easy.
Start off by opening a new or existing GPO, as shown below. In my example, I am going to assign a login script to all domain users, so I've created a new GPO at the domain level. Browse to the User Configuration - Windows Settings - Scripts (Logon/Logoff) section, as shown below
Double-clicking on the Logon icon at right brings up the Logon Properties window, as shown below.
This is where things get tricky. I have created a very simple script called logon.vbs and have saved it to my desktop, just to make it easy to find. If you click the add button shown above, you can browse to the script, and add any script parameters if necessary. If I browse to my desktop and select the file, however, it will not be applied correctly. The script needs to be stored in the GPT in order to function. In order to put it into the GPT folder, I need to find the folder - not only is this difficult, it is nearly impossible. In my case, the folder where the script needs to be stored is found at the following path:
Would I have found that on my own? Probably not. Because of this, an easier method is to choose the 'Show Files' button found on the Logon Properties box. If I click that button, it will open the folder above, and then I can simply cut-and-paste the logon script into this correct folder. Follow that up by clicking the Add button, which will automatically open to the correct GPT folder when you use the browse function. Choose the file just copied, click OK twice, and you're set - the script is now in the correct location to be assigned to user when they log in.
Using Group Policy to assign scripts is the recommended method in Windows 2000. Not only does it make script assignment flexible, it also saves an administrator considerable time and energy. I recommend you kiss the properties of a user account goodbye, and live a little with Group Policy script settings.