Decreasing Users' Downtime

By Brien M. Posey, MCSE

Published in TechRepublic's Windows Support Professional (TechRepublic.com)

If you're responsible for technical support on a network of any size at all, you've probably discovered that you must make the most efficient use of your time to keep from being completely overwhelmed. One way to accomplish this is to become proactive. Murphy's Law dictates that each computer on your network will fail at some point. So, you should make your workstations as easy to fix as possible to minimize downtime when problems occur.

If you can minimize users' downtime, you'll receive less hate mail from them and free valuable time for more important tasks. In this article, we'll discuss some techniques you can use to minimize the length of time a workstation stays down after a serious crash.

The general idea

The easiest way to ensure that you can quickly recover from a crash is to simplify the contents of the PC. In a nutshell, each PC's configuration should be as generic as possible. All profiles, logon scripts, user files, and accounts should be stored on the server.

If you organize your network in this manner and a workstation crashes, you can simply reload Windows NT from the server. You won't have to worry about spending valuable time performing the complicated recovery techniques needed to salvage a special configuration or a user's files. Even better, because each workstation has a generic configuration, a user whose PC has crashed can easily work on another PC while waiting for his or her computer to be fixed.

In an ideal situation, you could simplify things even more by providing all users with identical hardware. By doing so, you could keep a minimal set of drivers on hand and quickly reload a PC without having to wonder what type of video card or network card was in that particular machine. Unfortunately, as nice as this approach may sound, it doesn't work in the long run. If you upgrade one PC, you must upgrade them all to maintain identical hardware. From a cost and labor standpoint, doing so is impractical. You might think you could replace every PC every three years to make sure everyone kept identical hardware. But, a year after you replaced all the PCs, your company might hire new people—and PCs identical to those currently in use might not be available for purchase. For these reasons, don't worry about identical hardware. Instead, concentrate on factors that you can control.

Moving files to the server

The first step in making everyone's configuration more generic is to move all user files off the workstation and onto the server. While it may not sound wise to put all your eggs in one basket, keep in mind that your server is probably backed up nightly. Workstations are seldom—if ever—backed up.

Start with a very large volume that you'll use only for user files. Take care to construct this volume in such a way that you'll be able to increase its size if necessary. For example, you can add extra hard drives to many hardware-implemented RAID devices to increase the size of the partition without having to rebuild it. Be sure to format this partition as NTFS.

Granting access to files

Once you have a sufficiently large NTFS partition, you'll need to create a directory that each user can use to store his or her files. We recommend creating a directory called Users and placing subdirectories beneath it, as shown in Figure A. You don't want to bog down your server (or your administrative staff) with the task of managing a large number of shares. Instead, create one share at the Users level and grant everyone full control of it. You can then create subdirectories that match each user's logon name and assign these subdirectories NTFS permissions.

Figure A: You should build a directory structure similar to this.

User profiles

After you've moved everyone's files to a server, it's time to configure profiles. As you may already know, when someone logs on to a Windows NT workstation for the first time, NT creates a profile for that user. NT creates this profile in the \Winroot\Profiles directory, where Winroot is the location of the NT system files. Beneath the \Profiles directory is a separate directory for each user. As you can see in Figure B, each subdirectory contains additional files and subdirectories designed to store that user's personal settings.

Figure B: Windows NT creates a personalized profile directory for each local user.

Local profile directories work great as long as users never change PCs, and as long as a PC's hard disk never crashes. However, a profile won't follow a user who changes computers because each profile is stored locally. Since our goal is to make each PC's configuration as generic as possible, the profiles should be stored in a central location that's accessible from any PC. Doing so requires some work up front, but it's worth the effort in the long run.

To create a centralized location for user profiles, select a volume on one of your servers and create a directory called Profiles. Next, share this directory and give the group full control. Beneath the Profiles directory, create directories matching each logon name, as shown in Figure C. When you've created these directories, assign the Full Control permission to the owner of the profile and to the Administrator, as shown in Figure D.

Figure C: Create a profile directory for each user.

Figure D: Assign the Full Control permission to each profile's owner and to the Administrator.

Now that you've created the profile directories, you must tell NT to use them. Begin by opening User Manager for Domains. Next, double-click the user account whose profile you want to modify. When you do, the User Properties sheet will open. At this point, click Profile to open the User Environment Profile dialog box, shown in Figure E.

Figure E: The User Environment Profile dialog box contains the settings necessary to make the user account look to the server for profile information.

Now you must enter the location of each user's profile directory in the User Profile Path text box. To do so, enter

\\servername\PROFILES\directory

where servername is the name of the server containing the profiles, PROFILES is the share name assigned to the Profiles directory, and directory is the individual user's profile directory. Figure F shows an example.

Figure F: Enter the location of the user's profile directory.

As you probably noticed in Figure E, the User Environment Profile dialog box contains several other text boxes for customizing the user's account. Next, you'll want to enter the information for the user's home directory. (The home directory is the directory you created for the user to save all his or her files in.)

To establish the home directory, select a drive letter that no one presently uses—many network administrators use Z or X for this purpose. All users will use this drive letter to access their respective home directories. Next, click Connect and choose your drive letter from the dropdown list. Enter the location of the home directory in the To text box. Enter the path in the format

\\server\USERS\%USERNAME%

as shown in Figure G. Here, server is the name of the server containing the Users directory, USERS is the name of the share assigned to the Users directory, and %USERNAME% is a literal value.

Figure G: Enter a drive letter to connect to the home directory.

Why %USERNAME%?

You may wonder why you enter %USERNAME% instead of the name of the actual directory. Keep in mind that the name of each user's home directory is identical to his or her username. If you click OK and then click Profiles again, you'll see that NT has changed %USERNAME% to the actual username. You set up the location in this way because many administrators use a template account to create other accounts.

By using a variable in your template account, you ensure that all accounts created from the template will also contain a variable, so you won't have to manually set a home directory for each new user. When you create new accounts based on this template account, NT will automatically create a home directory at the location specified by the variable and assign the new user rights to it.

Logon scripts

The last thing you can control from the User Environment Profile dialog box is the name of the logon script. A logon script is a program that executes each time the user logs on. Naturally, if you use logon scripts, you'll want to store them in a central place, as well. Although you can set up logon scripts in many different ways, some ways are much better than others—especially in multiserver environments, where a number of domain controllers could potentially validate a logon. We'll discuss logon scripts and their stipulations in detail next month.

Conclusion

In this article, we've explained how you can minimize downtime by providing each PC with a generic configuration. We also showed you how to move critical configuration information off the workstation and onto the server.

Brien M. Posey is an MCSE and a freelance technical writer. He also works as a network engineer for the Department of Defense. You can contact him via E-mail at Brien_Posey@xpressions.com. (Because of the large volume of E-mail that he receives, it's impossible for him to respond to every message. However, he does read them all.)

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.