Determine How to Fix Applications That Are Not Windows 7 Compliant

Applies To: Windows 7, Windows Server 2008 R2

Windows 7 includes User Account Control (UAC) virtualization technology for applications that are not UAC compliant and that require administrative credentials to run correctly. When an application that is not UAC compliant attempts to write to a protected directory, such as the Program Files folder, UAC gives the application its own virtualized view of the resource it is attempting to change. The virtualized copy is maintained in the user's profile. This strategy creates a separate copy of the virtualized file for each user that runs the non-compliant application. There are, however, scenarios where UAC virtualization cannot be used:

• UAC virtualization does not apply to applications that are elevated and run with a full administrative access token.

• UAC virtualization supports only 32-bit applications. Native Windows 64-bit applications are required to be compatible with UAC and to write data to the correct locations.

• UAC virtualization is disabled for an application if the application includes an application manifest with a requested execution level attribute. Applications that are built by using Microsoft Visual Studio 2008 include an application manifest by default.

The following questions are designed to help you troubleshoot an application that does not run as a standard user. The questions are presented in the order that they should be answered.

1. Is the application performing legitimate administrative tasks?

2. Can an update fix the issue?

3. Is this a standard user compatibility issue?

4. Will converting computer-wide data to per-user data fix the issue?

5. Will modifying the access control list for a file or folder fix the issue?

6. Will running the one application as an administrator fix the issue?

Is the application performing legitimate administrative tasks?

Some programs are designed to perform legitimate administrative actions and therefore require administrative permissions. For example, if the application is designed to install or manage software on the computer, then it requires administrator-level permissions to perform these actions. Tools that manage system resources generally require administrative permissions and can be used only by users who are logged on as members of the local Administrators group or users who can provide administrative credentials. Typical standard users should not need to run these applications.

Can an update fix the issue?

Fixing problems in the application code can be as simple as upgrading to the latest published version. For legacy applications, updates or bug fixes may no longer be an option.

Redesigning applications

Applications that unnecessarily require administrative rights should be redesigned to be UAC compliant. Microsoft has provided guidance and tools for application developers to help facilitate this redesign process. For more information, see Application Compatibility in the MSDN Library (https://go.microsoft.com/fwlink/?LinkId=49973).

Even with these changes, there can still be tasks that require full administrator access. Some examples include managing user accounts, installing device drivers, and running enterprise management software. With Windows 7, application developers need to determine which of the two levels of access (standard or administrative) their application requires for specific tasks. If an application does not require full administrator access for a task, then it should be written to require only standard user access checks. For example, a UAC-compliant application should write data files to the user profile or a file share instead of the Program Files folder.

Windows 7 logo program

The Windows 7 logo program is a major benefit of creating UAC-compliant applications. The program enforces strict certification guidelines, providing assurance to customers that certified products will integrate properly with Windows 7.

The Windows 7 logo certification provides a competitive differentiator and credibility for independent software vendors (ISVs). For more information about the Windows 7 logo certification process, see Windows 7 Logo Program (https://go.microsoft.com/fwlink/?LinkId=146648).

Is this a standard user compatibility issue?

A common reason for applications to fail to run correctly as a standard user is that the application writes data to files contained in the application installation folder, such as a folder in %ProgramFiles%. Because standard users do not have write access to the Program Files folder or its subfolders, the application fails when attempting to write to a file in this folder.

To verify that the problem is actually related to running with lower privilege and not related to another Windows 7 compatibility issue, attempt to run the application as an administrator with elevation on a test computer.

If the application has a compatibility issue when running as standard user, you can attempt to resolve the issue by installing one or more application compatibility fixes, also known as shims. Shims modify the behavior of the application in ways that address common standard user compatibility issues. Since each shim changes the system behavior for the targeted application, it is possible that a shim may introduce a separate compatibility problem with the application. Therefore, you should only install the shims that are required for the application to run.

For more information about shims, deciding when to use a shim, and how to manage a shim database, see Managing Shims in an Enterprise (https://go.microsoft.com/fwlink/?LinkID=151421).

Will converting computer-wide data to per-user data fix the issue?

When you convert computer-wide data to per-user data, the data is maintained in the user's profile and available only to that user. Two examples of converting computer-wide data to per-user data are:

• Identify HKEY_CLASSES_ROOT keys that the application writes to, and create those keys under \HKEY_CURRENT_USER\Software\Classes in the registry.

• Identify .ini files that the application writes to, and create IniFileMapping entries for those files in \HKEY_LOCAL_MACHINE\Microsoft\WindowsNT\IniFileMapping in the registry.

Will modifying the access control list for a file or folder fix the issue?

Judiciously modify the access control list (ACL) for one or more of the file or folder in shared locations that are used by the application.

Use the following guidelines to help you determine what changes to make:

1. Make ACL changes to application-specific resources only. ACL changes should be considered only on application-specific resources, not on operating system–wide resources. While it may be acceptable to change the ACL on %ProgramFiles%\PublisherName\ApplicationName\DataFolder, you should never change the ACL on %SystemRoot%\System32.

2. Limit ACL changes to files that are not used by administrators. Avoid changing ACLs on resources that are used by administrators or services, particularly executable files such as .exe and .dll files. Doing so increases the risk of "elevation of privilege" that can lead to compromising the entire system. If you must change ACLs for resources used by administrators, the attack surface still remains far smaller than it would be if all applications always ran as an administrator.

3. Avoid ACL changes on binaries. To prevent malware from infecting or replacing program files, avoid changing ACLs on program code (for example, .exe, .dll, or .ocx files).

4. Limit ACL changes to a single standard user. Ideally, the resource should be one that is accessed by a single standard user only. If the resource is accessed by multiple standard users, there is increased risk of one user causing another user's account to be compromised.

5. Grant the least additional privileges possible. You should grant the least amount of additional access to the smallest possible number of resources and to the smallest possible number of users to allow the application to function properly. Granting Full Control to the Everyone group on a large number of the system files or the registry should never be necessary. Granting the additional access only to the primary user of the computer is optimal but may be difficult to manage across a large number of computers when each computer has a different primary user. If you can define a set of users who need to use the program, add them to a group and grant the access to that group.

6. Grant access to the built-in Interactive group. Another alternative to consider is to grant access to the built-in Interactive group. This grants the additional access only to those who are logged on interactively at the time without granting additional remote access to the resource.

Will running the one application as an administrator fix the issue?

If no other solution can fix the issue, run the single non-compliant application as an administrator. This solution should be used only as a last resort. As an alternative to running the application as an administrator, investigate applications that help standard users run the applications that they require without granting additional privileges to the user or the application.