FSLogix comes out of stealth mode at BriForum with simple Windows application management solution.

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.

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... 

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

1. Congrats and kudos!

Was waiting for something from Kevin Goodman since the VMWare thingy... :)

2. "...but it will help you run different versions of Java on the same Terminal Server.."

Does it support running several versions of apps in general?



Congrats to Randy and you for yet another vision on  application management. Will take some time to digest this and understand the use case. Some first thoughts

- multiple users in need of multiple versions of applications (''simply'' installed on one base image) How do you address different versions of shared components?)

- 'just install all the apps on all machines''. You must have good license agreements with your vendors otherwise this might be an expensive approach.

- How do you 'run' different versions of apps on a TS without actually virtualizing them?

- what exactly is the best use case you had in mind when you designed this?



With regards to the multiple versions of applications, FSLogix Apps is targeted to applications where they natively support being installed together. For example, Office 2010 and Office 2013 are designed to behave this way, as are all the recent versions of Adobe Acrobat.

In the cases where the software has shared components, we can do runtime isolation to resolve those problems without virtualizing the entire application.

In cases where the software truly cannot coexist with another version of itself, this is a scenario that appvirt is designed specifically to handle, and should probably be used. FSLogix can coexist and interop with the appvirt solutions quite well. :)



Appears to be  an interesting take on silo reduction (something I'm very keen on), will be requesting an evaluation me thinks,

It would appear (from the videos) that it works in the reverse to what is stated above, in as much the presence of a file means the user can't see the application and if the file doesn't exist then they can.  

Are the rule files applied to each user in an area they can edit, as such can  they just delete the rule file and then run the application.

Or have I just got the wrong edge of the wedge?.

as an aside, can you turn up the mic on your future videos, I didn't realise there was sound until I max'd the volume on the videos (forgot to turn it off when I turned the music back on, ouch)



In addition to what Kevin mentioned, the location for the rules on the system is in a folder that is ACLed for Administrators only. So the individual users could NOT just edit the rule and gain access to the application, unless the Administrator decides to allow them access to those locations.



Would it be fair to say it is like Symantec/Altiris  Software Workspace Virtualization (not to be confused with Software Workspace Streaming) but with the added benefit of ACLs?

SWV allows you to deploy applications into virtual layers.  They are installed locally but administrators can control varying degrees of isolation.

If not similar, I'm curious what the significant differences are.