When I started my career in networking, NetWare 2.14 was the latest network OS and login scripts were all the rage. We used NetWare login scripts to map network drives, map network printers, set user home directories, and map search paths. It seemed that there was little that you couldn’t accomplish through a login script if you used a little imagination.
Today, NetWare is no longer the dominant network OS, and login scripts take a less important role as well. Although Windows 2000 and Windows .NET Server 2003 allow you to create some elaborate login scripts, the question remains, are login scripts obsolete? I’ll look at several reasons that this may be the case.
Two of a kind
Before you answer the question of whether login scripts are obsolete, don’t forget that there are two types of login scripts. Legacy login scripts are applied directly to a user object and group policy scripts are linked to a group policy.
Legacy login scripts
You may access a user’s login script by opening the Active Directory Users And Computers console, right-clicking on a user account, and selecting the Properties command from the resulting shortcut menu to access the user’s properties sheet. The login script option is located on the properties sheet’s Profile tab.
There are two main problems with legacy login scripts. First, there tends to be a lot of preparation time involved in setting them up. I mentioned that when I began my career in networking, I worked with Novell NetWare 2.14. This version of NetWare required login scripts to be applied directly to a user object, similar to the way that Windows 2000 legacy login scripts are applied to user objects. The big difference was that at that time, NetWare required you to either manually type in or cut and paste the script contents for each individual user. This was very time consuming because if you needed to set up 10 users, you’d have to create 10 scripts.
Rather than linking an actual script to each user account, Windows 2000 requires you to enter the path and filename of the script that you want to use for each user. This greatly simplifies the old NetWare arrangement because you can use a single script for multiple users. Even so, I still know a couple of people who write an individual script for each user.
Even if you did use a single login script for each user, though, you still face a lot of preparation time. Imagine that you have a login script already created and you need to set up 10 new user accounts. As you set up the new accounts, you must still take the time to visit the Profiles tab on each user’s properties sheet and supply the path and name of the script. This isn’t nearly as bad as filling in the actual script, but it can still be time consuming if you have a lot of users to set up.
The other big problem with legacy login scripts is that they can undermine security. Suppose you had configured Windows to run a group policy script any time a user logs in. Group policy scripts are designed to run before legacy login scripts. Therefore, if you’re using group policy login scripts and legacy login scripts, it’s very possible for a legacy login script to contain lines of code that undo actions performed by the group policy login script.
Group policy scripts
The advantage to applying a login script at the group policy level is that you can define the script in a single location and the script will automatically apply to any users that the group policy applies to. Group policy scripts can be applied either to a user or a computer, or both.
I believe that login scripts are outdated, and I don’t use them on my own network. However, if your own environment requires you to use login scripts, I strongly recommend using group policy scripts rather than legacy login scripts.
The biggest drawback to using group policy scripts is that you must apply them carefully because they’re hierarchical. It’s possible to have a group policy apply to a computer, a domain, a user, or an OU. It’s also possible for multiple policies to apply to a single user. When this happens, the user’s effective policy is a combination of the various group policies. This means that if you apply a login script to different group policy objects, it’s possible that a user account will run multiple login scripts or that one login script may cancel out another login script.
If you plan to use group policy scripts, I strongly recommend figuring out which scripts apply to each user and to each computer and then designing your group policy script implementation in a manner that won’t cause scripts to interfere with each other.
Now that I’ve warned you about the hierarchical nature of group policies, let’s look at where a login script would be defined within a group policy. Begin by entering the MMC command at the Run prompt to open an empty Microsoft Management Console. When the console opens, select the Add/Remove Snap-in command from the Console menu. You’ll see the Add/Remove Snap-in properties sheet. Click the Add button found on the Properties sheet’s Standalone tab. This will cause Windows to display a dialog box containing a list of MMC snap-ins. Select Group Policy from the list and click the Add button.
At this point, you’ll see the Select Group Policy Object dialog box. You must choose the group policy object that is appropriate for your situation. For demonstration purposes, I’ll be using the Default Domain Policy. This is the group policy object that controls security at the domain level. You may select a policy by clicking the Browse button and selecting the group policy from the list. Then you’ll click OK, Finish, Close, and OK.
Computer configuration settings
When you expand the Default Domain Policy object, you’ll notice that the policy is divided into two parts: User Configuration and Computer Configuration. I’ll begin by examining the Computer Configuration.
Begin by navigating through the group policy tree to Default Domain Policy | Computer Configuration | Windows Settings | Scripts. This location contains a Startup and a Shut Down script. The Startup script is similar to a login script except that it applies directly to the computer, not to the user account, and runs at boot up, not at login.
If you right-click on the Startup script and select the Properties command from the resulting shortcut menu, you’ll see a screen that asks you for the names of the scripts that you want to run at startup. You can supply multiple scripts and even control the order in which these scripts run.
Now, navigate through the Group Policy console to Default Domain Policy | Computer Configuration | Administrative Templates | System | Logon. This location is designed to control what happens when a user logs on to the system. Remember that this portion of the group policy still applies to the computer itself, not to the user. Options that you set here would apply to any user who logs onto a system that the policy applies to.
As you can see in Figure A, there are quite a few options that pertain to login scripts and startup scripts. My best advice about these group policy settings is to remember that they apply to the computer, not to the user. You should also read carefully. Login scripts aren’t the same as startup scripts, and it’s easy to accidentally set a policy for one or the other.
|There are several options that you can use to control the behavior of logon scripts and startup scripts at a computer level.|
The first option you’ll see is Run Login Scripts Synchronously. If you enable this option, all login scripts that apply to the computer will run to completion before the computer ever displays the desktop. There is a similar option under the User Configuration section of the group policy that I’ll show you later. The option in the Computer Configuration section overrides the option in the User Configuration section.
The next option is Run Startup Scripts Asynchronously. Notice that the option uses Startup scripts instead of login scripts and works asynchronously instead of synchronously. If you enable this option, a startup script doesn’t necessarily have to complete for a user to log in. I recommend leaving this option alone because an incorrect setting could render some of your computers unbootable.
The next two options refer to running startup and shut down scripts visibly. If you enable this option, it means that the scripts will run within a Command Prompt window when executing. The advantage of this is that it allows you to observe the script and verify that it is working correctly.
After you’ve confirmed that the script is correct, though, I recommend not running the script visibly. Running a script visibly allows your users to see the contents of the script and could reveal sensitive information about your network’s configuration, leading to a security breach.
The final option that I want to talk about in this section is the Maximum Wait Time For Group Policy Scripts. This is the amount of time that a script is left waiting before the system aborts the script and continues with the boot or login process. There is no default value for this script, but I recommend setting it to something sensible like five minutes or so. The idea is that if a script locks up, the system will eventually abort the script and continue with the boot or login process.
I’ve also seen situations in which a poorly written script required user input. The problem is that if the script is running invisibly, there is no way for the user to enter the required input. In such a case, having a maximum wait time set becomes critical.
User configuration options
Now that I’ve shown you the scripting options that apply to the computer configuration, I want to discuss the scripting options that apply to the user configuration. You can define group policy level login and logoff scripts in a manner very similar to that used for defining startup and shut down scripts.
Navigate through the console tree to Default Domain Policy | User Configuration | Windows Settings | Scripts. The Scripts container contains a logon and a logoff object that you can configure to point to any login or logoff scripts you may want to assign at the user level.
Like the Computer Configuration, the User Configuration section also contains options that you can configure to control the way that login and logoff scripts behave. Find these options by navigating to Default Domain Policy | User Configuration | Administrative Templates | System | Logon/Logoff. You can see the options offered in this section in Figure B.
|You can control login and logoff scripting options at the user level.|
As you can see in Figure B, this portion of the group policy contains a lot of handy options. About half of the options here relate to login scripts. Notice that there are options to run login and logoff scripts visibly. Keep in mind that if you set these options through the Computer Configuration section, they take precedence over settings in the User Configuration section. There is also an option in this section to run legacy login scripts hidden. If you’re still using legacy login scripts, I recommend enabling this option.
Also notice that this section has an option to run logon scripts synchronously. As I explained, this means that the login script must complete before the desktop will be displayed. Again, if you have configured this option in the Computer Configuration section, it will take precedence over the options found in the User Configuration section.
Are login scripts obsolete?
I said that I believe login scripts to be obsolete, and that I don’t use them on my personal network. After all of the cool group policy settings that I’ve shown you, you might be wondering why I feel this way. One of the biggest reasons is that most of the time, login scripts are just used as a mechanism for configuring the user’s environment.
For example, a login script can be used to map network drives or to attach a network printer. These types of actions can easily be defined in a profile, eliminating the need for a login script. Of course, if your users are allowed to make changes to their profiles, you might want to consider writing a login script anyway, just in case users make profile changes that damage environment settings.
The other frequent use of login scripts is to run programs. However, I’ve seen too many cases where people get carried away and write some massive script that runs at the system startup. Extra code increases the chances of a security problem or a compatibility problem.
Windows 2000 is very accepting of what it will allow you to pass off as a login script. Basically, anything that Windows can run, it can use as a login script. This includes batch files, EXE files, VBS files, and JS files. The problem is that while Windows 2000 can run VBS and JS files natively, Windows 95 and Windows NT can’t. If you have a VBS login script, the script won’t run on Windows 95 or Windows NT machines unless you somehow embed the script into a batch file.
When it comes right down to it, in a mixed environment, more often than not, login scripts aren’t the way to go. Mandatory profiles and group policies can do almost everything you used to do with login scripts. Even though you’re probably more familiar and comfortable with login scripts, you’ll gain more efficiency by leaving them behind.