None of us love all applications equally. For one, there are those our users aren't supposed to be running: Streaming video. Elf bowling. Unapproved instant messaging. Try as you might, you'll never stop your users from getting to all of them.

These things kill productivity, hammer the network, and half the time seem packed with junkware, spyware, and who knows what else. And those are just the applications your users know they're not supposed to be running. There's also that whole class of 'quasi-business' applications that have an arguable business benefit ' but which your company hasn't paid for, isn't licensed to use, and doesn't want. Those can not only cause support issues, but outright financial damage if you're caught.

How can you stop them all?

It's tough. Windows' primary function, after all, is to run applications, and it does a pretty good job at it. Getting it to not run applications kind of goes against the grain. In Windows XP and Windows Server 2003, Microsoft introduced a technology called Software Restriction Policies (SRP), a part of Group Policy that was intended to keep unwanted applications from running.

With SRPs, you'd make a big list of all the applications you wanted to permit, and nothing else could execute. The technology more or less flopped. Oh, organizations definitely used it, and it works as advertised, but the process of assembling and maintaining that list of approved applications was incredibly complicated and time-consuming. Many, many organizations simply didn't have the time or resources, and so they gave SRP a miss.

That was 12 years ago. Hasn't anything better come along?

Introducing AppLocker

You've probably heard of AppLocker. It is a new feature of Windows 7 billed as the solution to SRP's tedious application whitelist maintenance. On paper, AppLocker scans your environment to find the installed apps and automatically constructs the whitelist for you. You can, of course, edit that to remove the already-installed applications that you don't want to permit, and you can maintain the list going forward.

So is AppLocker the answer?

Maybe. To be sure, AppLocker is still a complex piece of business, and it's far from perfect. To begin with, inventorying applications requires configuring client computers to run the new Application Identity Service, something that ships with Windows 7 but isn't enabled by default. This service is designed to read application rules from Group Policy, and then identify applications accordingly. In other words, this service basically makes AppLocker work.

Once enabled and running, the service reads application rules from Group Policy and evaluates every application that attempts to execute on the computer. If an application isn't permitted by your rules, then AppLocker prevents it from executing.

AppLocker logs verbose information to the Windows event log system, showing you which file was affected, whether it was blocked or allowed by a rule, the name of the rule, and so forth. On the face of it, this is pretty easy: Just get the service up and running on your client computers, something you can do with a Group Policy object (GPO) if you prefer. Configure rules in a GPO as well, and you're up and running.

AppLocker vs. SRP

First, a couple of differences between the old SRP and the new AppLocker, lest you think that AppLocker is just a quick way of generating SRP rules. AppLocker intends to deny applications by default, only allowing those that have a rule permitting them to run. AppLocker can also be run in audit-only mode, wherein it generates event log messages about the applications that are running. This is a key part of setting up AppLocker: By configuring those event logs to forward to a central computer, you can see which applications AppLocker might have blocked simply because you forgot to create a rule. By poring through the log entries (sounds fun, right?) you can ensure that you've accounted for every permitted application.

Generating the List

The problem with AppLocker all comes down to how you generate that whitelist. After all, AppLocker's roots are in SRP, which goes all the way back to Windows XP. Blocking applications isn't a new idea; what's supposedly new is the ease with which you can construct that whitelist.

Figure 1 - Applocker

The problem is that modern organizations have hundreds, if not thousands of applications. We're not talking about copies of Office, we're talking about the litany of line-of-business applications, tools, utilities, and other little pieces of software that people run. The sheer magnitude of an inventory project can often consume more time and more resources than you'll pay back with AppLocker, especially in smaller- and medium-sized businesses that don't have extra IT resources lounging around the datacenter.

AppLocker works by scanning one or more reference machines. The idea is that you take some machine that represents an 'allowed' set of applications. Most companies will start with a standard corporate desktop image that has all the standard corporate apps, and use that as their reference machine. AppLocker figures out what's on it, and generates rules to allow all of those applications. Easy.

Figure 2 ' Automatically Creating Whitelist Rules

Or is it? Do you ever install additional applications on top of that corporate image? Probably ' and AppLocker won't catch those right away. Do you have more than one corporate image? You're going to have to scan them all. And that's where AppLocker starts to get more complicated: Combining multiple rule sets, eliminating unwanted applications that are already out there, and so forth.

More complicated is the process of testing your AppLocker rules. Because the Application Identity service can be run in 'audit-only' mode, you can test your rules. However, the service only logs event entries to the local event log. That means you're going to need to configure multiple client computers (and servers, if you're using AppLocker to lock them down as well) to forward events to a central computer, and you're going to have to manually scan that computer to catch applications that would have been improperly blocked.

Figure 3 ' Enforce Rules vs. Audit Only

Ugly and time-consuming, you'll find yourself wishing for some kind of central consolidation and reporting functionality that Microsoft sadly hasn't included. Interestingly enough, Microsoft actually suggests you can also use Remote Desktop Services to remotely view events on other computers, but that's even more time-consuming.

AppLocker doesn't work well with the one-off exceptions that we all know are a way of life in IT. The CEO needs to run Elf Bowling? Creating that single exception isn't easy. You could remote into the CEO's machine (using Remote Desktop or Windows PowerShell) and configure an AppLocker rule as part of the machine's local policy.

If you're going to start using AppLocker, plan for those one-off exceptions to occur, and have a process for dealing with them (or very high-level support for not dealing with them). AppLocker also doesn't have a lot of flexibility: Once applied, it's applied until you change the rule set in its GPO(s). You can't have it stop working for certain time periods, although you can have it apply only to specific users or groups. There's no elegant way to temporarily allow a particular application. And AppLocker certainly isn't a licensing inventory or collection tool: It won't tell you how many people are running a given application, nor will it start blocking an application after a certain number of licenses are put into use.

Beyond SRP and AppLocker

If you've been using SRP, AppLocker is a huge step forward. If you haven't been using SRP, then AppLocker may not appeal to you either because it still comes with much of the same inflexibility. The good news is that, as an industry, we've never really relied on Microsoft to provide this kind of 'allowed application' functionality. Third party ISVs have always offered a far more robust set of capabilities.

While it's a great idea to block all but your specifically-allowed applications, most organizations aren't interested in doing so as a means of preventing malware. We've all got anti-malware software installed everywhere we want it, and it usually works just fine. What we need is to get a handle on the non-malware software that we simply don't wish to permit in our environments, and to get some control over software licensing.

Third-party software management applications tend to approach those goals similarly to AppLocker, starting with an automated inventory of applications. Rather than simply identifying applications by their publisher certificate or a file hash, true software management systems use massive databases that detect application fingerprints and create a more readable and effective inventory. With these solutions you'll know application names, versions, publishers, and so forth, so you can quickly spot which ones shouldn't be there ' and block them.

Unlike AppLocker, most third party solutions can tell you how many people are running each application. This knowledge is critical in the increasingly-challenging world of software licensing compliance. Some solutions even let you tell them how many copies you've paid for, and block allowed applications that are being used by too many people. In many cases, those solutions put users in a 'waiting list,' where they'll be notified when a license is available. Administrators will be notified that insufficient licenses are available, helping drive smarter software purchases in the future. You'll also be able to see when you have too many licenses for some product, and when upgrade time rolls around you can purchase fewer licenses and save some money.

These third-party solutions rarely require much more footprint than AppLocker itself. Usually there's a client-side service that you'll deploy, and some central server application and database. That central server is something AppLocker doesn't have or require (outside its Active Directory Group Policy roots), but it's the bit that gives you the central reporting and control AppLocker is missing.

Still, blocking unwanted applications is a project that requires ramp-up time. You're looking at an inventory process no matter which way you go, although with AppLocker you'll see more work in manual log reviewing than with dedicated third-party solutions. While AppLocker doesn't cost any more than your Windows 7 Enterprise or Ultimate licenses, it also doesn't provide the complete range of functionality that your organization may need. AppLocker may well be a fit for your needs, but before you turn it on and start generate rules in GPOs, take a few minutes to think about all the functionality you may need, and make sure that AppLocker is the right solution for your ongoing needs.