Consider the following scenario - I have created a Microsoft Office package with App-V that includes the base Office applications (Word, Excel, PowerPoint and Outlook). In addition to these I have also included Project and Visio. So I have a single App-V package that includes all of the Office applications – the base set of applications plus a couple of additional applications that I want to provide to a subset of users.
I have imported the package into my Management Server and given all users access to the Word, Excel, PowerPoint and Outlook shortcuts. I have created separate domain groups - one each for Project and Visio and configured access to those shortcuts accordingly. I now have users only accessing their assigned applications. Right?
Not quite. As I’ve shown in my previous FAQ, I can execute a different primary process rather than the one specified in the OSD file. So in this example, I can start Microsoft Word, but launch CMD.exe instead. I could then navigate to the Office installation folder and start any process including VISIO.EXE or MSPROJ.EXE. Additionally, I could insert a Visio diagram into a Word document, which would launch Visio.
One approach to restricting access would be to create separate packages and use Dynamic Suite Composition to combine the two environments on the client computer. However I now have two packages to create and update, increasing the size of the packages on disk and my network traffic when streaming those packages. As well as that I now have to maintain DSC links for multiple applications.
Delivering Office applications via separate packages would work, but it’s not without it’s drawbacks. Fortunately, there’s a simpler solution.
AppLocker is a feature of Windows 7 (Enterprise and Ultimate only) and Windows Server 2008 R2 (all editions) that allows you to whitelist or blacklist applications. By specifying PROJECT.EXE or VISIO.EXE as restricted to specified user groups (the same groups used when publishing the App-V shortcuts), I can control access to these applications even though users could attempt to launch them via means other than the delivered shortcuts. To implement AppLocker with App-V you need have deployed App-V 4.5 SP1 or above.
Tim Mangan has previously written an excellent article on the use of AppLocker with App-V, so I won’t repeat the technical details here. If you are new to AppLocker or even App-V, read Tim’s article.
Software Restriction Policies, the predecessor to AppLocker, is available for earlier versions of Windows and also works with App-V, but is not as flexible as AppLocker.
3rd Party Alternatives
If you aren’t deploying Windows 7 or Windows Server 2008 R2 there are 3rd party application white-list solutions that work with App-V – many organisations may already have these products in their environments. The most common of these will be AppSense Application Manager and RES PowerFuse.