FSLogix is a company started by Kevin Goodman and Randy Cook that, until now, has been operating in stealth mode. This week at BriForum, though, they are unveiling their new product that simplifies application management with a drastically simple approach. The solution? Just install all the apps, then control access and visibility via policy. After first being briefed on the product, I suggested they name it "FSLogix FacePalm," since that's what I felt like doing when I heard how simple it was to manage the applications. They have settled on the name "Apps," which does a good job of mimicking the simplicity of their approach, but I have a feeling the FSLogix name is what will catch on. After all, it sounds like the name LufLogix, except, you know, it's real.
(They have a logo and everything!)
Managing applications on laptops, desktops, virtual machines, and terminal servers is a challenge, and while application virtualization solves the problem for many of an organizations applications, there are usually a high percentage of apps that still need to baked into the base image. Apps is designed to address the application management issues of large organizations that can't virtualize all of their applications and still need a way to manage base image apps across multiple form factors. To use apps, you simply install all the applications into your image, then use the Apps product deploy a set of rules that govern who has access to what applications.
Essentially, every time a user logs in, a list of application entitlements is interpreted by FSLogix Apps, and only those applications to which the users has access are made available to them. It's as if the other applications don't exist. It does this without using any virtualization or application-level isolation, which means that it works on any Windows system on any form factor. It's so hands-off, in fact, that it also works with virtualized applications.
Got your attention? Good! The best way to dig into this is to follow the implementation process.
When you first install FSLogix, you can start with a blank machine or on a machine with your base image already applied. From there, you can determine which applications are going to managed by FSLogix and create rule sets for them. A rule set, or "Visibility Rule," is basically a config file, the presence of which on a desktop implies the user has the rights to use that application. Inside a config file are settings that should be implemented when the application is enabled. This includes things like file type associations and where shortcut icons are placed, but can also be more complex. To create a rule set, you can use an auto-generation tool included with the FSLogix package, or you can download rule sets that have been contributed to the FSLogix website by the community.
After the rule sets have been created, you simply need to install the FSLogix software on to the desktops. The package amounts to a File System Filter Driver and a Windows service. Deployment of the rule sets is done as a simple file transfer that can be accomplished in just about any way, such as login scripts or group policies, or even third party tools. When rule files are transferred to the appropriate folder on the desktop, the service compiles them and applies them to the desktop. In doing so, it provides access to the proper applications, sets their visibility, and refreshes the desktop to reveal the application icon, all the while leaving the other applications hidden from the OS. Applications that aren't allowed are not visible to anything on the system, not even Windows.
Because there is a service governing this, applications can be provisioned/de-provisioned on the fly. Any time a change is made to the folder that holds the rules, the service will kick in and apply the changes. There is no need to reboot, log off, or anything else. The only isolation happening with this solution is with registry entries and file locations, since apps that don't exist are effectively uninstalled. Registry entries for managed applications that exist for one user do not necessarily exist for another, no matter where they live in the registry. There is even a feature to redirect file access from, say, a poorly-placed INI file that lives in Program Files and is written to every time a user access it. In an RDSH environment, this would be troublesome, but with FSLogix Apps, requests to access that file are redirected to a user-specific file without Windows being aware of it, and the application continues on its merry way.
The benefits of a solution like this, besides only maintaining a single image, come in the form of flexibility. Since this works on any form factor, and each user is different, it's an ideal solution for Terminal Servers that previously had to be placed in applications silos. This won't help you run IE6 on a Windows 7 system (you'll still need application virtualization for that), but it will help you run different versions of Java on the same Terminal Server. The fact that this works with application virtualization platforms as well means that you could wind up with a single application management platform. You could, for instance, deploy all your virtualized applications to all your users, too, then use FSLogix rule sets to control access to them.
Since there is no hypervisor involved, this also works on client VMs and, more importantly, VDI VMs, too. That means one image for all your VDI desktops. Of course, the biggest benefit that stems from no virtualization is that the applications execute natively, and the only voodoo that takes place is with filtered file system and registry calls. Even those, though, happen in real time, it's just that the requests are dealt with somewhere else.
There are a few challenges with this solution that I can see people talking about almost instantly. The first will be the fact that you have to maintain the application install base on all the machines. Assuming there is already an application deployment solution in place to address apps in the base image, this isn't a real problem. And, considering this allows you to use just one base image across the entire organization, the disadvantage of updating every machine every time there is an update might be erased. Plus, haven't you always wanted a reason to make sure all your apps are up to date on every machine? :)
The second is that the size of the image is going to be larger than normal. This might also be true, but in this day and age of huge hard drives, optimized storage, and fast networks, is that really such a problem? We're not copying the apps over the wire every time they're used…they already live on the system, installed but hidden. The biggest impact, then, is going to be on base image size, but I can't imagine we're talking more than a handful of gigabytes difference. That could be a problem with VDI or anything provisioned on the fly, but when you consider this as part of the overall solution, it's easy enough to plan for without adding much in the way of infrastructure or new technology.
FSLogix has generated a lot of interest from a group of customers who are using this in beta. The product, which will remain in beta for the time being, will be on display at the FSLogix booth at BriForum this week, and I'm very excited to take a look at it in person. Kevin and Randy are both very personable and, above all else, technical, so it will be fun to stand back and listen as they get grilled by all the attendees. They also have a session during the show, the video of which we'll put up shortly after it's filmed. In the meantime, let us know what you think...
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.