Software Installation and Maintenance

Pilot Program

Design a pilot program to test, troubleshoot, and prepare software for deployment. The pilot also establishes an ongoing system for testing and maintaining applications, including how to work with patches, software upgrades, and software removal, and the creation of a software lab where pilots and testing can be performed on an ongoing basis.

Software deployment affects both client and server performance. Within the pilot, consider strategies for optimizing software deployment on your network and on client computers. It is important that you clearly understand the current arrangement of servers and client computers throughout your network before you attempt to manage operating system updates and applications. For example, you need to consider the impact on the network performance of allowing software to be downloaded over slow network connections. You also need to carefully define who can install and update applications. These and other considerations greatly affect the number of support calls that you receive.

You can manage software evaluation or a pilot in the following ways:

Evaluate the software outside the corporate managed environment — for example, in a laboratory or test network environment.
Create a Group Policy object to manage the evaluation, and assign or publish the application to users or computers that are managed within that Group Policy object.
Modify the security descriptors on an existing Group Policy object or on the assigned or published package to control who can install the package for evaluation.
By assigning or publishing software to your testers, they can test all methods to verify that you have the results that you need for the group of users or computers to receive the application.

Note

In order to easily manage who has the application and not to affect actual users if a package is improperly deployed, assign or publish software to users grouped within a test Group Policy object, rather than try to manage the pilot by controlling security descriptors.

To ensure that potential application problems are resolved before you deploy new software or upgrades, it is best that the test manager begin early to develop a plan for testing and maintaining software. For more information about setting up a pilot and testing existing applications, see "Conducting Your Windows 2000 Pilot" and "Testing Applications for Compatibility with Windows 2000" in the Deployment Planning Guide.

Software Installation User Scenarios

It is recommended that each application be evaluated from the perspective of the users who require the application. The following are some questions to consider:

Does everyone in the company require access to the software? Or does only a select group of users need to use it?
How often does the software require updates?
Do you need to customize the software for some divisions in the company?
Is the software an in-house application or software that is provided by an independent software vendor?
How often do you need to update user templates or custom files that you want to manage by using the software?

The answers to these questions and other information about your users and your organization can help determine the best way to conduct your pilot and manage software. For example, if you have an in-house application that is updated monthly and that is required only by the finance division, and all of the users in this division are in the finance organizational unit, you might want to assign the application to the finance organizational unit and manage updates by packaging them as a separate Windows Installer package that you also manage by assigning within the same organizational unit.

Within the pilot, test all conceived manners of deploying software. If there are additional templates or files that you want to distribute with an application to only the Help desk personnel, place the templates and files in a separate Windows Installer package. Then assign or publish both the application and the templates package to the Help desk organizational unit. When there are new templates or files, or changes to these files, you can upgrade the existing templates package. You do not have to reinstall the entire application. During the initial deployment, if you add the templates to the application package, the entire application would need to be upgraded when a new template or file is required.

The following scenarios explore some of the additional issues that can arise when deploying software. They can help you when you are working on the various pilot tests that you need to establish, based on the users with whom you are working.

These scenarios highlight some best practice tips that Windows 2000 software installation and maintenance supports. Although it is hard to provide a single answer that is going to work for all organizations and all situations, these scenarios illustrate some of the more commonly encountered situations. They include recommendations on how best to use the software installation and maintenance feature for specific types of users.

Roaming User or Floating Worker

In many organizations, some users move or "float" from one location to another in the organization to perform their jobs. Some receptionists are roaming users. A key point about the roaming or floating worker is that although they log on to different computers to perform their jobs, these computers are usually connected by a high-speed connection or a LAN connection.

Note

By default, software installation and maintenance policy settings are not applied over a slow link. So roaming or floating users who connect to their organization's network by slow links might not see changes to their software. Group Policy can change this. For more information about slow links and Group Policy, see "Group Policy" in this book.

When working with roaming users, there are two ways to assign applications — to the users or to the computers. For example, if there is an application that all of the receptionists use, assigning that application to the computers so that it is already installed on the computers that the receptionists use might make the most sense. But, this might also be a scenario where you need to assign the software to these users. Then when a receptionist relieves another receptionist, he or she logs on to the computer and sees the applications assigned to him or her (because the application is advertised). The application is only installed for the user if they actually run the application.

In another example, if you have users who roam between two computers with different locales (languages), manage the software carefully or the users might not see the set of applications that they expect to see — for example, if one computer is running the U.S. English language version of Windows 2000 and one is running the German language version Windows 2000, some applications, whether they were assigned or published, might not work correctly in both languages. If you are supporting roaming users between languages, test the applications thoroughly to determine whether there are any problems.

You can use the Software Installation snap-in to manage software that is designed for single or multiple languages. You need to ensure that software is managed in the way that users expect to have it work on their computers.

Mobile Users

In many organizations, some users travel extensively to perform their jobs. For example, sales personnel often spend more time at customers' offices than their own offices. A key point about mobile workers or traveling professionals is that although these users log on to the same computer, their computers sometimes connect through a high-speed line and sometimes through a low-speed (or dial-up) line.

You might decide that it is best to publish software to these users, which ensures that any customization (transform) that applies to the software installs the software locally on the users' computers. This might be more effective than leaving the software or the feature to either install on first use or to run from a network location.

Additionally, you want to allow mobile workers to keep some software available on local media while they are traveling. For example, for mobile professionals that make a lot of presentations, bids, and quotes, it might make sense for you to allow them to have Office on a CD. Then if they need the source files to install or repair a feature, they can use the source media.

Note

If users are having trouble staying connected when they download software, verify that the connection speed and Group Policy settings are set appropriately. With Windows 2000, you can determine the connection speed that is considered to be a slow link.

Shared Computers

In many organizations, users share computers. This is quite common on the factory floor or in a business such as a bank, where tellers have the same job function but might work at a different counter (and therefore computer) on different shifts. In these environments, the software is often task-based, and although users change, the software does not (however, the software might track who is logged on). You might want to group these users or computers so that you can manage them from a single Group Policy object and then use Software Installation to assign software to the computers (either by the Computer Configuration or the User Configuration of the Group Policy object namespace). Thus, the software is going to be available for every user of that computer.

Be aware that software that is assigned to the computer is installed when the computer restarts. If computers restart between shifts, the time that it takes to install the software (the first time after the software is assigned to the computer or is upgraded) might affect the total startup time of the computer. Again, this increase in startup time occurs only if new software has been assigned or the existing software is upgraded. You can use this feature to manage the software and essentially reinstall the software environment every time the computer restarts.

Another place that computers are shared is a computer lab or classroom environment where users share computers typically for a short period of time (for example, while they are taking a class). This scenario differs from the previous shared computer scenario in that each user might either use the same software as the previous user (they are in the same class) or they might use different software. It is also likely that these computers do not move. Therefore, this might be a case in which using a site to manage software makes sense; although grouping the computers into a single organizational unit would also work. Choose the method that gives you the right level of control for applying Group Policy and software installation and maintenance. Depending on the requirements, you might still decide to assign software to the computer. This can work well if the software is written to keep user information (such as configuration information and saved files) separate from software information (such as executable files). Another way to manage this environment is to assign software to the user (each student has his or her own identifier and must log on) so that each user gets the software that they need for their training.

Group Policy can also limit the changes that users can make to the desktop and other settings on these computers so that you can tightly manage each computer.

Note

It is recommended that you consider using Remote OS Installation in these shared computer environments. Then, if you ever have to rebuild the lab, you can do so in a quick and efficient manner.

Staging Computers

You can use Windows 2000 Remote OS Installation to stage and standardize your computers by installing the operating system and any standard applications at the same time.

When you first acquire computers, a lot of time is spent preparing them for your users. Without regard to the source of the computers or how the original equipment manufacturer (OEM) has prepared them, most organizations format the hard disk drives of the new computers and then configure them according to their organization's standard configuration.

The best way to do this is to prepare a standard configuration on a typical computer, including the application software and then make an image on the remote operating system installation server. For example, if you want to bring in new computers and customize it to include Windows 2000 Professional, virus protection software, and Office 2000, use the following steps:

Setup and configure Remote OS Installation.
Use Group Policy to create the appropriate Group Policy objects to manage the computers in the organization.
Create a software distribution point for the virus protection software and Office 2000.
Create a transform to customize Office 2000 in the way that you want it configured.
Use the Software Installation snap-in to assign the virus protection software and Office 2000 to the computers in the appropriate Group Policy object.

Note

If you assign the software to the user, the computer-assigned version can be removed, and the user version advertised and then installed on first usage. Although the end result is that the user has the software, this process might take additional time.

Install Windows 2000 on the source computer (the computer does not have to have exactly the same hardware, but it must use the same Hardware Abstraction Layer [HAL] as the client computers on which the image is going to be installed), and configure the operating system in the way that you want it.
Add the computer to the Active Directory container where it is going to reside when it is deployed. This container has the Group Policy object with the virus protection software and Office 2000 assigned to the computer that is associated with it. (Care must be taken to configure this computer with software from the Group Policy object where the computer is going to reside; otherwise, the software might be removed and reinstalled if a different Group Policy is applied to the computer when it is deployed.)

Note

When you install Office 2000 as part of a Remote Installation Services (RIPREP) image, you must turn off 8.3 name creation. Change the value of the NtfsDisable8dot3NameCreation registry entry from 0 (default) to 1 in order to turn off 8.3 name creation. NtfsDisable8dot3NameCreation is in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

See the procedure "To turn off 8.3 name creation."

Start the computer, and software installation and maintenance installs the virus protection software and Office 2000 (software assigned to the computer installs when the computer starts).
After Windows 2000 Professional, the virus protection software, and Office 2000 have been installed, use the RIPrep tool of Remote OS Installation to build a Remote OS Installation image. Place this image on the RIS server.

To turn off 8.3 name creation

On the Start menu, click Run.
Type regedt32.exe or regedit.exe, and then click OK.
In the registry editor, navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Select the NtfsDisable8dot3NameCreation entry.
To turn off 8.3 name creation, change the value of the NtfsDisable8dot3NameCreation registry entry from 0 (default) to 1. In Regedit.exe right-click the entry, and then click Modify.
– Or –

In Regedt32.exe, click the entry, click Edit, and then click the appropriate menu choice.
Close the registry editor.

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

After this image is available, a user who receives a new computer that supports Remote OS Installation only has to connect the peripherals (keyboard, mouse, monitor), connect to the network, turn on the computer, and then proceed through the Client Installation wizard.

The computer finds the RIS server and then downloads the Windows 2000 operating system and the software. When the computer restarts after remotely installing Windows 2000, Software Installation detects that the virus protection software and Office 2000 are already on the computer and only updates the advertisement information, which takes a few seconds.

Note

When the user logs on to the computer and selects the first Office 2000 application, they see Windows Installer start because it needs to complete a small amount of user configuration. This occurs whether Office 2000 is assigned to the user, assigned to the computer, published, or installed by using Remote OS Installation.

Although some scenarios lend themselves to assigning the software to the computer, and others to assigning it to users, avoid assigning the same software to both users and computers. This applies to assigning the software within one Group Policy object or assigning the software to users in one Group Policy object and to computers in another Group Policy object if both Group Policy objects can be applied to a single user when Group Policy is applied.

For more information about installing Microsoft Office 2000, see the Microsoft Office Resource Kit link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.