I was chatting with a customer the other day about FlexApp and they told me that “it’s a different kind of layering and I like it” – it’s not the first time I’ve heard that. This got me thinking ‘why are FlexApp customers having an all-around better experience when compared to other layering technologies. When I look at public forums like Twitter, user groups, forums, etc the overwhelming opinion appears to be that all layering products are essentially the same and if an application won’t work in one, it won’t work in any others. I feel your pain and I just want you to know “Not all layering products are the same.” While Citrix App Layering (CAL), VMware App Volumes and FlexApp share the “layering” moniker, FlexApp couldn’t be more different from the competition (see 9 things that FlexApp does that no one else can or does). It’s these differences that allow us to package applications that others cannot, deliver those FlexApps to the appropriate end point or user and do this in an extremely efficient manner very, very quickly.

Before we go any further, I want to point out a difference that, in my opinion, is huge for large to enterprise customers and really showcases that FlexApp is different than the others in a very meaningful way. FlexApps can be used with Citrix Provisioning with no detrimental effect on the size of the write cache. Let that sink in for a moment. This is not possible with Citrix App Layering. You can use elastic layers with Citrix Provisioning, yes, BUT you will need to expand your write caches by a factor of two or even three and possibly more depending on the current size of your write cache. One of the beauties of Citrix Provisioning is that it takes up so much less storage than other provisioning mechanisms.

I will explore the Citrix App Layering vs FlexApp on Citrix Provisioning in my next blog so stay tuned!

Architecture

I’ve talked about the differences in architecture before in this blog. As you can see, architecturally, FlexApp is night and day different than Citrix App Layering and VMware App Volumes. FlexApp isn’t layering on TOP of the image, it is layering INTO the image and the image is sacrosanct. FlexApp will not overwrite anything in the image like the other layering technologies do. This is critical as the other techs could potentially “overwrite” critical files and cause issues when the layer is attached.

I love the analogy of puzzle pieces when trying to visualize how FlexApp works. The analogy is extraordinarily accurate. When a FlexApp is attached, it’s snapped into the image. There is no overlap of the FlexApp with the image. When it comes time to remove the application, it’s simply unsnapped from the image. There is no remnant left behind at all.

Another distinction between FlexApp and the rest, based on the layer on top vs into, is that mounting multiple FlexApps will be faster than mounting multiple layers from a system using the layer stacks. FlexApp will simultaneously mount the layers being delivered to the end user. The layer stack method requires each layer to finish before it can continue to the next. This is what layer priority is for and why FlexApp does not require a priority system.

Packaging

Packaging an application in FlexApp is very simple and very powerful. Creating a FlexApp package is very similar to the traditional packaging paradigm. A clean operating system, preferably a virtual machine for ease of rollback, with common prerequisites installed (visual C++ runtimes, .NET runtimes, etc) and the FlexApp Packaging Console (FPC) is all that’s needed. The packaging machine can be part of the domain or not. In fact, it can be on the network or not.

The FPC gives you the flexibility to package an application almost anywhere. You can have your standard packaging machines in your own datacenter or you could package an application at 35,000 feet and import it into your environment later! The FPC is designed to be able to package an application with no connection to the ProfileUnity server. If you are a consultant, you could create a package (Let’s say Chrome) and deliver that ONE package to multiple diverse clients. That is how clean the packages are but how is that done?

The first thing you’ll see when using the FPC is that you must say “start capture” and “end capture”. This alone limits the amount of noise that is captured. But how can you tell how much noise was captured or even if the application was captured correctly? Traditionally, layering vendors don’t really give you any insight into that. You could mount the VHD and trawl through the filesystem manually and mount the registry files to see that as well but that isn’t particularly easy to do and could potentially corrupt the VHD.

The FPC has a package explorer which is essentially a file explorer/regedit view of everything that was captured. You can easily see everything that was captured in one view and add, modify or delete as necessary. What if you notice that you forgot to install something or make other changes that would be easier if you were still capturing? The FPC has that covered as well. You can ‘extend’ the current package and make those changes. There is no having to add versions to make those changes.

And last, but most definitely not least, did I mention how fast it is to package an application and get it deployed? Obviously depending on the application and needed configuration, it only takes a few minutes. It is on par with traditional packaging.

Cross OS

FlexApps are not limited to the OS or image they were created on as I’m sure you understood from the above. We do not break the laws of Windows which means no 16-bit applications on a 64-bit operating system, we don’t fix compatibility (Windows 7 application that only runs on Windows 7, we can’t make it run on Windows 10) amongst other things, as always, test test test!

FlexApp Mount: Machine, User, Click-to-Layer

This is where things start getting interesting. FlexApp currently has three ways of specifying when a FlexApp is mounted. Machine, User and Click-to-Layer.

The way FlexApp does machine based mount is unique to FlexApp as far as I can tell. Not only can you assign FlexApps to an endpoint but it also mounts the FlexApp during boot. Why is this important? There is a resource hit when mounting layers or anytime you are adding something dynamic to a machine or user environment. This hit can be alleviated for the end user by having the FlexApp mounted at boot instead of at user login. When a user logs in, the app is already there and waiting.

User based mounting, along with filtering talked about below, is the quintessential layering assignment. When a user logs in, the FlexApps are mounted delivering applications that the user requires but are not part of the image.

Click-to-Layer based mounting is definitely unique to FlexApp. This method delivers an icon on the desktop for the user but the FlexApp is not mounted yet. When the user clicks the icon to open the application THEN it is mounted. This is great for those applications that aren’t used very often but need to be there when they are required.

Click-to-Layer also allows for publishing a FlexApp whether it’s RDSH, XenApp or some other mechanism. There is an executable called JitCut.exe that is run with an argument for which application should be mounted. Very simple.

Assigning a FlexApp: Filtering

FlexApp filtering is second to none. It uses the ProfileUnity filter engine which allows you to create as simple or as complex of a filter as you need. Do you want to use Active Directory groups? Yup. Do you want to use AD groups plus restrict the FlexApps to virtual desktops and not RDSH? Yup. Do you want to use AD groups, restrict to virtual desktops and only allow the FlexApp when the user is coming in from your internal network? YES! Time of day? Day of week? Yes and Yes!

Extraordinarily powerful and flexible!

Cloud

Cloud is becoming more and more pervasive and desktops are starting to move in that direction as well. What if you want to deliver FlexApps to cloud desktops OR what if you have a requirement to deliver applications to remote users that aren’t on necessarily on your network? FlexApp allows you to store and run applications from object-based storage from Azure, AWS and GCP. In other words, NO EXTRA INFRASTRUCTURE NEEDED! For example, SMB Shares which would require a server.

Because FlexApp uses object-based storage, Windows cannot mount the VHD’s from there, so a solution had to be found and that’s what happened. FlexApps, when run from the cloud, are being cached on the endpoint through block-based caching. This allows features, again, that no other layering vendor has. The FlexApps are running from the cache and there is no lock on the VHD like that required when mounting directly from an SMB share. Caching is required when running from cloud storage but it can also be turned on for on-premises FlexApps. In fact, you can have some applications cached and others not. It’s turned on at a FlexApp layer level.

Resiliency and Failover

Caching has given FlexApp resiliency and failover capabilities as well. Now if there is a network blip or outage, there is a good chance the user may never notice. Unless FlexApp needs to get a new block, the application will continue to run (the blocks are local) unlike other vendors that would crash the application or worse blue screen the machine.

FlexApp also introduces a failover mechanism that runs in the background. The administrator sets up two locations where the FlexApps are located, specifies those locations in Group Policy or registry setting and if a location goes down, FlexApp will automatically get blocks from the other location. This is completely invisible to the end user! As well, FlexApp is monitoring network latency is if the primary location suddenly has higher latency than the secondary, FlexApp will automatically move to the secondary and then back again when the latency dies down.

Oh, and I should mention that the locations for the FlexApps can be on-premises to on-premises, on-premises to cloud and cloud to cloud. It’s entirely up you!

Physical

Yes, FlexApps can be delivered to physical desktops. Again, a unique feature of FlexApp.

Conclusion

Whew, thank you for going through this blog! I hope you have been able to learn some things about what makes FlexApp a better technology especially in regards to application compatibility. If you have any questions or comments, you always reach me on twitter @JeffPitsch or email at jeff.pitsch@liquidware.com. If you’d like face to face time, I will be at a lot of shows this year, user groups or we can always do Webex’s, calls and other forms of communication.