App & Profile Containers: FSLogix's new features are the features to beat in Application Management

As hot as the Application Management space has been this year, I thought it would be a good idea to take closer looks at the products that are in this space.

As hot as the Application Management space has been this year, I thought it would be a good idea to take closer looks at the products that are in this space. So far this year, we’ve added two new products to the list of application management solutions (which we’re limiting to the “new breed” of application management): Ceedo and CloudHouse, bringing our list to:

  • Ceedo
  • CloudHouse
  • FSLogix
  • Liquidware Labs
  • Numecent
  • Spoon
  • Unidesk
  • VMware AppVolumes

That, of course, is not meant to discount App-V and ThinApp and anything else you might be using, but these platforms are intended to take advantage of the fact that the reasons we’re packing and deploying applications today is different than they were a decade ago. As with any of these modern application management tools, there is bound to be some overlap in an organization. You may have the majority of your applications sequenced in App-V, for example, and if you do that’s great. Some of them were probably easy, and for others it was probably agonizing work. Odds are you’re left with other apps that you have to install some other way, like via SCCM or directly into the base image. That’s where these other tools come in.

The first stop on the tour is FSLogix. When we last checked in with them, they were addressing the challenge of application management by building a base image with all of your applications in it, then hiding from Windows all but the applications you want your users to see. Because Windows doesn’t know that the apps are there, you can use FSLogix as a licensing management tool. It also means that you don’t have to go through the exercise of setting complex permissions, for example giving one group of users access to the Acrobat Pro .exe file while explicitly denying access to the rest of the users that entitled to Adobe Reader.

The brains behind the mix is FSLogix’s File System Filter Driver, which is managed by a set of rules that you configure via the FSLogix Apps RuleEditor. The workflow is something like this:

  1. Start with a base OS image and install applications
  2. Use the RuleEditor to scan each application on the machine in order to create rules. The scanner has tricks for sussing out exactly what components in the filesystem and registry belong to it, and will automatically build rule sets for each app. The easiest way to think about this is to picture the scanner going through the uninstaller, looking for what it’s supposed to remove. There’s more to it than that, but that’s the foundation of the process.
  3. After your image has been fully discovered, you can deploy the image to your users and allow/disallow applications based on tweaking these rules. Within the RulesEditor app, you can provision or deprovision access to apps based on users, groups, network locations, machines, or AD container.

Don't worry, they've got plans to update the interface

There is a lot to like about this solution. Because FSLogix is working at the filesystem level, it can be used to create additional rules for things like printer drivers, file type associations, or even which items are in the context menus. Sure, you can do this in other ways, but this allows you to bundle all of that along with a specific application. Does the Barcode Reader Application need to be able to open .BCR files and print to a label printer? Great, bundle them together! 

They can also hide, specify, or redirect components of an application to isolate them from other applications, which mimics App-V’s isolation capabilities. With FSLogix, even managing fonts is simple, because you simply hide them from Windows altogether.

The biggest knock on FSLogix (besides the management interface, but we’ll get to that) is that installing all of your apps into the base image makes for one hell of a big base image. Explaining FSLogix to people usually elicits one of two responses:

  1. Facepalm at the absurd simplicity of the entire concept
  2. Faceslap for suggesting that they create huge base images

Number 1 makes for an easy sell. Number 2, on the other hand, requires a technical solution. In any storage-constrained situation it’s easy to see why having a huge base image would be a show stopper. Since laptop and desktop drives are pretty large these days, we run into that more with VDI today than in any other situation, but it’s not impossible to have an issue with typically smaller SSD drives on physical desktops and laptops, too. To solve this problem, FSLogix create App Containers, which is similar to what AppVolumes is doing but different enough that it’s worth explaining.

App Containers themselves are not standalone application packages, rather, they’re carved out of the base image after it has been created and scanned. To create them, you first create your entire base image, scan all the apps, and then kick off a routine that moves the apps you specify off to their own VHD files. Today that process is only moving the filesystem components, though moving everything to a VHD is in the roadmap.

Then, to deploy an app from a VHD, you create a new rule in the RulesEditor that attaches the VHD file from a network location. There are some unique things about their approach that are worth getting in to. First, the VHD attachment happens in the guest OS, so you’re not relying on a hypervisor to do the attaching. It works on physical or virtual, and you’re not subject to any hypervisor limitations on the number of virtual disks you can mount. 

Second, and this is probably the coolest thing FSLogix has going for them right now, is that they can use this App Container functionality on something that they call Profile Containers. The way FSLogix interacts with the VHD means that you only have to open up one SMB connection to the VHD, rather than mounting it as a sort of network drive that introduces all sorts of SMB traffic. By creating a VHD for each user’s profile with FSLogix’s Profile Migration Utility, your users can take advantage of things that they haven’t been able to use in years.

For example, there’s an ongoing debate (well, not actually a debate since everyone agrees) that Folder Redirection sucks. Helge Klein calls it a “mini denial of service attack” because every time a client interacts with a redirected file there’s a ton of SMB traffic as a file is opened, read, and closed. By using FSLogix’s Profile Containers and placing all the user profiles into their own VHDs, there is only one SMB connection to the VHD, and all other network traffic is just packets going through a single SMB connection. Because of that you can also have huge files, like Outlook OST files and Windows Search!

The biggest critique I have right now for FSLogix is that their management interface leaves something to be desired. When I want to show or hide an application, I don’t want or need to see all the components involved. I’d rather just have a checkbox for showing or hiding an app, with an option for an advanced mode that gets down to the nitty-gritty. They are very aware of this, and the near-term roadmap has some enhancements to make administration much more friendly on the eyes.

The fact that FSLogix works inside the guest OS or on physical machines leaves the door wide open for any number of use cases that stretch beyond TS or VDI. I can even picture using it with Jentu (which, as Brian wrote, is like Ardence before Citrix got their hands on it) to deliver nonpersistent streamed OS images to physical desktops while still centrally controlling the applications and enabling some type of persistence. 

I’ll get a closer look at the other products in this space in the coming weeks/months. I think 2015 might come to be dubbed “The Year of Application Management." 

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Is application management really that big of an issue for people? Why not just install apps on your VM's like you install them on your laptops? You probably have a deployment solution in place for laptops that will work just as well for VDI. If you put a hardware level dedupe  storage array beneath VDI I don't see any reason at all to try to come up with some new way to deploy windows + apps. just deploy a persistent VM, install apps with whatever tool you already have, and be done. all these virtualized filter driver layer bubble container shenanigans are unnecessary.

We've tried out multiple different app management solutions over the past 4 years, all of which seemed really brilliant and clever and easy. but every single one of them has turned out to have major flaws (compatibility issues, major bugs, dependencies that weren't obvious even in testing, etc) once we actually put them into production. Turns out we didn't need them anyways since actually installing apps into windows using .MSI's/.EXE's is a tried and true method that is incredibly easy to do. It's only when we forced complexity, registry trickery, disk attachment shenanigans, etc, on ourselves that we felt the pain of the application management space.


I am the CEO of FSLogix. I tried to post this over the weekend. (Thanks, Gabe for the tech support)

Even though I am on the non-persistent side of this persistent vs. non-persistent debate, I don’t believe one should convert a working persistent implementation to a non-persistent one just for the sake of switching. However, the customers we talk to rarely tell us that their non-persistent implementations are working flawlessly.

For example, I agree with that installing applications natively via .MSIs or .EXEs — that is how you install / update applications when using FSLogix. It is a tried and true method (while there are some of us that may disagree that it is an easy thing to do) I’m sure most of us would agree that it is a lot easier than sequencing or packaging a virtualized application.

The one place where many seem to disagree is when to do these updates / installs.

Let’s say that the you have 800 users. That means 800 .MSIs installing across the network for each Windows update and 800 times the number of applications for each application update or install. (Or 8,000 or 80,000 depending on your org size) While in the ideal organization, the users’ desktops are probably always on and always receive updates flawlessly, this is what I have heard or seen happens in the field:

1. Patch management, software distribution and operating system deployment is labor intensive and complicated to troubleshoot:

Sometimes the Client gets the application updates but not software updates (or vice versa)

“Almost” all of the clients receive deployed software updates. (Tracking down those that didn’t and finding out why is time consuming)

The client log indicates that patches are required but deployment tool doesn’t think updates are necessary

Or, the opposite in which the client log thinks that patches are not required but the deployment report indicates that updates are required.

And the general PITA of the patch/update failed to install.

2. Patch management, software distribution and operating system deployment is expensive

SCCM generates $1B worth of revenue for Microsoft each year ( licensed by CALs). Throw in Tivoli Endpoint Manager and Symantec and you start talking real money. Money that could be better spent on upgrading storage for inline deduplication.

Persistent VDI is also limiting. In their 2014 Briforum presentation,  â€œVDI High Availability and Why Persistent Desktops Are the Devil", Dan Allen and Nick Rintalin discuss many of the limitations of persistent desktops. Nick works for Citrix and Dan worked for Citrix at the time of the video so maybe they are biased towards virtual deskops over physical desktops, but in the non-persistent vs. persistent they make excellent points including the fact that high availability is difficult with persistent VDI. To quote Dan, “With persistent VDI, you are locking a user to a single VM, on a single LUN, on a single SAN, attached to a single VLAN, hosted on a single hypervisor cluster, on a single hypervisor platform, in a single data center, hosted in a single VDI brokering system.  If anything goes wrong with any component in the stack, the user cannot access their VM.“