An Introduction to AppLocker (Part 2)

by [Published on 22 Sept. 2009 / Last Updated on 22 Sept. 2009]

Issues that should be tackled before creating AppLocker rules.

If you would like to read the other parts in this article series please go to:


Although AppLocker is far superior to Software Restriction Policies, there are some major issues that you need to be aware of before you ever create your first AppLocker rule. This article explains those issues.

In my first article in this series, I explained that Microsoft introduced Software Restriction Policies in Windows XP as a way of allowing administrators to have control over which applications users are allowed to run. As history has shown though, Software Restriction Policies have some major shortcomings. With the release of Windows 7, Microsoft has attempted to address these shortcomings through a new feature called AppLocker.


Although AppLocker is technically a new version of the Software Restriction Policies feature, AppLocker is not compatible with Software Restriction Policies. If you currently have Software Restriction Policies defined within a Group Policy Object, those policies will continue to work, even if you upgrade your organization’s PCs to Windows 7. However, if you define AppLocker policies within the same Group Policy Object that already contains your Software Restriction Policies, then computers that are running Windows 7 will ignore your software restriction policies, and only the AppLocker policies will be applied.

On the flip side, if a Group Policy Object contains both Software Restriction Policies and AppLocker policies, then computers that are running Windows XP and Vista will ignore the AppLocker policies and will only use the Software Restriction Policies. This happens because the AppLocker feature does not exist in legacy operating systems.


Although AppLocker does offer a big improvement over Software Restriction Policies, it does have some limitations. The biggest limitation is that if users have administrative permissions over their own computers, then AppLocker can be easily circumvented.

Microsoft typically recommends that you do not give users administrative rights, but in the real world doing so is sometimes unavoidable. After all, there are some applications that simply won’t function correctly unless the user has total control over the system.

If you want to use AppLocker, but your users have administrative permissions, then I would recommend taking some time to see if there are any alternatives to giving the users full administrative control over their computers. Perhaps you can provide users with full control over certain folders without actually having to give them full blown administrative permissions. This approach does not always work though, because some applications require that the user be able to modify the registry or other parts of the operating system.

If users do require full blown administrative access to the system, you might be able to get away with simply locking down the administrative tools. For example, you might be able to create a rule that locks down things like the Registry Editor or Windows PowerShell. If you attempt to use this approach, you must take care not to make the rule global in scope. After all, your help desk staff will likely require access to the various administrative tools so that they can correct problems with user’s machines.

Basic AppLocker Strategies

Although AppLocker supports some of the same basic types of rules that Software Restriction Policies use, the basic way in which AppLocker works is quite a bit different from what you might be used to. In fact, it is easy to get yourself into a lot of trouble if you do not understand the way that AppLocker works. Therefore, I recommend that you pay close attention to what I am about to tell you in this section.

In order to safely use AppLocker, you have to understand Microsoft’s basic philosophy behind AppLocker rules. This philosophy revolves around the idea that there are specific applications that you use in your organization. In contrast, there are a nearly infinite number of applications that your organization doesn’t use. Don’t think of these applications in the traditional sense, but rather as executable code. For example, some of the types of “applications” that you may not have approved for use in your organization might include older versions of the applications that you do use, video games, malware, peer networking software, and the list goes on.

My point is that there are way more applications that you do not want users to run than there are applications that users are supposed to be using. That being the case, it is far easier to provide Windows with a whitelist of approved applications than it is to block every single application that you want to prevent from running. This is Microsoft’s philosophy behind the way that AppLocker rules work

This leads me to the first major concept behind AppLocker rules. Even if you remember nothing else from this entire series, please remember this. AppLocker rules are organized into collections (which I will talk more about later in this series). Although it is possible to create an explicit denial, AppLocker rules should usually be thought of as a mechanism for granting permission to something (remember, it is easier to approve the software that you want to allow than to ban the software that you want to restrict). Now here comes the really important part. If you create so much as even one single rule in a rule collection, then Windows automatically assumes that you want to prevent everything else from running.

This is an extremely important concept to grasp because let’s suppose for a moment that you wanted your users to be able to run Microsoft Office and Internet Explorer, so you create a rule that allows them to do so. In doing so, you have denied the user the rights to run anything else, including the Windows operating system. Believe it or not, it is easy to accidentally lock a user out of Windows by improperly creating AppLocker rules. This is something that I am going to address a lot more as the series goes on.

The last thing that I want to talk about is denials. As you may recall, I mentioned earlier that it is possible to prevent users who have administrative permissions to the system from running administrative tools, but that you can create an exception for the helpdesk staff. This is something that I am going to discuss in more detail later on in the series, but for right now I wanted to point out that establishing this type of configuration requires a bit of backward thinking.

Given the way that AppLocker works, we can’t just deny everyone access to the administrative tools. Instead, we would have to grant everyone access to the Windows system files. From there we could add a denial for the administrative tools that applies to a specific group of users (everybody but the helpdesk staff). You don’t have to do anything for the helpdesk staff because they have access to the administrative tools because you have given everyone access to the Windows system files.


In this article I have explained that it is easy to accidentally lock yourself out of Windows by creating an improper set of AppLocker rules. That being the case, I would highly recommend experimenting with AppLocker on one or more lab PCs before you ever attempt to use AppLocker in a production environment. In Part 3 of this series, I am going to begin showing you how to actually create AppLocker rules.

If you would like to read the other parts in this article series please go to:

See Also

The Author — Brien M. Posey

Brien M. Posey avatar

Brien Posey is an MCSE and has won the Microsoft MVP award for the last few years. Brien has written well over 4,000 technical articles and written or contributed material to 27 books.


Featured Links