CHAPTER 9 (I)

CHAPTER 9

Troubleshooting Software Issues

Software errors can appear during the installation process, immediately after installation, or long afterwards. Those that appear during installation tend to result from policy or permission constraints, availability issues, or installation settings. Those that appear immediately after installation tend to be associated with policy restrictions or  compatibility problems. Those that appear long after installation tend to result from configuration changes.

In this chapter, we look at the various causes of software errors and provide strategies for how to resolve them.

Exam objectives in this chapter:

■ Identify and resolve new software installation issues.

■ Identify and resolve software configuration issues.

■ Identify cause of and resolve software failure issues.

Lessons in this chapter:

■ Lesson 1: Understanding and Resolving Installation Failures 340

■ Lesson 2: Resolving Software Configuration and Compatibility Issues 355

Before You Begin

To perform the exercises in this chapter, you need:

■ A domain controller running Windows Server 2008 R2

■ A client running Windows 7 Enterprise that is a member of the domain

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.

After this lesson, you will be able to:

■ Troubleshoot software installation failures by verifying a number of well-known installation requirements.

■ Understand how AppLocker can prevent software installations.

■ Understand many of the feature improvements of AppLocker over Software Restriction Policies .

■ Use AppLocker to block a Windows Installer program from running.

Estimated lesson time: 30 minutes

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.

FIGURE 9-1 Viewing the local administrators

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.

FIGURE 9-2 Running an installation with administrator privileges

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, “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  roperly, 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.

FIGURE 9-3 Avoid installing programs from untrusted publishers.

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.

MORE INFO

DEPLOYING APPLICATIONS

The following Web sites are good resources for automating the installation of applications, as well as other deployment topics:

■ AppDeploy.com at http://www.appdeploy.com

This Web site provides information about deploying applications that are packaged using a variety of technologies.

■ Source Forge at http://unattended.sourceforge.net

This Web site describes how to automate the installation of many older installers.

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.

FIGURE 9-4 An installation prevented by AppLocker

FIGURE 9-5 An installation prevented by SRP

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.)

FIGURE 9-6 AppLocker is configured in a GPO.

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

REAL WORLD

J.C. Mackin

AppLocker is a great feature in many ways, but I don’t believe it sufficiently warns administrators about the dangers of configuring it incorrectly. If you create a new rule without also creating the default rules, for example, you can easily lock yourself and everyone else out of your computer. I actually experienced this problem firsthand when I originally saw AppLocker in a Windows 7 beta. I simply made a rule in Local Security Policy denying access to Notepad.exe, and I ignored the messages prompting me to create the default rules. Immediately afterwards, I was dismayed to see that Windows could not start. What I didn’t know at the time was that AppLocker is enabled when you create the first rule. After you create that first rule, all programs of the same type—executables, in this case—are denied if you have not allowed them. Luckily for me, this was only a virtual environment, and I had made a data snapshot of the computer before making any changes. It was easy for me to return the computer to the previous state. But I thought—what if this were a real environment? It’s not unusual for administrators to explore new features on their own machines. Few people would suspect that the punishment for incorrectly configuring such a feature would be locking themselves out of their computer indefinitely. Worse yet, what if someone actually applied such a policy to the entire domain, and the domain controllers themselves were rendered unusable? It could be a disastrous situation. What you should remember is always to create the default rules first in AppLocker and then create additional rules to modify the behavior of those default rules. When creating new rules, always test your results first in audit-only mode or use a virtual machine environment so that you can easily revert to a previous state if necessary.

Quick Check

■ How do you find messages related to AppLocker in Event Viewer?

Quick Check Answer

■ In the Event Viewer console tree, navigate to Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\AppLocker.

Q

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 Shared View 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 Shared View 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 %System drive%\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.