Advanced Published or Assigned | Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)

When you attempt to Publish or Assign an application to your users or computers, you are given an additional selection of "Advanced". If you didn't choose "Advanced" when you initially deployed the application, that's not a problem. You can simply right-click the package, and choose Properties from the shortcut menu to open the Properties dialog box. The only option that is not available in this "after the fact" method is the ability to add Microsoft Transform Files , which I'll describe in the "Modifications Tab" section later in this chapter.

The Properties dialog box has six tabs: General, Deployment, Upgrades, Categories, Modifications, and Security. In Figure 10.10, the Properties dialog box is focused on the Deployment tab, which is discussed in detail, in this section.

Figure 10.10: These are the options on the Deployment tab when Assigning to computers.

The General Tab

This tab contains the basic information about the package: the name that is to be displayed in the Add or Remove Programs folder, the publisher, and some language and support information. All this is extrapolated from the .msi package.

If you're using the Windows 2003 administrative tools to deploy your package, you'll get another little goodie: you can specify the URL of a web page that contains support information for the application. For instance, if you have specific setup instructions for the user , you can place the instructions on a page on one of your intranet servers and include the URL with the package. The client's Add or Remove Programs folder displays a hyperlink to the URL next to the package. Although .zap files also display this information, you can't configure these files once they are Published.

The Deployment Tab

This tab, as shown in Figure 10.10, has three sections: Deployment Type, Deployment Options, and Installation User Interface Options. There is also an Advanced button at the bottom of the tab. Depending on how you wish to deploy, The options on the Deployment tab depend on how you want to deploy the application and whether you are Assigning to computer or Assigning or Publishing to users. In our first example, Figure 10.10 shows the options when Assigning to computers.

Figure 10.11 shows the options on the Deployment tab when Assigning an application to users. You'll notice that many more options are available than when Assigning to computers. The options in the "Installation user interface options" section are critical, and you will likely need to change them before applications are correctly Assigned or Published to users.

Figure 10.11: These are the options on the Deployment tab when Assigning or Publishing to users.

The Deployment Type Section

The options in this section let you instantly change the deployment type from Published to Assigned and vice versa, and it is available only when you are deploying applications to computers. When you are deploying applications to computers, Assigning is the only option. If you're deploying to user accounts, you can also change the deployment type by right-clicking the package definition (as seen in the Group Policy Object Editor dialog box in Figure 10.5) and selecting the deployment type, Assign or Publish, from the shortcut menu.

The Deployment Options Section

This section has four check boxes:

Auto-Install This Application by File Extension Activation When .msi applications are Published or Assigned (or .zap packages are Published), each of their definitions contains a list of supported file types. Those file types are actually loaded inside Active Directory.

When a GPO applies to a user or a computer and this check box is selected, the application is automatically installed based on the extension. This is, essentially , application execution via Document Invocation. Note, this option is always automatically selected (and cannot be un-selected) if you Assign the application. That is, document invocation is only optional when Publishing.

Document Invocation is most handy when new readers and file types are released, such as Adobe Acrobat Reader and its corresponding .pdf file type. Simply Assign or Publish an application with this check box enabled, and Acrobat Reader is automatically shot down to anyone who opens a .pdf file for the first time. This check box is selected by default when you are Assigning applications to users or computers.
Uninstall This Application When It Falls out of the Scope of Management GPOs can be applied to sites, domains, or OUs. If a user is moved out of the scope to which this GPO applies, what happens to the currently deployed software? For instance, if a user or computer is moved from one OU to another, what do you want to happen with this specific software package? If you don't want the software to remain on the workstation, click this check box. Rememberthe applications aren't removed immediately if a user or computer leaves the scope of the GPO. As you'll see shortly, computers receive a signal to remove the software. (This is described in the "Removing Applications" section later in this chapter.)
Do Not Display This Package in the Add/Remove Programs Control Panel As mentioned, icons and program names for Assigned applications appear in the Start ˜ All Programs menu, but, by default, they also appear as Published icons in the Add or Remove Programs applet in Control Panel. Thus, users may choose to install the application all at once or perform an en masse repair. However, the dark side of this check box is that users can remove any application they want. To prevent the application from appearing in the Add or Remove Programs folder, check this check box. When the application is then earmarked for being Published, the application is available only for loading through document invocation.
Install This Application at Logon This option is new and applies only to Windows XP and Windows 2003 Server clients . See the section "Assigning Applications to Users over Slow Links Using Windows XP and Windows 2003" later in this chapter for a detailed explanation.

The Installation User Interface Options Section

Believe it or not, the two little innocuous buttons in this section make a world of difference for many applications when Assigning or Publishing applications to users. Some .msi packages can recognize when Basic or Maximum is set and change their installation behavior accordingly . Others don't. Consult your .msi package documentation to see if the package uses this option and what it does.

For Office XP (and Office 2003), Assigning applications to users can be disastrous if you retain the default of Maximum. Instead of the application automatically and nearly silently loading from the source upon first use, the user is prompted to step through the Office XP installation wizard (the first screen of which is shown in Figure 10.12).

Figure 10.12: The default of "Maximum" results in many applications no longer being a silent install.

Simply choosing Basic remedies this problem. That is, Office XP is magically downloaded and installed for every user targeted in the OU. Why is this the default? I wish I knew. It wasn't the default in Windows 2000. For now, if you're Assigning applications to users, be sure the Basic check box is checked. For information about how to change the defaults, see the "Default Group Policy Software Installation Properties" section later in this chapter.

The Advanced Button

Clicking the Advanced button opens the Advanced Deployment Options dialog box, as shown in Figure 10.13. This dialog box has two sections: "Advanced deployment options" and "Advanced diagnostic information."

Figure 10.13: The options in the Advanced Deployment Options dialog box in Windows 2003 Server

The Advanced Deployment Options Section

In Windows 2003 Server, this section has three options, and in Windows 2000 Server, it has four options:

Ignore Language When Deploying This Package If the .msi package definition is coded to branch depending on the language, selecting this option can force one version of the language. Normally, if the language of the .msi package doesn't match the language of the operating system, Windows will not install it. The exceptions are if the application is in English, if the application is language neutral, or if this check box is checked. If there are multiple versions of the application in different languages, the MSI engine chooses the application with the best language match.

Remove Previous Installs of This Product for Users, If the Product Was Not Installed by Group Policy-Based Software Installation (older version of Windows 2000 only) If you use older Windows 2000 administrative tools to deploy your application, you'll see this option. However, in Figure 10.13, there is just an empty hole (where the mouse pointer is). For each .msi application, a unique product code (which is shown in Figure 10.13) is generated at initial compilation time. If your users somehow get their own copy of the .msi source and the product code matches the .msi application, they can forcibly uninstall their copy before loading the copy you specified.

This can come in handy if the folks in your organization run out to CompUSA and buy a version of a program you weren't ready to deploy using Group Policysay Office XP. If users acquire and install their own copy of Office XP before you're really ready to officially deploy it using Group Policy, you can forcibly remove the copy they install. Once you are ready to deploy Office XP using Group Policy, be sure to check this check box to remove all copies of Office XP that you did not deploy using Group Policy. The copy you're shooting down from on high will then be installed. In this way, you can ensure that all copies you deploy using Group Policy are consistent, even if your users try to sneak around the system.

This works because the unique product code you're sending via Group Policy matches the product code of the .msi package the user loaded on the machine. The Office XP you deploy is essentially the same as the Office XP they deploy. The product codes match, and the application you deliver "wins" if you select this check box.

Why is this option absent from the later versions of the Windows 2000 tools or the Windows 2003 Server version of the Adminpak tools? Because this feature is built in to the latest Windows 2000 Service Pack (SP4) and standard issue for Windows 2003 Server. This procedure is performed automatically and is no longer required as an option.

Warning

Even if you repackage your own applications (such as WinZip, Adobe Acro bat Reader 6, and so on) using a third-party tool (such as WinINSTALL LE), a product code is automatically generated at compile time. However, if you deploy those repackaged applications with Group Policy (in conjunction with this check box in Windows 2000), this procedure does not remove copies of applications that users installed with "Setup.exe" style programs. It removes only applications on the target machine that have a .msi product code.

Make This 32-Bit X86 Application Available to Win64 Machines Software distribution with Windows 2003 Server gets a little more complex because of the support for IA-64 computers. The IA-64 version of Windows XP supports 32-bit applications by running them in a special Win32-on-Win64 emulator. This is similar to the way NT and Windows 2000 support 16-bit Windows applications. In general, 32-bit applications should run fine on IA-64 platforms, but you can encounter an ill-behaved application that does not function correctly in the emulator. Additionally, Service Pack 1 for Windows 2003 Server and Windows XP Service Pack 2 make 32-bit applications run even more stably on IA-64 computers.
Include OLE class and product information This feature allows applications that contain COM services to be deployed such that COM clients can find their deployed applications. Basically, check with your application vendor to see if you need this switch; generally you don't. Enabling the switch increases the likelihood that the application will fail to deploy unless the application specifically requires this setting.

The Advanced Diagnostic Information Section

You can't modify anything in this section, but it does have some handy information.

Product Code As mentioned, if the unique product code of the application you are deploying matches an existing installed product, the application will be removed from the client. Some diagnostic information in the Event Log may refer only to Product Code (also known as Product ID).

Deployment Count A bit later in this chapter, you'll learn why you might need to redeploy an application to a population of users or computers. When you do, this count is increased. See the section "Using MSIEXEC to Patch a Distribution Point" a bit later in this chapter for more information.

Script Name Whenever an application is Published or Assigned, a pointer to the application, also known as a .aas file, is placed in the SYSVOL in the Policies container within the GPT (Group Policy Template). This entry shows the name of the .aas file, which can be useful information if you're chasing down a GPO replication problem between Domain Controllers.

The Upgrades Tab

You can deploy a package that upgrades an existing package. For instance, if you want to upgrade from Office XP to Office 2003, you can prepare the Office 2003 installation (as we did earlier with Office XP) and then specify that you want an upgrade, which can be either mandatory or optional.

Note	There is no Upgrades tab for .zap package definitions.

Moreover, you can "upgrade" to totally different programs. For instance, if your corporate application for ZIP files is WinZip but changes to UltraZip, follow these steps to upgrade:

Create the UltraZip .msi package, Assign or Publish the application, open the Properties dialog box, and click the Upgrades tab.
Click the Add button to open the Add Upgrade Package dialog box, as shown in Figure 10.14.

In the Package Upgrade section, select the package definition (in this case WINZIP 8.0).

Tip	Although you can click the Browse button to open the Browse dialog box and select another GPO for this to apply to, it's easier to keep the original package and upgrade in the same GPO scope.

Use the options at the bottom of the "Add Upgrade Package" window, to choose either to uninstall the application first or to plow on top of the current installation, and then click OK.
Back in the Upgrades tab, check the "Required Upgrade for Existing Packages" check box and click OK to force the upgrade.

Figure 10.14: Use the Upgrades tab to migrate from one application to another.

If the "Required Upgrade for Existing Packages" check box is cleared, users can optionally add the program using the Add or Remove Programs applet in Control Panel. This can cause grief for some applications, such as Office 97 and Office 2000 together on the same machine. Moreover, if the check box is not checked, the old application is started whenever an associated file extension (such as .doc ) is invoked.

Tip	When Assigning to computers, the "Required Upgrade for Existing Package" check box is always checked and not available for selection.

The Categories Tab

The Categories tab allows administrators to give headings to groups of software, which are then displayed in the Add or Remove Programs applet in Control Panel. Users can select the category of software they want to display and then select a program within the category to install. (See earlier Figure 10.8 above the mouse cursor, which shows the Category dropdown box.)

For example, you might want to create the category "Archive Programs" for WinZip and UltraZip and the category "Doc Readers" for Adobe Acrobat Reader and GhostScript. If you want, you can list a package in multiple categories. You can also create categories. For information on how to do so, see the "Default Group Policy Software Installation Properties" section later in this chapter.

The Modifications Tab

The Modifications tab is used to support MST files, or Microsoft Transform files, or just "Transform Files" for short. Transform files are applied upon current .msi packages either to filter the number of options available to the end user or to specify certain answers to questions usually brought up during the .msi package installation.

Each vendor's .mst transform-creation program is unique. Ask your application vendor if they have a transform-generation utility for your package. If not, you might have to step up to a third-party .msi/.mst tool, such as Wise Package Studio or AdminStudio by InstallShield. Some applications, such as Office 2000 and later, come with their own .mst generation tool.

In this screenshot, you can see I've loaded an MST file named NOMSACCESS.MST. This MST will prohibit the use of Microsoft Access 2003 from Office XP, but allow all other functions of Office XP to run.

The Modifications tab is only available for use when "Advanced Published or Assigned" is selected when a new package is deployed. If a package is already Published or Assigned, the Modifications tab is not usable. As you can see in the screenshot above, all of the buttons on the Modifications tab are grayed out. Again, this is because the MST file was loaded at package deployment time, and afterward there is no way to Add or Remove MST files after deployment. We'll reiterate and reexamine this issue a bit later.

Note	There is no Modifications tab for .zap package definitions because transform files apply only to .msi files.

You might be wondering how you can create your own MST files for Officeand that's what the next section is about. After you're done, you'll have the chance to load your MST file as well to test it out.

Using the Office .mst Generation Tool

You can deploy Office 2000, Office XP, and Office 2003, for instance, whole hog by using their included . msi package. Indeed, you saw this earlier. All versions of Office were available when our users chose to use Office. But what if we didn't want, say, Access available to our users? Or what if we want to adjust an Office property at a global level?

Using the Custom Installation Wizards from the Office Resource Kit, you can create a . mst transform file that can limit which options can be installed, as well as specify all sorts of custom options, including the default installation path , the organization name, the custom Outlook behavior, and more! The tool has the same name in all three versions of Office (but the application is unique to each). Table 10.1 shows you where to find the downloads.

Table 10.1: Location of Office Resource Kit downloads
Office Version	Where to Find the Resource Kit
Office 2000	www.microsoft.com/office/ork/2000/default.htm in the Toolbox folder
Office XP	www.microsoft.com/office/ork/xp/default.htm in the Toolbox folder
Office 2003	www.microsoft.com/office/ork/2003/default.htm in the Toolbox folder

The procedure to create an MST is straightforward, but quite long, and I simply don't have room available to dedicate to each and every step. In this example, I'll assume you're using the Office XP Custom Installation Wizard (CIW). Here is the basic overview:

Choose Start ˜ All Programs ˜ Microsoft Office Tools ˜ [ the version of the tool you loaded ] ˜ Custom Installation Wizard to start the CIW.
Tell the CIW where your administrative installation of that version of Office is. Remember, you created an administrative installation of Office XP in the section "Setting Up the .msi Package with an Administrative Installation" earlier in this chapter.
Give your .mst file a creative name, for example, nomsaccess.mst .
Continue to follow the wizard's instruction, choosing your specific installation options. In this example, on screen 7 (of 22), as shown in Figure 10.15, we'll tell Office XP that we don't want Access available to users.
At the final screen, click Finish and save the .mst file to a handy location.

Figure 10.15: Use the CIW to choose the options you want and create the .mst file.

As the CIW presents the final Wizard screen, it will give you information about how to run the .msi file along with the .mst file manually. But you can ignore this because you're about to use the .mst file in a Group Policy Software Installation GPO.

Applying Your .mst File to the Installation

As previously stated, you can add .mst files only when you're initially Assigning or Publishing a package. You previously performed these steps in the "Creating and Editing the GPO to Deploy Office" section at Figure 10.3. When you do, the "Select deployment method" dialog box will appear. Afterward, follow these steps:

In the "Select deployment method" dialog box, click "Advanced" to open the Properties dialog box.
Click the Modifications tab, and click Add to open the "Open" dialog box.
In the File name field, enter the full UNC path of the .mst file, for instance, \\WinDC01\apps\officexp\nomsaccess.mst .

Note
The .mst file needn't be in the same location as the .msi distribution, as long as the path is available via the UNC name.
Click OK.

Your screenshot should be similar to what is seen in the graphic at the beginning of the "The Modification Tab" section.

Once you press OK, the .mst file will be locked in and cannot be changed. You have only two options if you are unhappy with the .mst file:

Remove the package and deploy it again.
Create an upgrade package as described earlier.

Removing the entire Office suite and reinstalling it can be a pain for your users, so, if you want to deploy Office with (or without) .mst files, be sure to test in the lab before you really get started in your actual deployment.

What's with the Up and Down Buttons in the Modification tap?

If you wanted to, you could add multiple MST files before pressing the OK button to lock in your selection. But why would you do this?

Multiple, autonomous administrators can individually create .mst files and layer them such that each transform file contains some of the configuration options. These files are then ordered so that the options are applied from the top down. If configured options overlap, the last-configured option wins.

However, in my travels I really haven't seen administrators choose to add multiple MST files for the same MSI. Typically, only one MST file is used as we did in this previous example.

The Security Tab

Individual applications can be filtered based on user or security group membership. For instance, if you Assign Office XP to all members of the Human Resources Users OU, you set it up normally, as described earlier.

Warning

If a user who happens to administer the application in the GPO is not given Read access, they will no longer be able to administer the application. Therefore, don't use filtering based on user or security group membership on the administrators of the application.

If, however, you want to exclude a specific member, say, Frank Rizzo, you can deny Frank Rizzo's account permissions to "Read" the package. A better strategy is to create a security groupsay, DenyOfficeXPand put those people not allowed to receive the application inside that group. You can then set the permissions to "Deny" the entire security group the ability to read the package as shown in Figure 10.16.

Figure 10.16: Use the Security tab to specify who can and cannot run applications.