DESKTOP MANAGEMENT

A systematic approach to workstation configuration, deployment, and ongoing management is necessary to maintain an organized, controlled environment.

Standardize

It is best to configure all of your machines to have a common settings base. That is, while each machine will undoubtedly be unique in some ways, there should be certain files and configurations that you can rely on being present to more easily manage the machine later. These settings can include almost anything the administrator desires.

• Standard local administrative username and password (in non-domain environments especially) that do not change. It should be dedicated to system administration; users should NOT be allowed to use this account. Since the password will be the same on all your machines, users should NEVER be given the password since doing so would effectively give them access to all workstations in your environment.
• Standard set of utilities. For instance, certain resource kit utilities are very useful to include in your standard build. These are some good ones: ipseccmd.exe, linkd.exe, sleep.exe, soon.exe, windiff.exe (and supporting files), depends.exe (and supporting files), robocopy.exe. There are also some very handy free utilities on the web. Sysinternals offers quite a few. The pstools collection in particular is valuable for systems management.
• Standard options. For instance, you might decide to disable Simple File Sharing on all your computers so that you can connect to the workstations' administrative shares (C$, etc.). (Of course, if you do this, you probably also want to set up some sort of IPSec policy to allow connections only from your administrative workstations.) You may also want to customize the Default User profile so that all users receive a common profile to start with, disable the same unnecessary services on all the machines, etc. You must decide on the specifics; the idea is to be systematic in your implementation.

In order to accomplish this, you will need to have some standard practice for building machines. Many people in the Rutgers environment build Ghost "images" to achieve standardization. They create an image for each hardware platform they support and then deploy the same image to all the machines. The advantage to this approach is that you can quickly build a machine (or multiple machines simultaneously) with all your standard settings. The downside is that a separate image is needed for every machine type you support. If you don't have any hardware standards in your environment, you may need to maintain a lot of images, which use a lot of storage space and are somewhat time-consuming to update.

Another approach to the standardization problem is to use scripting. You can use an "answer file" to script the installation of Windows so that every machine you build starts with the same base. In fact, you can run "unattended" installations by automating the entire installation process. (See deploy.chm in the Deploy folder on the Windows XP CD ROM for detailed information.) The advantage to this approach is that you maintain a single build that works on multiple machine types. "Updating" the build usually entails modifying a script or two. The disadvantage, compared to the imaging process, is that it takes more time to build any single machine. However, this is usually offset by the fact that the process is fully or nearly-fully automated and does not require "babysitting," allowing you to work on other things while the machine builds itself.

To successfully standardize your environment, you will not be able to rely on the OEM-installed configurations that come with the computers you order. These configurations tend to have a lot of extra software that reduce performance and stability with little additional benefit. At the very least, you should modify these OEM configurations to more closely match your standard build. You might do that, for instance, by running a script that creates your standard administrative account (see myadmin.vbs for an example), installs the extra utilities you require, removes excess "autorun" software, and creates any of your non-default settings (autoupdate policies, standard profile, etc.). In most cases, however, you will benefit the most from rebuilding new PC's when they arrive. With a standard build mechanism in place, a little extra work now will save you lots of troubleshooting time in the future.

Build Recommendations

If you support more than a handful of machines, you will probably want to build your machines so that non-system administrators can not modify critical aspects of the configuration. This is especially true in lab environments. The only way to keep the machines stable is to prevent unauthorized changes from occurring. If you do not take steps to prevent ordinary users from randomly changing the configuration, you will likely find yourself in a reactive cycle of fixing problems rather than proactively designing better solutions.

The best option, assuming you have the cooperation of your department head, is to "lock down" the machines and withhold administrative access from the people who ordinarily use the machines. For those environments where it is politically troublesome to restrict users' rights, you can invoke the "best practices" explanation for why it is necessary: e.g., besides limiting "accidental" damage, computing in a restricted security context limits the damage that viruses and other malware can do. It also promotes a more stable and therefore reliable computing environment.

Some recommendations for achieving and maintaining lock-down:

• Use the NTFS filesystem. Besides being more stable than FAT32 on Windows XP, NTFS will give you the ability to set permissions on directories and files. Unless you wish to give everyone full control over every area of the filesystem, you will need to use NTFS and modify permissions appropriately. (See fixACLS.cmd for an example of how to automate permission-setting.) Some people fear that using NTFS will make data recovery more difficult in the case of hard drive failure. Given the wide array of tools and techniques that are now available (from Linux with NTFS support, to BartPE, to simply accessing the drive from another XP box), this is not an issue and should not deter you from leveraging the benefits of using NTFS.
• Put accounts in the Users group. There is no way to leverage NTFS permissions if the users are part of the Administrators group. To limit unwanted changes, ordinary users should be just that - "Users". Unfortunately, some applications assume the user has administrative rights and might therefore produce some error messages when run in a restricted context. However, using tools like Sysinternals' Filemon and Regmon, you can often pinpoint exactly which permissions need to be "loosened" without giving the users total control. While annoying and sometimes time consuming, these efforts will ultimately save you a lot of aggravation. If at all possible, also avoid putting accounts into the Power Users group. While doing so is often convenient technically and politically, Power User rights, though not quite "administrative," increase the number of things that can go wrong.
• Automate and/or centralize software installation and configuration changes wherever possible. A negative side effect of locking down your workstations is that your users become more dependent on you to maintain their computers. If they need to install a new program or modify the system in some way, you will probably need to do it for them. This, of course, requires more of your time and detracts from the purpose of locking down the machines in the first place. If you find that you must rely on the users to do some self-support, you may need to grant them elevated access rights. However, first consider approaching configuration changes from an "automation" point of view. That is, if you frequently need to implement the same kinds of changes, try automating the process in some way. For instance, learn a scripting language like VBScript, JScript, or even just NT-style shell scripting, or use an installer product like InstallShield or InnoSetup (free) to create a customized set of changes that work without user intervention. Then deliver those "packages" to the machines with a tool like ZENworks, SMS, the AT command line scheduler (at.exe), Task Scheduler (schtasks.exe), or WMI. (See Utilities page for more information.) The more you can automate, the less time you will have to spend visiting individual machines and performing repetitive tasks. You will also have the added benefit of consistency in your environment since tasks that are automated are always done the same way.

BACK TO TOP

© 2005 Rutgers, The State University of New Jersey. All rights reserved.