App-V and AppLocker

Microsoft snuck one past me. I have wanted to write about using Microsoft's Application Virtualization product, App-V, in conjunction with their new AppLocker technology, but I was prevented from doing so by an NDA.

Microsoft snuck one past me. I have wanted to write about using Microsoft's Application Virtualization product, App-V, in conjunction with their new AppLocker technology, but I was prevented from doing so by an NDA. That NDA was related to the 4.6 release, which is not due out until the first half of next year. But Microsoft released 4.5 Service Pack 1 this month, and snuck into the release notes was support for AppLocker. I just noticed this during my prep for a training class next week.

Some Release History

The RTM version of App-V 4.5 supports clients and sequencing on Windows XP, Vista, Server 2003, and Server 2008 (without R2).

Microsoft released 4.5 CU1 (Cumulative Update 1 -- who names these things?) last winter, which in addition to being a rollup of hotfixes, added support for the beta version of Windows 7.

4.5 SP1, I thought, simply rolled up more fixes and added official support for the RTM version of Windows 7. Support for the App-V Sequencer/Client on Windows Server 2008 R2, which is only available as a 64-bit OS, is not due out until "the first half of 2010". App-V 4.6, which is currently in Public Beta via Microsoft Connect, is the first to allow the sequencer and client on x64 versions of the operating systems. [Although not the point of this article, I'll mention that the beta rocks! It supports both 32- and 64-bit virtual apps on the x64 platform].

Sneaky Stuff

As I prepared for my next training class I was reviewing 4.5 SP1 in case there were any surprises. First, I was surprised to see that the release includes not only a new client and sequencer, but a new TS client and server too. I have not figured out why the server was included, but am guessing it is only for improved support of MIT based Kerberos environments mentioned in the release notes.

But also snuck into the release notes was a note that 4.5 SP1 (aka 4.5.2) supports the use of AppLocker on Windows 7 Clients. So I guess we can talk about it now!

What is AppLocker and why does App-V need support?

AppLocker is Microsoft's latest incarnation of Software Restriction Policies, only this time I think they got it right. AppLocker requires the use of Active Directory based on the Server 2008 R2 release, and either Windows 7 or Server 2008 R2 Remote Desktop Session Hosts (aka: Terminal Servers). It allows IT to define policies, using both white and black list rules, that define what executables, installers, and scripts, users are allowed to run. Microsoft wisely provides default templates, such as white listing OS components, allow designation of signed-code certificates, and hash based application designation (which prevents a user from just copying a exe to a new name to avoid blacklisting). There is even an audit/enforcement mode so you can test your policies before putting them into effect. Best of all, the support for preventing execution is inside the kernel and not in an external user mode service, which eliminates so many back doors.

What is a "WhiteList" or "BlackList"?

A "WhiteList", called an "Allow" rule in AppLocker , is a rule that specifically states that things that are allowed to be run.A "BlackList", called a "Deny" rule in AppLocker , is a rule that specifically states things that may not be run.WhiteListing is usually considered to be the best style of rule by security professionals, but is often not practical because you need to know everything in advance.BlackListing helps by allowing you to turn certain things off, in this case, for specific users or computer.

So why does App-V need to support AppLocker?

Previous releases of App-V do not work well with AppLocker.Microsoft needed to make some changes in App-V primarily because of it's special file system.All of that isolation going on gets in the way of AppLocker doing it's job.So AppLocker does not work with virtual applications running on App-V clients at 4.5.1 and older .Microsoft had to make some small adjustments to get this to work.They also wanted to improve on what the user sees when they are denied access to a virtual application by AppLocker.

Why do App-V Shops Need AppLocker?

App-V applications can be deployed in several ways. You can use a central server that is dedicated to serving up virtual applications, you can use SCCM 2008 R2, or you can use the client in "stand-alone mode". With the dedicated server, applications can be deployed on a per user basis, but not a per-computer basis. With SCCM and the stand-alone client, applications can be deployed on a per computer basis but not per user.

NOTE: There is some confusion regarding deployment using SCCM R2 and the ability to assign on a per user basis to Terminal Servers.For production purposes, it just doesn't work right! According to the Microsoft White Paper "Application Virtualization 4.5 for Terminal Services," Using Microsoft System Center Configuration Manager (SCCM) R2 with terminal servers only allows delivery to the console session for advertisements.This would eliminate the possibility of user-based targeting as the users will not log on to the console session and, therefore, will not run the advertisement.This is a SCCM limitation for both virtual and traditional applications.

I often hear from enterprise customers that want to mix and match per-user and per computer deployment of virtual applications.For example, in a University setting, it is common to use the Dedicated server to deploy apps on a per user basis, but they have some special applications such as AutoCAD that are licensed for use only on certain lab machines.They want to ensure the student who is in the lab can run the software in the lab but can't run the software elsewhere.I also hear from Terminal Server shops that want to move to SCCM R2, but want per-user assignment capabilities.AppLocker might not be the ideal solution, but in certain cases it might make sense.

Think of application deployment as being a multi-stage set of actions which all must pass for the user to get and run an application:

  • The application must be prepared and centrally placed.
  • A deliver of the virtual application to the target client machine.
  • A publishing of shortcuts to a start menu.
  • An authorization.

Previously, authorization was defined by the publishing/delivery steps (possibly re-enforced at runtime).Although most people think of App-V supporting delivery and publishing tied together, often companies separate out the publishing (such as in a Citrix environment, or using another third party tool such as RES).Using AppLocker, we can now more clearly define authorization rules that match what we need.


Microsoft has a number of documents and videos available for AppLocker.Here are a few:

The video, and examples, above show setting up AppLocker using local security policies, so figuring this out using the Active Directory Group Policy Editor was a little bit of a challenge.


Because I can't show you the TS scenario yet, I set up an example using Windows 7computer that is shared between users at different times.In the example that follows, Ihave used App-V 4.5 SP1 to deploy an application on a per-computer basis.   I might have set up the client using SCCM R2 for the deployment, but in this case I happened to use the App-V 4.5 SP1 client configured in stand-alone mode.It isn't much of a stretch to imagine doing the same with aServer 2008 R2 Terminal Server when 4.6 is released.

Work started at a Server 2008 R2 domain controller.In theServer Manager, I opened up Features to reveal the Group Policy Management console.In the capture below, you can see that I have already createda policy called "AppLocker_SharedAppv".Because AppLocker is a computer based policy, this policy will be applied using a filter limiting implementation to only computers requiring the policy.



When I created the policy, I used the Group Policy Management Editor (by creating a new Group Policy Object from the Manager).The capture below shows the relevant portion for working with AppLocker.


 In the above capture, I highlighted the AppLocker entry to expose the information shown on the right side of the screen.In the "Configure Rule Enforcement" box there are two very important parts.

First, the warning note.Windows 7 and Server 2008 R2 come with an installed service called "Application Identity".By default, the service is off and set for manual start.On client machines that want to use AppLocker, this service must be set to an automatic start (and started).I was scratching my head for quite a while until I figured this one out.In my test, I did this manually, but I suppose you could also do this in Group Policy also.


Second, in the"Configure Rule Enforcement" box there is a link to configure the rule enforcement.For my example, I only want enforcement for executable rules, and not installers or scripts.This is shown below.


Once configured, in the editor I created an executable rule.When I tried to create the rule using the wizard, the wizard detected that I had not created default rules, and prompted me to have the wizard do so.You need these default rules, which enable general windows and program file apps to run, as well as allow administrators to run anything.(Keep in mind that these rules apply only to what AppLocker will allow.A user still needs ACL access, for example).

I created an executable rule to deny access to an exe based on the file hash.I denied users that were members of a particular group access to PaitDotNet.exe.All I needed to do was point to a copy of the exe and the wizard calculated the hash.The wizard also supports path based rules and digital code signatures.



After closing the editor, I applied the policy using a security filter to limit the computers that apply this policy.


I test by logging into the client computer with the application deployed using the App-V to all users of the computer.This computer is a member of this security filter group, and I log in using an account that is part of the deny group in AD for this application.When I attempt to launch the application, App-V seems to be able to detect that AppLocker caused the denial and displays a new error message, 2C-000004EC, indicating that AppLocker is responsible.




App-V 4.5 SP1 on Windows 7Enterprise and Ultimate, but not Professional, clients (and eventually Windows Server 2008 R2 clients) can make use of the AppLocker technology built into those operating systems when deployed in a Server 2008 R2 Active Directory environment.

Using AppLocker with App-V is probably more of a niche requirement, but the combination looks to be useful for some situations.To my knowledge, Microsoft has not made any noise about back-porting AppLocker to older operating systems, which probably limits the scope for a while until those operating systems become more widely deployed.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Great if you are married to App-V which or wrong average person will blindly follow, Appsense can already do this on any exe. I wonder this mean for them? MS should buy them or similar and add their stuff into MDOP and add value to their VDI platform. It would solve so many problem. But of course the MDOP team still believes that Med-V is going to solve world hunger. The dumb leading the blind.


RES, AppSense or Scense User workspace Management. Guess they all exist because of issues like these. need some proof?

or visit us at TechEd.


Nice work Tim. Businesses which don't want/can invest in the tools Hessel mentioned will have big advantage of the AppLocker feature. More control and easier to manage and again a little more easier.

PS.I think you made a typo in the release history bit. Should be 4.5 SP1 instead of 4.6 SP1 (third alinea, first line)


Appdetective can get me a guide dog and a copy of JAWS, as im a dumb blind person.

Re user enviro man, GP Prefs came from the Desktop Standards acquisition, and MS didnt make it exclusive to MDOP. MS should really aquire RTO and replace roaming profiles.

App Locker is there cause normal software restriction policies were not good enough, you couldnt easily create white lists.

Anyway back on topic.

Thanks for the write up Tim.

Another idea is to publish app-v shortcuts, via GP prefs and use its rich targeting.

The issue I have about using plain app locker is its negative feel to an end client that runs a denied app. U can customise the deny message and put in a URL, but it would be better to not have the entry point there in the first place if they cant use it. But hey it is a solution...


@Jurjen - thanks, fixed typo.

@rahvintzu - Yes, I am assuming that you handle the shortcut publishing from anther method.  Have not considered GP Prefs as they method.  I guess you still want somtthing to automate the prefs creation though.


How about this....Divide your apps into your two models, User vs Device.

For user based then use native app-v publishing (assuming stream mode), for device then create a pref shortcut. For me the amount of apps that are device based are in the minority, I guess if you had an app portfolio of the majority as device based then you would want to automate the entry point creation process.


That said im using SCCM in cache mode.

But my next SOE will use standalone stream severs. Not a huge fan of the SCCM implementation its abit half arsed, in a few areas.

I hope they improve things in SCCM 2010.


Yeah I can't wait for some TS admin to block cmd.exe using AppLocker only to find that the gazillion App-V OSDs that are using pre-launch scripts start failing... tee hee


@Tim Mangan Thank you for putting that together. I learned a lot from the read.



This is why the default app locker policies are auto created for you. But you can guess some bright spark will delete them (to be really secure). You just have to hope the GP is no global in scope.

This is actually a nice (or not so nice) way to drop AD, apply software restriction policies to DCs without default rules.