MCITP Self-Paced Training: Troubleshooting Software Issues in Windows 7

Lesson 1: Understanding and Resolving Installation Failures

To troubleshoot installation failures, you need to understand the requirements of a successful installation. These requirements include—among other factors—administrator privileges, compatibility with Windows 7, availability of installation code and data, and the status of application dependencies. You also need to understand how administrative features such as Software Restriction Policies (SRP) and AppLocker can block an installation even when these requirements are met. This lesson provides an overview of issues such as these that are related both to successful and unsuccessful installations.

Verifying Software Installation Requirements

You can install new software on clients running Windows 7 in two general ways. First, you can push applications to clients by means of a software deployment technology such as Group Policy, Microsoft System Center Configuration Manager, or a third-party solution. The second option is to install a program manually.

Although some of the requirements for successful software installation are particular to the way in which the software is deployed, most requirements apply to all software installation methods. To begin troubleshooting a failed installation, therefore, you can verify the general requirements described in the following section.

Verifying Administrator Rights

One of the most basic requirements for a successful software installation is that the user account running the installer program needs local administrator privileges, and to have these local administrator privileges on a particular computer, the account needs to be a member of the Administrators group on that computer.

If you are not able to get past the User Account Control prompt when you attempt to install a program, therefore, you should verify that the account used for installation is granted local administrator privileges on the computer in question. Typically, having domain administrator privileges is sufficient because by default, domain administrators are members of the local Administrators group on every computer that is a member of the same domain. However, you should perform this verification even if you are already a domain administrator because the Domain Admins group might have been removed from the local Administrators group.

To determine whether you are a member of the local Administrators group on a particular computer, you can use the Local Users And Groups console. To open this console in Windows 7, you can click Start, type edit local users and groups, and then press Enter. (Note that you can perform this step even if you are not already a local administrator.) Then, in the console tree of the Local Users And Groups console, select Groups, and then double-click the Administrators group in the details pane. This procedure opens the Administrators Properties dialog box, which is shown in Figure 9-1. This dialog box lists all the local administrators for that machine.

If you are a local administrator, you can then use the Add button in the Administrators Properties dialog box to add other local administrators if desired. Note, however, that in an enterprise network, it is preferable to control local group membership by using the Restricted Groups feature in Group Policy.

Running an Installation Program as an Administrator

If you can verify that you are a local administrator but you still see a message indicating that administrator rights are required to perform the installation, you should choose the option to run the installer program as an administrator. To do this, right-click the installation icon for the program, and then click Run As Administrator, as shown in Figure 9-2. If a User Account Control consent or credential prompt appears, provide confirmation or administrator credentials as needed.

Verifying Windows 7 Compatibility

If an application is known to be incompatible with Windows 7, you might receive a message informing you of this fact when you attempt to install the program. If no updated version of the software is available, you can try altering the compatibility settings on the installer program or hosting the application in a virtual environment. Handling software compatibility issues such as these is discussed in detail in Lesson 2 of this chapter, Lesson 2: Resolving Software Configuration and Compatibility Issues.

Verifying Trusted Publishers

When you install a new program, Windows 7 checks for a certificate and a digital signature to authenticate the publisher of the program. To verify this digital signature properly, the local computer must trust the root certification authority (CA) for the publisher certificate. Stated another way, the local computer must have installed in its Trusted Root Certification Authorities certificate store the root certificate in the certificate chain of the publisher certificate. An administrator can install this root certificate manually on a local computer or the certificate can be deployed to the Trusted Root Certification Authority certificate store on many clients through Group Policy.

If the certificate in the installer program is from a trusted publisher and the digital signature is verified, the installation proceeds normally. However, if no digital signature is present, or if the local computer is not configured to trust the publisher, you will see a warning message similar to the one shown in Figure 9-3.

In general, you should avoid installing programs from unsigned publishers in an enterprise environment. Such programs might fail during installation, and even if they do install successfully, they could present stability problems or introduce malware into your network.

Verifying Software Logo Testing on a Client Running Windows 7

Occasionally, when you attempt to install an application, you will receive a warning that the application has not passed Windows 7 logo testing. In this case, you should avoid installing the software.

For an application to pass Windows 7 logo testing, it must meet a number of requirements, including compliance with specific anti-spyware guidelines, isolation from protected resources in Windows, a reversible installation, and a digital signature on all files.

Verifying the Installation Media Location

Before you attempt to install an application, ensure that all the files needed for installation are available in the required locations. For example, if you have copied an installer program from a network source to a local computer, be sure that you also copy all the associated secondary files that are called by the installer program when it runs. (These secondary files can include .cab files or .ini files.) If you are installing an application from over the network, verify that any secondary files are also accessible from the local computer and that you have Read and Execute permissions on these files.

Verifying Installation Settings

When you attempt to install an application, ensure that the settings that you have chosen for the installation are configured properly; otherwise, the installation might fail. For example, if you choose to install a program on a read-only disk, the installation fails.

Verifying External Connections

Certain applications require connectivity to external sources of data. For example, the application might require a connection to a database, mainframe, Web site, license server, or other application server. In this case, verify that the installation program can reach these external connections.

Verifying Licensing and Other Application Constraints

An application might include constraints that will prevent it from installing successfully. For example, a license or product key might be required to install the application, or the application might need to be installed with a specific user account. Verify also that the application architecture is compatible with the local processor. For example, you cannot install a 64-bit application on a computer with a 32-bit CPU.

Verifying Application Dependencies

Some applications can be installed only after you first install other updates, features, service packs, or other applications. Be sure to prepare the client running Windows 7 for application installation by first installing all the necessary software dependencies.

Understanding Installation Restrictions with AppLocker

Occasionally, when you are attempting to install an application, you might receive an error such as the one shown in Figures 9-4 or 9-5.

If you see such a message, the AppLocker or SRP feature has been used to prevent the application from being installed. Both technologies are available in Windows 7 and Windows Server 2008 R2. AppLocker is essentially a new and improved version of SRP, but SRP is still included in these newer operating systems for compatibility with networks running older versions of Windows.

As with SRP, you configure AppLocker through Group Policy. To locate AppLocker, open a Group Policy Object (GPO) and navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Application Control Policies\AppLocker, as shown in Figure 9-6. (In Local Security Policy, the path is simply Security Settings\Application Control Policies.)

You can see that the container for AppLocker (Application Control Policies) is found immediately below SRP.

The next section introduces AppLocker and describes the differences between it and SRP.

Overview of AppLocker

AppLocker is a new feature in Windows 7 and Windows Server 2008 R2. It allows administrators to restrict the programs that users can run or install in your organization.

AppLocker resembles SRP in a number of ways. First, you configure both AppLocker and SRP in a GPO. Also like SRP, AppLocker allows you to create rules specifying an application to which you want to allow or deny access. Finally, as in SRP, in AppLocker you can define a program by specifying—among other methods—a hash of or a path to its file.

AppLocker, however, provides the following important improvements over SRP:

• Publisher rule condition

  In AppLocker, you can specify a program by extracting information from its digital signature, as shown in Figure 9-7. You can then use part of or all of this publisher information to define the programs you want to allow or deny. This publisher condition essentially replaces Certificate Rules in SRP.

  

  Figure 9-7 With AppLocker, you can specify an application by digital signature.

  Using publisher information from a digital signature is by far the best way to specify an application in AppLocker. First, you can use this publisher information to create rules at various levels of specificity: You can make the rule apply to the publisher in general, to any version of the particular application, or to specific versions of the application (including all previous or future versions). Second, the publisher condition solves a key problem with SRP: In SRP, there is no comparable way to restrict access to an application through multiple updates. If you specify a path to an application that you want to restrict, users can simply move the program to a new path to avoid the restriction. If you specify a hash for the application, you have to create a new rule every time the application is updated.

• AppLocker blocks all programs that are not specifically allowed

  In SRP, rules by default are used to block access to chosen applications. However, within any company network, the number of applications that you want to block typically far exceeds the number that you want to allow. AppLocker accounts for this disparity by locking all applications that are not allowed. More specifically, AppLocker rules are enabled for one of four file type (executables, Windows Installer programs, scripts, or DLL files) when you first create a rule for that file type. Then, when AppLocker is enabled, all applications of that file type are locked if they are not allowed by a rule. To prevent system lockouts, AppLocker provides the Create Default Rules and Automatically Create Rules options. These options create allow-type rules for most applications. You can then create additional rules to change this default configuration.

• Assign Rules to Specific Users and Groups

  In AppLocker, you can create rules that apply to everyone or only to specific users and groups. In SRP, you can create only rules that apply to everyone.

• Exceptions

  AppLocker enables you to create a rule with an exception. For example, you can create a rule that allows any application to run except a specific .exe file. This feature is not available in SRP.

• Audit-only mode

  Unlike SRP, AppLocker includes an audit-only mode. Through auditing, you can test your configuration without enforcing AppLocker rules. When you configure AppLocker to audit AppLocker rules for a chosen file type (such Windows Installer programs), events are written to the event log when AppLocker would normally block access to that application.

  Audit mode is configured in the properties of the AppLocker node in a GPO, as shown in Figure 9-8. Audit events as they appear in Event Viewer are shown in Figure 9-9.

• Import and export rules

  In AppLocker, you can export and import rules to and from other computers, which allows administrators to copy and edit rules easily.

  

  Figure 9-8 Configuring AppLocker rules for audit only

  

  Figure 9-9 Audit-only events for AppLocker

AppLocker Availability and Compatibility

AppLocker rules are enforced on computers running only Windows Server 2008 R2, Windows 7 Ultimate, and Windows 7 Enterprise. AppLocker rules are not enforced on computers running other versions of Windows, such as Windows Server 2008, Windows 7 Professional, or Windows Vista.

In a GPO containing only SRP rules, the rules are enforced on all computers running Windows, including those running Windows Server 2008 R2, Windows 7 Ultimate, and Windows 7 Professional. However, if a GPO contains both SRP rules and AppLocker rules, these same three operating systems read only the AppLocker rules. The SRP rules are applied to computers running other Windows operating systems.

AppLocker Relies on the Application Identity Service

AppLocker rules are enforced on eligible clients only when those clients are running the Application Identity Service. By default, this service is not configured to start automatically on computers running Windows 7. If you want to enforce AppLocker rules, therefore, you should use Group Policy to set the Startup Type parameter to Automatic for the Application Identity Service.

PRACTICE: Preventing Software Installation with AppLocker

In this practice, you download an .msi file from the Microsoft Web site and then prevent installation of that .msi file through AppLocker.

EXERCISE 1 Obtaining an .msi File

In this exercise, you download the file SharedView.msi from the Microsoft Download Center. You then begin a new installation to test its functionality.

1. Log on to the domain from the client running Windows 7 (Computer1) as a domain administrator.

2. In Windows Internet Explorer, visit the Microsoft Download Center at http://download.microsoft.com. Search for the file “SharedView.msi,” and save it to your Downloads folder on Computer1. (If you do not have Internet access from Computer1, you can download the file from another computer and copy it to Computer1.)

   NOTE: YOU CAN USE ANY .MSI FILE

   Although we will use the file SharedView.msi in this exercise, you can replace this file with any other that you can locate and copy to the Downloads folder on Computer1.

3. Share the Downloads folder by granting Read access to Everyone. To perform this step, right-click the Downloads folder, choose Share With on the shortcut menu, and then click Specific People. In the File Sharing window, type Everyone, click Share, and then click Done.

4. Open the Downloads folder and double-click SharedView.msi to begin the installation.

5. If an Open File-Security Warning message box appears and asks if you want to run the file, click Run.

6. The first page of the Microsoft SharedView Setup wizard appears. The fact that the wizard has started indicates that the .msi file is not blocked.

7. Click Cancel and then Yes to close the Microsoft SharedView Setup wizard.

EXERCISE 2 Configuring AppLocker to Block an .msi

In this exercise, you create a GPO, and then, in the new GPO, you create the default rules for AppLocker in the Windows Installer rule collection. Finally, you create a new Windows Installer rule that denies SharedView.msi.

1. Switch to the domain controller (DC1), and log on as a domain administrator.

2. Open Group Policy Management, which is available through the Start menu in the Administrative Tools folder.

3. In the Group Policy Management console tree, locate and expand the Domains container, and then select the domain (Nwtraders.msft) node.

4. Right-click the Nwtraders.msft node, and then click Create A GPO In This Domain, And Link It Here in the shortcut menu.

5. In the New GPO dialog box, type AppLocker Block SharedView.msi, and then click OK.

6. In the Group Policy Management console, in the details pane, right-click the AppLocker Block SharedView.msi GPO, and then click Edit. The Group Policy Management Editor opens.

7. In the Group Policy Management Editor console tree, navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Application Control Policies\AppLocker\Windows Installer Rules.

8. Select and then right-click the Windows Installer Rules node, and then click Create Default Rules from the shortcut menu.

   In the details pane, three new rules appear. These rules allow everyone to run all digitally signed Windows Installer files, everyone to run all Windows Installer files (signed or not) in the %Systemdrive%\Windows\Installer directory, and administrators to run all Windows Installer files without exception.

9. Right-click the Windows Installer Rules node, and then click Create New Rule on the shortcut menu. The Before You Begin page of the Create Windows Installer Rules wizard opens.

10. Read all of the text on the page, and then click Next.

11. On the Permissions page, click Deny, and then click Next.

12. On the Conditions page, leave the default selection of Publisher, and then click Next.

13. On the Publisher page, click Browse.

14. In the Open window, in the File Name field, type \\computer1\users\username\Downloads\SharedView.msi, and then click Open. For the variable username, specify the name of the account that you used in Exercise 1 to copy SharedView.msi to the Downloads folder. On the Publisher page, the information from the digital signature in the .msi file has populated the gray fields next to the slider.

15. Raise the slider two notches so that it is positioned next to Product Name. Next to the slider, MICROSOFT SHAREDVIEW still appears in the associated field, but the two fields beneath contain only an asterisk (“*”).

16. Click Next.

17. On the Exceptions page, click Next.

18. On the Name And Description page, type Block SharedView.msi in the Name text box, and then click Create. The new Deny rule now appears in the details pane.

19. In the Group Policy Management Editor console tree, navigate to Computer Configuration\Policies\Windows Settings\Security Settings\System Services.

20. In the details pane, double-click to open the Application Identity service. The Application Identity Properties dialog box opens.

21. In the Application Identity Properties dialog box, check Define This Policy Setting, click Automatic, and then click OK. Clients need to run this service for AppLocker to work.

22. Close the Group Policy Management Editor console and the Group Policy Management console.

23. Switch to Computer1, and then restart Computer1.

EXERCISE 3 Testing the Configuration

In this exercise, you test the results of implementing the new GPO that you created in the last exercise.

1. After Computer1 has finished restarting, log on to the domain from Computer1 as a domain administrator.

2. Open your Downloads folder, and then double-click SharedView.msi.

3. If an Open File-Security Warning message box appears and asks if you want to run the file, click Run.

4. A Windows Installer warning message appears, indicating that the system administrator has set policies to prevent this installation.

5. Click OK to close the message.

6. Return to DC1. In the Group Policy Management console tree, locate the GPO named AppLocker Block SharedView.msi.

7. Right-click the AppLocker Block SharedView.msi GPO, and clear Link Enabled on the shortcut menu. This step effectively disables the policy.

8. Log off both computers.

Lesson Summary

• The successful installation of software depends on many requirements. These requirements include local administrator privileges, Windows 7 compatibility, proper installation settings, and other factors. To troubleshoot problems with an installation, you should verify that all of these requirements are met.

• A Windows Installer program can also be blocked by SRP or AppLocker.

• AppLocker is an improved version of SRP that is new to Windows 7 and Windows Server 2008 R2. Improvements in AppLocker include the publisher rule condition, the ability to assign rules to specific users and groups, and audit-only mode.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 1: Understanding and Resolving Installation Failures. The questions are also available on the companion CD if you prefer to review them in electronic form.

1. You work for Fabrikam, Inc., a firm whose network consists of a single Active Directory Domain Services (AD DS) domain.

   Fabrikam’s development team periodically tests new software tools for various departments. Recently the team has been testing a tool created by another company, a new partner named Contoso.com. Whenever authorized users attempt to install the program, however, they receive a warning informing them that the program is from an unknown publisher.

   You want to allow authorized users to install applications made by Contoso without receiving a warning. What should you do?

   1. Ensure that all authorized users are administrators of the computers on which they are installing the software.

   2. Provide authorized users with the credentials of a domain administrator and instruct them to provide these credentials at the User Account Control prompt when they attempt to install the software.

   3. Use Group Policy to deploy the public certificate provided with the software to the Trusted Publishers certificate store on all required computers.

   4. Use Group Policy to deploy the root certificate for Contoso.com to the Trusted Root Certification Authorities certificate store on all required computers.

2. You want to use AppLocker to prevent users from running a file named NewApp.msi for versions 7.0 and earlier. You have already created the default rules. How can you achieve this objective?

   1. Create a new Executable rule with the Publisher rule condition.

   2. Create a new Executable rule with the File Hash rule condition.

   3. Create a new Windows Installer rule with the Publisher rule condition.

   4. Create a new Windows Installer rule with the File Hash rule condition.