There’s been a lot of buzz recently about FSLogix, who are a company making a few disruptive waves in the virtualization world with their core products. The beauty I see in FSLogix is that it is very much a simple product – almost reverse app layering, to coin a phrase. It delivers user entitlements to applications based around using a filesystem driver to “reveal” the applications as necessary, rather than delivering them on-demand through app virtualization or layering tech such as App-V, AppVolumes, and the like. In a world where complex solutions are often king, I find FSLogix is a breath of fresh air for businesses that don’t have the budget, the skills or the resources to invest in “Rolls-Royce” infrastructure. This is not to say complex solutions don’t have their place – very, very far from it! – but they’re not the only way to get things done. And FSLogix’s products are not just aimed at SMEs either – simplicity can be just as elegant at scale.
But rather than dive straight into FSLogix’s core product, FSLogix Apps, for this first instalment we will take a look at a part of their portfolio that solves a common operational problem just about everyone can identify with – the management of legacy Java apps and multiple Java versions. Don’t you all just hate Java? The world would be a better place without it. I can recall many, many instances where I’ve had to shoehorn legacy Java versions into application silos, App-V packages and base images. In fact, for a long time I’ve been keen to try and manage it through AppSense Application Manager, and I’m pretty sure it can be done in this way (I am getting around to testing this – I promise!) However, if you’re not an AppSense customer and want to manage Java versions (or you just don’t have the patience to wait for someone like me to test it), FSLogix is a wonderfully simple way of achieving Java management heaven.
Let’s take a Windows 7 image and install a couple of Java versions onto it firstly.
In this state, our machine has a later Java version installed (8.31) but is still vulnerable to the security exploits available through the legacy version on the machine (7.71). The idea is that FSLogix will “cloak” (i.e. hide from the operating system) the legacy version unless a program or URL is visited that specifically requires it, massively limiting the exposure to drive-by attacks. So without further ado, let’s install FSLogix Apps and the FSLogix Java Rule Editor.
Now that they’re installed, let’s pick some Java test sites that we can use to demonstrate what happens. We are going to use the standard “Verify Java” detection page from java.com in the first instance, because that detects all versions of Java on the machine and will show us how this software hides the legacy versions until they’re called.For the old version, we will use http://www.javatester.org/version.html, so that we can see it uses the older version and can’t detect the newer one – showing that good ‘ol FSLogix is doing exactly what it says on the tin.
Firing up the FSLogix Java Rules Editor allows us to select the URL (or process, for that matter) and associate a Java version with it. The interface in this version is very simple, to say the least, but I’m a fan of substance over style any day of the week. Interfaces improve easily…poor functionality is harder to make better.
Next, we will add the second URL in that we mentioned above, and associate the old Java version.
Finally, we need to deploy this – in so much as there is any deployment to speak of. You save the rules, then generate some deployment files, and then copy them into %PROGRAMFILES%\FSLogix\Apps\Rules, from where they are compiled and enabled. Once they’re in there, the service automatically brings them into usage – no mess, no fuss! This sort of deployment could easily be automated from a central location or locations using Group Policy Preferences, AppSense, RES, many other bits of software, even a bit of PowerShell or batch. That’s part of the appeal – it sits easily in with other enterprise deployment tools, or can easily be handled by an admin.
So, let’s see it in action! Firstly, let’s go to the Java.com version tester. Anyone familiar with this knows it detects all versions installed on the desktop. So what happens when we go here?
That looks very good…it is only detecting the 8.31 version, and even though it’s recommending the newest version, it doesn’t know about 7.71 at all. That’s because FSLogix has hidden it from the OS completely. Don’t believe me? Let’s empty the Compiled Rules folder in the FSLogix program data (essentially resetting it to default settings), and then revisit the same page…
Cool! We know now that FSLogix was hiding the legacy, vulnerable Java version, and now we’ve turned it off, it’s there for all to see and exploit.
So, re-enabling our FSLogix rules, let’s now visit the javatester.org URL, where the old version is allowed out of the woodwork…
…and then let’s turn FSLogix off again, just to see what this page shows normally when there are two versions installed…
…and it’s exactly as expected. Now that FSLogix isn’t hiding the newer version to allow compatibility, the page has gone back to the later version. Hiding the newer version allows sites and applications that are incompatible with newer versions to continue operating without incurring a massive security risk to your org. Pretty cool stuff!
The Java bit is almost an aside to what FSLogix Apps really does – really it is concerned with application delivery and management from a single image with apps installed. But we will have more on that in the second and third parts. They also have features that can now deliver apps from the network and handle user profile management – but we will come to that in future articles.
The reason I started with the Java version control and management is that this is a real-world problem that just about everyone has come across and has pain with. Think of all the effort and infrastructure that goes into maintaining legacy Java-based apps that the vendors can’t or won’t update to the latest versions – and then replace it with a simple solution like this. I think it is very interesting.
You do have to fiddle with a lot of Java settings sometimes to get things to work (deployment.config files, security lists, etc.), but it’s a hell of a lot better than the alternatives in my opinion. There’s also the fact that the interface is still very simplistic, but that can easily be improved. All in all, FSLogix has some interesting features that make it something we should all be aware of, and the Java management is just the tip of the iceberg – more to come!
If you’ve got any questions about FSLogix, my company HTG is an FSLogix partner – get in touch and we can help!
Share
