Software Installation policy is designed to manage the complete life cycle of deployed applications. After you deploy applications using Software Installation policy, you might need to make changes to the deployment or even remove a deployment. By right-clicking on a deployed application within a GPO, you get a series of options for managing the application. For example, you can switch a user-deployed application from published to assigned simply by choosing the appropriate menu item. If you previously chose to autoinstall the application by file extension activation, you can disable this by clearing the Auto-Install option.
In the "Configuring Advanced and Global Software Installation Options" section, we discussed performing upgrades, customizing installation packages with transforms, and other routine maintenance tasks that can be performed using installation options. Additional tasks that you might also need to perform include:
Removing deployed applications
Redeploying applications
Configuring Software Restriction policy
Troubleshooting
You can use Software Installation policy to install applications and to uninstall previously deployed applications. You can manually trigger an uninstall by removing the software package that deployed the application in policy. An uninstall can also be triggered automatically. Automatic uninstalls occur if an application falls out of scope and you’ve configured Uninstall This Application When It Falls Out Of The Scope Of Management.
To trigger removal of a previously deployed application, follow these steps:
Access Software Installation under Computer ConfigurationSoftware SettingsSoftware Installation or User ConfigurationSoftware SettingsSoftware Installation as appropriate for the type of package you want to work with.
Right-click the related package, and select All Tasks, Remove.
In the Remove Software dialog box that appears, you have two removal options:
Immediately Uninstall The Software From Users And Computers. Immediately removes the application from all clients that are using it
Allow Users To Continue To Use The Software, But Prevent New Installations. Stops future deployments but allows the application to remain on systems where it has already been installed
Click OK.
Tip
When you remove an application, even though it is no longer visible within policy, the application itself still resides within the Group Policy Container (GPC) in Active Directory and the Group Policy Template (GPT) in SYSVOL until it’s manually removed. To indicate that the package has been removed, the msiScriptName attribute on the packageRegistration object within Active Directory takes the value R. For more information about the storage of policy settings, see Chapter 13.
As discussed previously in "Patching or Installing an Application Service Pack," the need to redeploy an application can arise for a number of reasons. If you patch an administrative installation of an application that was previously deployed, you can use the redeploy feature to have all targeted users or computers reinstall the application with the updated file. When you redeploy, the application is reinstalled wherever it was already installed, and on the next foreground processing cycle, all targeted users and computers perform a reinstall. What they actually do is call the Windows Installer engine to perform a repair using the options o, m, u, s, and v. These options provide the following behavior:
Reinstalls the application if a file is missing or an older version of the file is present.
Rewrites all computer-specific registry entries associated with the package.
Rewrites all user-specific registry entries associated with the package.
Overwrites all shortcuts associated with the package.
Runs the repair from the source Windows Installer package file and recaches the .msi file locally. (Windows Installer .msi files are always cached on the local computer during an installation—and stored in the %windir%installer folder.)
Note
When a package is redeployed, any user settings and data that were created since the application was first installed should be retained. However, this depends on how the application setup was written and where the settings and data were stored. For applications such as Office, user settings and data are retained through a redeployment.
After you deploy your software, you might want to ensure that only the correct software and software versions are executed on your user’s systems. You can use Software Restriction Policies for this purpose. These policies are found in the Computer Configuration area or User Configuration area within Windows SettingsSecurity SettingsSoftware Restrictions Policies.
Software Restriction Policies provide a powerful mechanism for blocking software execution. You can restrict known software types that cause problems on your network, such as games or peer-to-peer file sharing applications, as well as unknown types of software that can perform malicious activities.
Software Restriction Policies are configured on a per-GPO basis. Software Restriction Policies under Computer Configuration are used to set restrictions for all users of a computer. Software Restriction Policies under User Configuration are used to set restrictions for individual users or user groups.
When you access the Software Restriction Policies node under either configuration area for the first time within a GPO, you see a message stating that no software restriction policies have been defined. You begin the process of using Software Restriction Policies by right-clicking the Software Restriction Policies node and choosing Create New Policies. You then see a set of nodes in the results pane:
Enforcement policy. Determines how software restriction is applied to software files and to whom software restriction applies.
Designated File Types policy. Determines what file types and extensions are considered to be executable code.
Trusted Publishers policy. Sets trusted software publishers.
Security Levels node. Contains policies that specify whether and how restricted software runs.
Additional Rules node. Contains policies that control software execution. Rules can be established based on publisher certificates, the Internet zone from which the software is obtained, file path, and a secure hash of a file.
Together, these policies allow you to set global behaviors for software restriction as well as specific custom rules and behaviors for restricting or allowing specific software execution. Once you’ve used these settings to define the rules for your Software Restriction Policies, you can deploy them to your users and computers.
Whether you deploy Software Restriction Policies per computer or per user depends on whether you need to control software execution for all users on a computer or just particular users, regardless of where they are logged on. You can merge Software Restriction Policies from multiple GPOs if you need different levels of control based on the user or computer’s location in Active Directory.
Enforcement policy settings determine how software restriction is applied to software files and to whom software restriction applies. To view or set enforcement policy settings, follow these steps:
Access Software Restriction Policies under Computer ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies or User ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies as appropriate.
If software restriction has not been set up yet, right-click the Software Restriction Policies node and choose Create New Policies.
In the right pane, right-click Enforcement and select Properties.
You can apply software restriction policies to all types of executable code except DLLs or to all software (Figure 9-14). The default is to exclude DLLs, which is a safe place to start.
You can you control who will process the software restriction policies. By default, all users are subject to the policy, but to be safe you can choose to exclude members of the computer’s local Administrators group. This lets administrators undo any overly restrictive policies.
Click OK.
Designated File Types policy determines what file types and extensions are considered to be executable code. To view or set designated file types, follow these steps:
Access Software Restriction Policies under Computer ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies or User ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies as appropriate.
If software restriction has not been set up yet, right-click the Software Restriction Policies node and choose Create New Policies.
In the right pane, right-click Designated File Types and select Properties.
In the Designated File Types Properties dialog box (Figure 9-15), common extensions are listed by default, such as .exe, .bat, and .vbs.
You can add to the list if you have executable types that you want to include in the policy. Type the file extension of a file type that has already been registered on the system in the File Extension box and then click Add.
You can remove executable types from the list as well. Select the file type to remove, and then click Delete.
Click OK.
Using Trusted Publishers policy, you can allow software execution based on public-key signing of the executable code. You can specify whether regular users can add to the list of trusted publishers maintained on their computer or whether this action can be performed only by administrators. For example, when you download a file from Microsoft, you have the option at download time to add Microsoft to the list of publishers whose content you trust.
Using Trusted Publishers policy, you can prevent your users from ever adding a trusted publisher to their computer. This can be a good thing if you suspect your users are downloading software that, while signed by a legitimate publisher, is not appropriate for use on your computers. You can also use this policy to configure whether certificates that a publisher has used to sign their software are still valid. This is done by checking their certificate authority to see if the certificate has been revoked—either because the publisher or the certificate’s timestamp is no longer valid. This is a good idea, but it can result in latency for the user because Windows must contact the signing authority each time a certificate is used to ensure that it is still valid.
To view or configure trusted publisher options, follow these steps:
Access Software Restriction Policies under Computer ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies or User ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies as appropriate.
If software restriction has not been set up, right-click the Software Restriction Policies node and choose Create New Policies.
In the right pane, right-click Trusted Publishers and select Properties. The Trusted Publishers dialog box opens.
Specify who can select trusted publishers. The options are:
End Users. All users can select trusted publishers
Local Computer Administrator. Only local computer administrators can select trusted publishers (and any domain or enterprise administrators).
Enterprise Administrators. Only members of Domain Admins or Enterprise Admins can select trusted publishers.
Specify whether to check if a certificate has been revoked—either because the publisher revoked the certificate, the certificate’s timestamp is no longer valid, or both.
Click OK.
Security Levels policy specifies that restricted software is either disallowed or unrestricted. The Disallowed and Unrestricted modes are mutually exclusive.
By default, the Unrestricted mode is active. This means that any computer or user processing these Software Restriction Policies can run any code except those explicitly restricted by additional rules that you specify. When Disallowed mode is active, any computers or users processing these Software Restriction Policies cannot run any code except those explicitly allowed through additional rules.
Thus, your choice with Security Levels is to either lock down everything and allow for known exceptions or to allow everything and lock down code you know to be unsafe. The best choice depends on your security requirements, but using Disallowed as the default means a lot more work for your administrators to respond to user needs as new legitimate applications are required. However, if you have a tightly controlled and fairly static environment, it can be an excellent choice for preventing unknown, potentially malicious code from executing.
To set the security level, follow these steps:
Access Software Restriction Policies under Computer ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies or User ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies as appropriate.
If software restriction has not been set up yet, right-click the Software Restriction Policies node and choose Create New Policies.
Select the Security Levels node. The currently selected default is shown with a green circle and a check mark on its icon.
To set Disallowed as the default security level, right-click Disallowed and select Set As Default.
To set Unrestricted as the default security level, right-click Unrestricted and select Set As Default.
You can use Additional Rules policy to configure the actual rules that specify what software is restricted or allowed to run. If you right-click the Additional Rules node, you have four rule types to choose from:
Certificate Rules
Hash Rules
Internet Zone Rules
Path Rules
The sections that follow discuss how to use each rule in your Software Restriction Policies.
Certificate rules enable you to allow or disallow code execution based on who has digitally signed the code. For example, if our in-house development team signs all applications that are developed and deployed to our users, we can create a certificate rule to always allow these applications to run, as shown in Figure 9-16.
To create a certificate rule, follow these steps:
Access Software Restriction Policies under Computer ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies or User ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies as appropriate.
Right-click Additional Rules, and select New Certificate Rule.
In the New Certificate Rule dialog box, click Browse to browse to a certificate file on your local computer or network.
Use the Security Level list to specify whether applications signed by this certificate are unrestricted or disallowed.
Click OK.
File hashes are unique, nonreproducible values that are computed on a file based on its content. By creating a hash rule, you can restrict or allow execution of very specific file versions.
To create a hash rule, follow these steps:
Access Software Restriction Policies under Computer ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies or User ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies as appropriate.
Right-click Additional Rules, and select New Hash Rule.
In the New Hash Rule dialog box, click Browse to browse to the executable file you want to control and select it. As shown in Figure 9-17, the file hash is then automatically computed.
Use the Security Level list to specify whether applications signed by this certificate are unrestricted or disallowed.
Click OK.
Note
For Figure 9-17, we created a hash rule to prevent execution of Solitaire. Because the rule is based on the file hash rather than the name or other data that can be easily changed, the user can rename Sol.exe to anything else and it will still be restricted from running.
The Trusted Zones rule lets you control code execution based on where the code is running from. This rule augments the controls that Microsoft Internet Explorer provides, letting you control code that is installed by Windows Installer. That is, this rule applies only to applications that are installed via a Windows installer package from a particular location on the network. For example, if a user attempts to run an application installation using a Windows Installer package downloaded from the Internet, this rule can prevent that installation.
You can essentially use Internet Zone rules to control what software a user can install from where. Unfortunately, however, these rules do not affect software that is packaged using a format other than Windows Installer.
To create an Internet Zone rule, follow these steps:
Access Software Restriction Policies under Computer ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies or User ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies as appropriate.
Right-click Additional Rules and select New Internet Zone Rule.
Use the Internet Zone list to specify the zone you want to configure. The zones are:
Local Computer
Local Intranet
Restricted Sites
Trusted Sites
Internet
Use the Security Level list to specify whether applications from this zone are unrestricted or disallowed.
Click OK.
Path rules are probably the most flexible in terms of allowing or denying code execution. You simply enter a file system path—to a file or a folder—and any code that falls under the Designated File Types is controlled by the rule. Note that the path you enter is recursed. That is, if you type c:program files, all files and folders under this parent folder are controlled. Because of this, use caution when disallowing access to large folder hierarchies.
You can also create path rules to registry keys. This can be useful if you want to control what can run out of the various autostartup locations within the registry, such as the RunOnce key. The trickiest part of a registry path configuration is that you can’t browse to registry paths from the Path Rule dialog box. Instead, you must manually type the path to the registry key or copy/paste it from the Registry Editor to the Path box. You must also enclose the registry path in % symbols, as shown here:
%HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce%By restricting common registry paths that perform autostartup tasks, you can control malicious code that tries to install itself in the user’s workstation.
To create a Path rule, follow these steps:
Access Software Restriction Policies under Computer ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies or User ConfigurationWindows SettingsSecurity SettingsSoftware Restrictions Policies as appropriate.
Right-click Additional Rules, and select New Path Rule.
Type the path you want to use. You can click Browse to browse to the file or folder you want to control and select it. With registry paths, you must type the path or copy/paste it from the Registry Editor to the Path box.
Use the Security Level list to specify whether applications from this zone are unrestricted or disallowed.
Click OK.
Many tools and techniques are available for ensuring that Software Installation policy functions properly. The main tools are the various log files that you can enable to gain insight into what is or isn’t happening during Software Installation policy processing. The primary log files for troubleshooting include:
Application event log. The Application event log on the target computer generates messages related to general Group Policy processing as well as Software Installation–specific messages. Software Installation messages have an event source of Application Management or AppMgmt. Windows Installer–related messages have an event source of MsiInstaller. These messages tell you whether an application installation was successful, and if not, it will often provide some basic explanation.
%windir%debugusermodeuserenv.log. Provides insight into problems with Group Policy core processing and specifically high-level error codes for Software Installation processing. It can also point to why a GPO wasn’t processed during a given cycle.
%windir%DebugUserModeappmgmt.log. Provides detailed logging of the Software Installation processing steps, including which GPOs are being processed for Software Installation policy and what applications are being installed.
%temp%msi*.log. The Windows Installer engine can create detailed logs that enumerate every step of the package installation. This log file is useful for troubleshooting problems with the package when you know that Software Installation policy is functioning properly but the application is failing on installation. For per-computer deployments, these log files are created with a unique name, beginning with msi*.log, within the %windir% emp folder. For per-user installations, the log files are created within the user’s %temp% folder.
These log files are stored on the client computers that are processing Software Installation policy, not on the domain controller. To learn how to enable and use these log files, see Chapter 16.
In addition to log files, you can use the Group Policy Management Console’s Group Policy Results Wizard to remotely collect Software Installation policy information on a particular computer and verify that the application was installed as expected. Figure 9-18 shows an example of a settings report generated by the wizard. The wizard also shows a filtered view of the application event log on the client computer—showing only Group Policy–related events from the Policy Events tab.
The first thing you can do to ensure that you understand what’s happening during Software Installation policy processing is to enable verbose Group Policy status messages. You can do this easily by enabling Verbose Vs. Normal Status Messages under Computer ConfigurationAdministrative TemplatesSystem.
Enabling this policy gives you visual clues about what’s happening during foreground Group Policy processing, including when managed applications are being installed and what application installation is currently running.
Using the tools and logs described above, the following general approach to troubleshooting Software Installation processing works well:
If an application fails to install correctly for the target user or computer, use the GPMC Group Policy Results Wizard to ensure that the user or computer is actually processing the GPO containing the application package. If not, see Chapter 17 for possible solutions.
If you’ve confirmed that the GPO is being processed but the application is not being installed, the next step is to enable logging to determine where the failure is occurring. Start by enabling the Appmgmt.log file to determine whether the application installation is being attempted and, if so, whether any errors have occurred. This file generally shows error codes related to the installation or provides a reason why the installation can’t be completed.
If Appmgmt.log indicates that the installation is being attempted but is failing, the next step is to enable verbose Windows Installer logging. The log file generated during a Windows Installer installation steps through each action the package takes and can provide insight into where the failure is occurring and why.
A number of issues that arise during Software Installation policy processing can be resolved relatively easily. The most common of these issues are explained here:
It takes two or three reboots or user logons to trigger a installation via policy. If your clients are running Windows XP, they probably have Fast Logon Optimization enabled. This causes some Group Policy processing, such as Software Installation policy, to require multiple restarts for logon. You can disable this feature by enabling Always Wait For The Network At Computer Startup And Logon under Computer ConfigurationAdministrative TemplatesSystemLogon.
Software Installation policy is not being processed even though other policy is being processed correctly. As mentioned earlier, Software Installation policy is not processed by default if a slow link is detected between the computer and the domain controller. To verify whether a slow link was detected, run the GPMC’s Group Policy Results Wizard against the client. This will tell you whether a slow link was detected at the last foreground policy processing cycle.
Users or computers are unable to run an application setup, and the error is "Access Denied.". To run the setup, the user or computer must have Read permission to the share and the files where the Windows Installer package resides. Make sure the users or computers that will process the policy have sufficient permissions to access the packages.
Software Installation policy uninstalls a version of the software that already exists on your computers before installing the managed copy. This happens by design. If Software Installation policy finds an application that was installed manually outside of the Software Installation policy process and that application has the same Windows Installer product code as the managed application that is to be installed, the unmanaged application is automatically uninstalled first. This ensures that only managed applications are installed on your systems.
An administrator manually uninstalled an application that was previously deployed via Software Installation policy. When that computer processes the policy again, the application is not reinstalled. Managed applications deployed via Software Installation policy should never be manually uninstalled. Even though the application is gone, registry-based information is left behind that causes Software Installation policy to think the application is already installed. If needed, you can manually delete this information to force a reinstall. From the Registry Editor, open HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrent-VersionGroup PolicyAppMgmt (or HKEY_LOCAL_MACHINE if the application was deployed per computer). Each managed application has a subkey under this key that contains information about the deployment. Locate the subkey that lists the uninstalled application, and delete that subkey.