This blog is really about what I thought I knew about layering products and how much I simply didn’t know. I’ve been working with layering for about as long as anyone and I made the mistake of thinking that all layering products were essentially the same. Sure they each did things a little differently but in the end the concepts were the same and their abilities were, for all intents and purposes, the same. Boy was I wrong.
Over the seven years I’ve worked with layering I’ve had many customers and prospects ask about certain features. When are they coming? Are they even on the roadmap? I’ve got a feature request I’d like you to add. I’ve heard a lot of requests over the years but here were always some that truly stood out. I never really thought they would be coming to fruition though. Again, boy was I wrong.
When I started at Liquidware, I saw those requests had actually been developed and were in the FlexApp product. To be honest, I was stunned. I had no idea that FlexApp could do any of this. I made the mistaken assumption (bad! bad Jeff) that layering products were essentially the same and had the same strengths and weaknesses.
These are the nine big features that I’ve seen requested many, many times and, in this case, I’m so glad I was wrong. These nine are in no particular order but are split amongst three categories. Enjoy!
The first thing I would like to discuss is packaging, editing and upgrading a layer. Packaging is extremely easy, and many people will be familiar with the process. Create a virtual machine to be used for packaging and snapshot it. When you are done packaging the application you snap it back and go on to your next application. Very clean, very easy and applications can literally be installed, configured and ready for deployment in minutes. The question is, how does FlexApp packaging differ from other solutions. Let’s dive in.
1) Edit a layer
As I said above, capturing an application is easy but what happens if you missed something or want to add something? You can edit a layer if it is not assigned in the Profile Unity Console. When you edit a layer, you are directly editing the VHD that you created. The great thing is that you get a view of the layer graphically that is a mix of file explorer and regedit. You can easily see what files, folders, registry entries, services and shortcuts were created. And what’s that? Printers and print drivers??!! We’ll l jump into that in a bit.
2) Clone, upgrade or fork a layer
Have you ever created a layer, got it working perfectly, and then discover that another group uses the same application but requires it to be pointed at another database? Or there is something significantly different about the configuration that would require a new layer of the same app to be created to handle those differences? What about you simply want to clone the layer, so you can test upgrades against it? What if you weren’t tied to a layer chain?
FlexApp allows an administrator to clone a layer and do with that clone what you want. When you upgrade an application, you can clone the original layer, upgrade it, test it and then deploy. You could also delete it, clone it again and redo the testing until it works correctly. Do you have the same app but different configurations for different sets of users? Clone the original, edit it and deploy to the correct users.
3) Import a layer
Many organizations have, or should have, a dev/test/prod type of environment. This allows for thorough testing before something is pushed into production. A problem with other products is that they don’t allow for this very easily. FlexApp allows you to take a FlexApp layer from one environment and import it into another. You don’t have to do anything special. Just point to where the layer resides or copy it somewhere else or whatever so that the FlexApp Packaging Console can see it and import it.
Another use case that is very popular is the ability to create a package offline and import it later. For instance, I have VMware workstation on my laptop. I can fire up a packaging machine, package the application, edit it and save it. Then later I could copy it to a thumb drive or if I’m attached to a network later, copy it up to a share and then use the FPC in the existing environment and import it. I could take the app and deliver to any other FPC. There is nothing in the package itself that ties it to the original environment.
4) Print Drivers
In the picture above, you saw that there were two sections in the FPC edit window: Printers and Print Drivers. FlexApp can not only capture print drivers (most layering systems can) BUT it can also capture the printer that is created AND deliver it as a layer. Let that sink in for a moment. The driver or printer doesn’t need to be part of the image or part of a layer that is used directly at boot. When a user logs in, the layer is attached and then the driver and printer are there for the user. This is true of click-to-layer as well (more on click-to-layer in Assignment below).
You have a package ready and waiting for users to access it. Now what? You need to assign it properly for users to access it. Typically, this is done one of two ways: Active Directory User/Group or machine based. FlexApp, in conjunction with the ProfileUnity Console, can do those as well but with so much more control. It also has options no other layering product has.
If an application can only be assigned by user or group, what happens if they log into a desktop and Remote Desktop Session Host server? They get the app in both places. What if the app doesn’t run properly on RDSH and the user tries to run it? You could assign the app to the desktop but then everybody who logs into the desktop gets the app. That’s not desirable either.
FlexApps are assigned using the ProfileUnity Console. There you can create your filters and use them to assign the FlexApps appropriately. The first image is defaults when you create your own filter.
That’s pretty powerful by itself. Is it a desktop? Is it a terminal server? What version of Windows and more. That’s just the tip of the iceberg though. It’s the middle portion, the Conditions, that make filters so powerful. The image below shows all the conditions you can use.
The key with filters is that you can combine them. If you want a specific user group coming in through ICA (but not from home) to only have access to a FlexApp on a Tuesday, you can do that!
These filters are truly powerful.
6) Cross OS Layers
Being able to assign layers across multiple operating systems has been requested for years. If Firefox or any other application can run on Windows 7 and Windows 10, why do I need to create two different layers for it? With FlexApp, you don’t. As you can see in the images above, a portion of the filter creation dialog box is you can specify what operating systems you want the app to be deployed too. Saying that, if a Windows 7 app doesn’t run on Windows 10, we can’t help with that. The laws of Windows still apply. This feature cuts down on the number layers, the time to manage those layers, and potentially the number of images required.
7) Assign to user, machine boot and click-to-layer
As you saw above in the filtering section, you have a lot of flexibility in who can see and use a layer. This really could be a sub-heading under that section but a few things I want to call out. First, FlexApps can do session isolation in RDSH. Two users log into a server, user A has access to a FlexApp and user B does not. User A would be able to access and use the application, user B would not even though they are on the same RDSH. Second, an admin can specify that certain layers are mounted at boot. This is different than filtering on desktops. This is attaching a FlexApp very early in the boot process and allowing it to use apps that may require boot time services and other things. This is not to say that all applications, like Anti-virus, could be done this way but many apps can be. Testing your apps for compatibility with this will be important.
Third is click-to-layer, applications on-demand. Click-to-layer is specified when you assign the application in the ProfileUnity Console. It’s a per layer check box. With this option, the layer is not attached at boot or at user login. The user gets an icon on their desktop and when they double click the icon, then the layer is attached. Admins can also use click-to-layer in a published application scenario.
In the end, it doesn’t matter how easy it is to capture an application or how we can decide if and when a user received an application. If the user is unhappy or can’t work productively, then, whether it’s layering or any other technology, IT has not only failed the user but their company as well. How does FlexApp help in this regard? Read on.
8) Micro-Isolation (or I don’t want to have to deal with Layer Priority)
One of the biggest headaches in traditional layering has been conflicts especially between .dll’s or other files. This has led to the concept of layer priority. With layer priority, layers are applied to a machine in a specific order so the last layer applied wins. For instance, if layer A and layer B have a file called test.dll in the exact same directory, which test.dll will be used? If layer A has a higher priority than layer B, then the test.dll in layer A will be used. What if layer B has an updated test.dll that can be used by layer A and layer B but the test.dll in layer A will not work with layer B? Typically, you can then go in an change the priority of the layers so that layer B will be applied after layer A and then the correct test.dll will be used out of layer B. Whew…..and the worst part? There is no easy visibility into the layers to even see what might be causing a conflict. The testing methodology is a long process as well.
FlexApp, on the other hand, offers a feature that does away with the need for layer priority. It’s called Micro-isolation. This is a technology that if there are conflicts like the example above, instead of using priority to determine which one of the two test.dll’s will be used, it will redirect the call back to the originating layer. In other words, layer A will use test.dll in layer A and Layer B will use test.dll in Layer B. A side effect of this is that logins are much faster because FlexApp doesn’t have to attach a layer at a time to honor layer priority. Multiple layers can be attached at the same time.
9) Layering to Physical
This is quite simple. Companies want a solution for both physical and virtual. FlexApp allows for this. You can assign a layer to physical and virtual machines. At this point in time, I am unaware of any other layering technology that allows for this. The small caveat is that the physical machine should be well-managed, meaning someone has not made a mess of it by installing and uninstalling tons of regular apps.
So that’s the nine right there. There are other features that have been requested as well but I only have so much space and these are the big ones. If you agree or disagree, let me know. I look forward to the discussion!