Targeting Phase

The main task of the targeting or scope-of-management phase is to determine the software needs of your users. During the preparation phase, you analyzed the groups to whom you need to deploy software. In the Distribution Phase, you established the software distribution points where the software is going to be located. (You need to know where the software files are located in order to complete the targeting phase.) In this phase, you do the following:

• Create and modify Group Policy objects in order to efficiently manage software for each individual and group.
• Create a pilot to test how you want to assign or publish software to users or computers.

Manage Your Software

By using the Software Installation snap-in, you can assign software to users or computers and publish software to users managed by a Group Policy object that is associated with an Active Directory container. Because one Group Policy object can manage many users or computers, you can use Group Policy and security descriptors to refine software management to a smaller subset of users or computers. Software management includes the following:

• Using the Group Policy snap-in to add or edit Group Policy objects.
• Assigning or publishing software for users and computers.
• Configuring software for management by associating transforms or customizations and creating upgrade relationships.

Add or Edit Group Policy Objects

As Figure 23.2 illustrates, in a Group Policy object, you can manage software for computers by selecting the Computer Configuration node or you can manage software for users by selecting the User Configuration node.

Enlarge figure

Figure 23.2 Software Installation User and Computer Configuration

Computer Configuration   Contains software settings that apply to the computer and therefore all users who log on to the computer.

User Configuration   Contains software settings that apply to users regardless of which computer they log on to.

The Software Installation snap-in that you use to assign and publish software is located in the computer and user configuration nodes, as illustrated in Figure 23.2.

Assign or Publish Software

Given that software can be either assigned or published and targeted to users or computers, you can establish a workable combination to meet your software management goals. Table 23.7 details the different approaches.

Table 23.7 Assigning or Publishing Software

Published Software

When you publish software for a user, there is no evidence of the software on the user's desktop. That is, published software does not appear to be installed on the user's computer. There is no Windows Installer advertisement information about the software on the computer either in the registry or as shortcuts on the desktop or the Start menu. The user can install the published software by using Add/Remove Programs in Control Panel.

When a users clicks Add/Remove Programs and selects Add New Programs, a list appears of all of the categories for the available software and, within their specific categories, the software that is published for them. Users can install only software that you have determined they need to perform their jobs.

If there is a large amount of software available, users can quickly locate the software that they need based on the categories that you have predefined. For example, a user might see software sorted by Administration, Everyone, Finance, Sales, and Shipping categories. If the user is a member of the sales team, he or she installs applications from the Everyone and Sales categories. The user would not be able to see or to install applications from the Administration, Finance, or Shipping categories because he or she is not a member of these organizational units. For information about creating categories, see "Categorizing Applications" later in this chapter.

Figure 23.3 shows the installation process for published applications.

Enlarge figure

Figure 23.3 Typical Installation of Published Applications

After the user installs a published application, it behaves like an assigned application until the user removes the application by using Add/Remove Programs or until you remove the application.

Assigned Software

You can assign software to either users or computers.

User assignment is most powerful for software that users require to perform their jobs. Software that is assigned to the user appears to be installed on any computer to which the user logs on. When called by WinLogon, the Application Management extension to Group Policy advertises the application in the local computer's registry and as an item on the Start menu or a shortcut on the desktop. The user installs the assigned application by selecting the application from the Start menu.

Figure 23.4 shows the installation process for user-assigned applications.

Enlarge figure

Figure 23.4 Typical Installation of User Assigned Software

You can also assign an application to a computer. In this case, the application is installed for all of the users who use the computer the next time that the computer restarts, which is the next time that the Group Policy for the computer is applied.

Note

If several users use one computer, and everyone who uses the computer uses a particular application, that application might be a candidate for assignment to the computer.

Assigned software is resilient. For example, if a user removes the application by using Add/Remove Programs, the advertisement information is reapplied to the user or to the computer, and therefore, it is reinstalled the next time it is selected or the computer is restarted.

Configure Software for Management

Windows 2000 software installation and maintenance's scope of management is defined by Group Policy, which uses Active Directory. A Group Policy object can contain several settings that affect how an application is installed, managed, and removed. By using the Software Installation snap-in, you can configure the deployment options for an individual package or for a group of software applications.

Individual Package Deployment Options

For each application, there are several settings that can be managed in any application's properties dialog box on the Deployment tab. Figure 23.5 shows the Deployment tab for Microsoft® Outlook® 2000.

Enlarge figure

Figure 23.5 Application Deployment Properties

Table 23.8 describes the options that are available on the Deployment tab of an application's properties dialog box.

Table 23.8 Application Deployment Properties

Auto-Installation

On the Deployment tab, as displayed in Figure 23.5, you can choose to Auto-install an application by file name extension activation. Without regard to whether an application is assigned or published, users can force an application to be installed by invoking a document or file that is associated with the application.

It is common for users to receive documents as attachments in e-mail messages without having the software associated with the attachment installed on their computer. When given the options, in most cases, users do not know which file type to choose in order to successfully open the attachment. With Windows 2000 software installation and maintenance, you can configure the appropriate software to install automatically.

Figure 23.6 shows the process of software being installed by document invocation.

Enlarge figure

Figure 23.6 Installing Software by Document Invocation

A user double-clicks an unknown document or attachment to open it

If there is an assigned application advertised on the user's computer, but the application has not yet been installed, Windows Installer installs the application and opens the document.

If there is no application for that document type either installed or advertised on the computer, Windows 2000 Professional looks in Active Directory for the published application that is associated with the attachment file name extension.

If the application is published, Windows Installer uses the advertisement script for the application in Active Directory to install the application and then opens the document for the user.

Important

If you have more then one application assigned for the same file name extension the last one installed on the local computer is the application that opens the file.

Prioritizing File Name Extensions

In the Group Policy object, you can select a file name extension and configure a priority for installing on -demand applications. An application is installed on demand when a user selects a file with a file name extension for a published application that is not already installed on the local computer. Configure the file name extension priority so that users who are managed by this Group Policy object always install the correct published application when the file name extension is selected. The first application that is listed in the Software Installation snap-in on the File Extension tab is the application installed in association with the extension.

To configure the file name extension priority

1. Open the Group Policy object in which you want this setting to apply.
2. Click the applicable User Configuration or Computer Configuration node. Click Software Settings, and then click Software Installation.
3. Right-click and select Properties
4. On the File Extension tab, in the select file extension drop-down list, select the file name extension.
5. In the Application precedence list, move the chosen application to the top of the list by using the up or down buttons, and then click OK.

Note

File name extension associations are managed on a per-Group Policy object basis. Changing the priority order in a Group Policy object affects only those users who have that Group Policy object applied to them.

Defining Settings for a Group of Applications

You can also use the Software Installation snap-in to determine the settings for a group of applications. To manage several applications at one time, use the General tab in the Software Installation Properties dialog box, shown in Figure 23.7. You can use this tab to globally define the default settings for the new packages within the Group Policy object.

Enlarge figure

Figure 23.7 Software Installation Properties Dialog Box

Table 23.9 describes the options available on the General tab of the Software Installation Properties dialog box. You can use the General tab to define the default software distribution point where packages are stored and to determine how you want to deploy the new packages.

Table 23.9 Software Installation Properties

The Advanced published or assigned option might be the most common selection because it allows you the most control over the package properties.

Note

It is recommended that you begin by deploying and testing one application at a time in a pilot environment.

Important

Use the Uninstall applications when they fall out of scope of management option carefully. If you assign an application to computers in a Group Policy object associated with an Active Directory site and select this option, a mobile user whose computer is managed by the Group Policy object might lose applications when the user moves to a new site. For example, if a user with Microsoft® Office assigned to his or her computer travels to another site for business and Office is not assigned to computers in the new site, the application is removed when the user starts his or her computer in the new site.

Categorizing Applications

You can organize assigned and published applications into logical categories to make it easier for users to locate the appropriate application in Add/Remove Programs.

Windows 2000 does not have predefined categories. In the Software Installation snap-in, you can create and modify categories. The categories that you establish are per domain, not per Group Policy object. You need to define them only once for the whole domain. To avoid conflicts, it is recommended that only one administrator create categories for the organization.

Note

When you are assigning or publishing software, and you associate an existing category with the Windows Installer package that is being either assigned or published, you are working on a per-Group Policy object basis.

If you have a large amount of software to manage, define categories so that it is easy for your users to recognize their applications. Create categories that reflect your organizational structure, as when users in a department use a common set of applications. For example, a category named Finance might have Microsoft® Excel and other accounting applications. You can also have categories that reflect job functions. For example, a category named Project Managers might include Microsoft® Project, Excel, and other project management applications. Or you might decide to classify all applications by the type of software. For example, a category named Presentation Tools might include Microsoft® Publisher, PowerPoint, and other graphics programs that supported by your organization. You can also define broad categories like line-of-business tools, site-licensed applications, and beta applications.

Modifications

You can determine some of the application properties, such as modifications, only when the software is first deployed, and you can change some of the properties, such as whether or not the software is visible in Add/Remove Programs, later by modifying the package properties.

For more information about updating software by using patches and upgrades, see "Updating Software by Using Patches and Upgrades" later in this chapter.

Targeting Software for Multilingual Users

Multinational corporations share information and collaborate on a worldwide basis. Up to this point, the operating system support and the files that you generated by using an application in one language were not necessarily compatible with a file that was created by using the same application in a different language.

Windows 2000 Server makes the process of deploying and supporting Windows 2000 across national and language boundaries easier and more flexible. The multilanguage version of Windows 2000 was designed with a single worldwide executable file that supports most European and East Asian languages, as well as languages such as Arabic and Hebrew, which are read right-to-left. Instead of deploying a different localized version of Windows for each language that your organization needs, you can deploy Windows 2000 with the MultiLanguage Pack to all international users. The worldwide executable file makes multilanguage setups much easier because there are few differences in setup routines, registry settings, and component configurations. The single worldwide executable file also streamlines the development and deployment of customized solutions.

Note

Windows 2000 supports many languages. Before managing software, verify that your applications run on an operating system that is running in a native language mode.

Software Installation and Maintenance and Multilanguage Issues

Although a Windows 2000 Professional–based computer has many different locale and language settings, for the purposes of software installation and maintenance, only the system locale matters. The system locale affects the code page that is installed, and code page availability, more than any other factor, affects how a language-specific or multilanguage application behaves. For additional information about locale and language settings, see the Locales and Language link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.

Applications typically support one language. This supported language, or the product language, is expressed in the Windows Installer package for the application.

To determine whether or not to install an application on a Windows 2000–based computer, software installation and maintenance checks to see the following:

1. If the ignore language parameter is set in the Software Installation snap-in for the managed package. If ignore language is set, the package is either advertised or installed without regard to whether or not the system locale and product language match.
2. If the system locale and the product language match. If they do, the package is either installed or advertised.
3. If the system locale is any value, and the product language is either neutral or English. If so, the package is either installed or advertised.

Important

Users roaming between computers with different locales might produce unexpected results.

Use caution when deploying two versions of an application with different product languages (for example, an English and a German version of the same application) in the same Group Policy object if the two applications have the same product code. If the two applications have the same product code, only one of them is installed for users or computers. If you need to make the same application available to users in multiple languages, the different language versions of the application have to have different product codes.

© 1985-2000 Microsoft Corporation. All rights reserved.