by Dan DiNicolo
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
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.
In a Windows NT 4.0 domain environment, assigning scripts to users was more or less restricted to simple logon scripts. In a Windows 2000 domain, however, the power of Group Policy unleashes script deployment capabilities that make NT 4.0 pale in comparison.
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