Quick -- name three reasons why someone might use logon scripts in Windows.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
I can think of a few -- drive mappings immediately come to mind. For many years, logon scripts were the only workable solutions for automatically mapping drive letters to common file shares. For example, logon scripts can easily map the H: drive to a user's home folder, ensuring consistent access to data no matter where said user might log in.
A second reason to use logon scripts is to set user environment variables and registry keys. Recall that a Windows logon script executes as the user logs in. As such, it will run with that individual user's credentials, providing access to their registry hives and other personalized data. IT shops everywhere have at some point used a logon script along with the REG command or VBScript to customize application settings or environment variables in HKEY_CURRENT_USER.
Additionally, creating printer connections is a fairly obvious use for Windows logon scripts. Using a batch or even VBScript script, a smart IT pro could automatically connect a set of printers to every workstation. Doing this eliminates the need for users to know which printers are usable.
These three solutions have made good use of traditional logon scripts for their execution. Through some scripting slight-of-hand and a bit of testing, creating your own logon script to do the same has been a great way to take configuration control out of the hands of users.
While logon scripts in Windows are capable solutions, they have always had a dark side. First off, working with logon scripts requires scripting knowledge. Even more insidious, tiny syntax errors are infamous for spreading big problems all around a network. Moreover, logon scripts have limited functionality in environments where people don't logon all that often. Since they only execute as the user logs in, changes to a script could take days or more to distribute throughout a network. Finally, logon scripts are notoriously bad at targeting specific settings to specific users. For example, to create a printer for Finance users only, you would need to encode that logic yourself.
Group Policy preferences > logon scripts
Microsoft's Group Policy preferences (GPP) tool strikes a blow at the heart of the limitations associated with traditional Windows logon scripts. With very little effort today, you can create and implement a set of GPPs that connect drive letters, set environment and registry variables, and even attach the correct printer to the proper user.
Using Group Policy preferences to accomplish these tasks provides a much-improved interface to create configurations. Even better, GPPs can be discretely targeted to specific users and computers, ensuring desired preferences make their way to the right people. That targeting can be accomplished through simple organizational unit (OU) assignment, or you can get extremely detailed by limiting GPP processing to certain computers via item-level targeting. Item-level targeting is accomplished on a per-GPP basis, meaning Group Policy preferences can be created repeatedly in a single Group Policy, instructing each to specifically target only the user or computer that should process the preference.
Interested in getting rid of your logon scripts? Let's take a look through an example of printer configuration using a GPP. In this example, we'll assign a particular printer only to those users in the Finance group.
Start this process by creating a new Group Policy in the Group Policy Management Console and edit this policy in the Group Policy Management Editor (GPME). In this example, assign printer connections to different Active Directory security groups in the domain. The shares for these printer connections have already been created on the print server and published into Active Directory.
Navigate through the GPME to User Configuration | Preferences | Control Panel Settings | Printers. Right-click on Printers and choose New | Shared Printer. The New Shared Printer Properties console will appear, similar to Figure 1. Here, there are options to select the share path to the printer, as well as make the determination to map the printer to a local port.
Choose the ellipses (…) button to search for the correct printer in Active Directory. Figure 1 shows that the Brother MFC 8840Dp rinter attached to the \\TRICOSS print server has been selected.
There are four options available for how the GPP will manage the print connection:
- Create will create a new printer connection if one with the same name does not exist, but will not modify one that does.
- Replace will delete and recreate the printer connection, adding a new one if it does not exist.
- Update will modify the printer connection, updating the settings that are defined in the preference item. This is different than Replace, which fully deletes and recreates the item. Update will create a new printer connection if one does not exist.
- Delete removes the printer connection, doing nothing if one does not exist.
The update option is the easiest to begin with, as it updates any settings that are different as the policy is applied or refreshed without fully recreating the connection. Update also creates the printer connection when it is applied to computers where the connection does not exist.
Step two happens under the Common tab (see Figure 2), which displays five options. Four of these are useful for printer connections:
- First, select the box to Run in logged-on user's security context. This executes the printer connection within the context of the user, as opposed to the computer.
- Also check the box to Remove this item when it is no longer applied. This checkbox ensures that the printer connection will be automatically removed down the road when it is no longer relevant, and its preference needs to be removed. Checking this box will reset the preference to operate in Replace mode.
- Apply once and do not reapply is a setting that will instruct the preference to only apply once. If a user changes the printer connection at a later time, it will not be "fixed" by the GPP. Carefully consider your options before checking this box. For obvious reasons, this option cannot be set at the same time as Remove this item when it is no longer applied.
- Item-level targeting is the final step. By checking this box and clicking the Targeting button, you can identify a set of granular settings that will assign the preference to the right user or computer (see Figure 3). Here, a single security group item was created by clicking New Item | Security Group.
Considering that many IT shops can have dozens or hundreds of printers to configure across an even larger number of workstations, this process greatly simplifies the logon script creation of yesteryear. When building your own printer connections via Group Policy preferences, it is generally considered a good practice to place all of your printer connection GPPs within a single Group Policy Object and assign their targeting on a per-GPP basis through item-level targeting.
Printer connections are but one example of how Group Policy preferences are a perfect solution for getting rid of logon script woes. The next article in this series will highlight another use for GPPs as logon script replacements: customizing registry settings for user applications.
ABOUT THE AUTHOR
Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Greg's Jack-of-all-Trades tips and tricks at www.ConcentratedTech.com.