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:
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
- Liquidware Labs
- 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:
- Start with a base OS image and install applications
- 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.
- 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.
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:
- Facepalm at the absurd simplicity of the entire concept
- 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."