Software Restriction Policies was introduced in Windows XP for administrators to control the software allowed to run on computers that they manage. The more advanced version of Software Restriction Policies, AppLocker, is available in Windows Server 2008 R2 and in some editions of Windows 7.

In AppLocker, you can create rules for a specific product name, such as "Allow Adobe Acrobat Version greater than 7.0 to run." With this type of rule, there is no need to change the hash rule with every application update or verify the path of the executable right or the access right of someone to write to that path. This type of rule can be general or specific, depending on the criteria that you select: publisher, product name, file name, or version. The information that the rule is based upon is gathered from the digital signature of the application.

Simplified rule structure

In AppLocker, there are no complex precedence rules for different rule types such as path or hash. All Deny rules take precedence over Allow rules irrespective of rule type. If you create an Allow rule in AppLocker, the items that are allowed in those rules will be allowed to run unless there is a Deny rule that specifically denies that item.

User rules that can be enforced whether a user is interactively logged on or not

With Software Restriction Policies, you can only target rules for specific users by setting those rules in a specific user policy. This means that a help desk administrator who is remotely administering a user's desktop is subject to the default machine rules and cannot run administrator tools or other specifically allowed programs. In AppLocker, user rules are enforced whether a user is interactively logged on or not.

Ability to set separate policies for .exe files, .msi files, scripts, and DLLs

In Software Restriction Policies, if you allow files in a certain path to run, then .msi files or scripts in that path can run as well. In AppLocker, the desktop administrator only has to author rules for the specific lockdown scenario. This means that executable rules apply to executable code; path rules created for executable programs will not be applied to DLLs. To control DLL behavior, you must create a DLL rule. This componentization makes it easier for desktop administrators to determine how their rules will be enforced.

Audit-only mode

In AppLocker, you can enable an audit-only mode, which allows you to test how your rules would be applied without actually enforcing them.

Rule creation wizard

In AppLocker, a rule creation wizard can be used to generate rules that will allow all applications in a specified folder to run.