Liquidware Labs ProfileUnity Reviews

There a couple products on the market these days that offer application provisioning without installing the application in the image (excluding application virtualization). With many solutions it's the big guns getting all the attention and the rest is fighting for attention. The best solution isn't always the one top of the list. So its time to shed some light on this.

As a consultant customers ask me for guidance in products, to give guidance I need to compare products and as such I will compare two major players in the application provisioning field. The two players I'm talking about are:

• Liquidware Labs ProfileUnity with FlexApp v6.5
• VMware App Volumes v2.9

I wrote a blog series already on VMware App Volumes, how to install it and how to work with it (only did read-only AppStack - for a reason). If you want to read, here it is, it's the video of the working, the rest of the series is found the recent blog menu.

This blog will show you how ProfileUnity is handling this application provisioning. It won't show the installation but the working and the comparison of both products.

Application provisioning

First let's take a quick look at application provisioning, I want you to understand the concept behind it before we move on. What is the concept and what is it solving?

When you implement a virtual environment you must start with a Golden Image. In this Golden Image you install a base layer of applications, applications you can't/won't virtualize or applications that are so common you deploy them in the image.

When your organization has the same requirement for all departments you have one Golden Image with those common applications installed. This sounds good in theory but in the real-world, those organizations don't exist, there is always at least one department that requre different or more applications.

For every department that has a different requirement in the base software layer you need a different Golden Image. When many departments have different requirements, the number of Golden Images go up. Of course, this does not add ease of management to your environment.

Application layering, the product category for FlexApp and App Volumes, offers the ability to stay with one Golden Image and fill in the different requirements with assigning application layers to desktops on demand.

With this background in mind, it's time to take a look at both products and how they compare.

As previously mentioned, I did a blog on App Volumes already so the biggest attention will be on ProfileUnity and FlexApp, after that I’ll compare them and most details about App Volumes will be discussed there.

ProfileUnity

Liquidware Labs has been offering UEM for many many years, enabling customers to be smarter with managing the user environment. It is not possible to test one without the other, they are integrated like a marriage. So a quick look at ProfileUnity first, what is a user environment and how is that handled with ProfileUnity.

The user environment is:

• User settings they want to be saved and use another time
• User mandatory settings you want to be there
• Drive mappings
• Printer mappings
• E-mail settings
• User installed applications
• Department installed applications
• Application Rights Management with Privelege Elevation and Application Restrictions
• and so forth and so forth...

Below is a quick look a the configuration (default 2012R2 RDSH config) from the management console. If we compare this to VMware UEM (that could be another blog altogether) you notice they have Outlook configuration option that VMware UEM hasn't. Most of this blog will focus on the App Layering that both companies have in common.

The biggest pro that ProfileUnity has over many other products is that it's lacks the requirement of additional infrastructure. There is no database for user settings, no server infrastructure needed, all you need is a network share (Netlogon by default) and group policies working and a management server for the console.

Another difference with ProfileUnity is that it runs with Admin privileges and therefore is also able to implement HKLM keys, something that most UEM products lack as they run in user context.

ProfileUnity is easy to setup, wizard driven, fast and ready in a few minutes. I tried to install all components on one server with limited resources and that kinda failed. That server was a 1CPU/2GB server for my lab was stretched already. ProfileUnity would run fine on that but invoking FlexApp features was a bit to much for that server. I re-installed on another server with better specs and things ran fine... (That's what happens when you have multiple test running in a lab at once :)

That's enough on ProfileUnity functionality for now, I guess a separate blog comparing them with VMware UEM is bound to appear here soon... before VMworld.

FlexApp

FlexApp features are an included part of ProfileUnity and here I compare it with App Volumes to take a look at delivering application to departments or groups. ProfileUnity calls this FlexApp DIA (Departmental Installed Applications). There two options for delivery, VHD or VMDK through vCenter. Both delivery methods are able to run next to each other, so you don't have to make a selection for either one but can deliver to your users depending on their needs. Another option FlexApp offers is instant connection in session just like App Volumes does

In the management console of ProfileUnity you have two options, UIA (User Installed Applications) and DIA. We will focus today on the DIA, applications delivered to departments controlled by you. App Volumes calls these an AppStack while ProfileUnity’s FlexApp refers to them as DIA VHDs or VMDK “FlexDisks.”

To clarify:

FlexApp: Departmental Installed applications = App Volumes: AppStack
FlexApp: User installed applications = App Volumes: Writeable volume for User Installed Applications

This first blog will handle the departmental installed applications for that is the one that has the most use cases I think. User installed applications is something only for education and scenario's like that. There are so many caveats there that would mess up the working of other applications when you allow users to just install everything, I won’t cover that for now.

So how do you capture an application with FlexApp?
On the reference machine, the machine where you install the applications in the application layer, you install and start the FlexApp packaging console. It is preferred that this machine closely match your environment and be a non-persistent machine that you can easily snapshot back to a base image to keep it clean. You login with the URL of your ProfileUnity Management Console and can autheticate with your AD credentials.

Here you can edit, delete or create a package, I created a few already testing the product. Let's create a new one with 7Zip.

It says 7Zip and Firefox but while typing I decided 7Zip is enough to show the working concept. You point to a share you created for these packages and continue with creating the package. You can set various options like size, installer location and virtual disk type but I left it all default.

After you clicked continue the packaging process is started the VHD (VMDK is also selectable) is provisioned and mounted, all you have to do is click on Start to package the application in the layer.

You then get a message that the application installer has been launched, after you have completed any interaction with the install and it completes you click on Finish. There is nothing more simple than this.

So here we go, the dreaded ;) 7Zip installation... 

...and we're done

So now you click on Finish and the capture of the application is starting, uninstallation and unmounting the VHD. We're almost done here, just one more step to take.

You need to set an icon for the package, this is because there is only one application installed in the package. When more applications are installed there is a generic icon displayed. So pick one and click OK.

Packaging has finished.

Now we turn to the ProfileUnity Management Console and open the Windows 2012R2 configuration and open the FlexApp DIA option there.

If you were wondering about seamless integration with the packaging console, it is tightly integrated, the package we just created is already selectable from here. We can add it to the selected users’ environment with a context aware filter rule to this configuration.

I haven't selected a filter yet but the filter rule her could be "finance department" user or "all users with that legacy 90's app they can't get rid of". Depending on the rules you set there and anywhere in the console on the configuration, you design an application user environment fit to your user population.

If you look at all the option for filtering it shows you have a massive amount to determine the context in which you determine when you deliver applications to users. I think this is a very interesting option that I haven't seen with App Volumes yet. App Volumes and VMware UEM have to be more integrated to provide anything like this. VMware UEM offers this but lacks the ability to call an AppStack to be loaded.

VMDK “FlexDisk” options are also available for FlexApp DIA delivery. The interface to assign VMDKs is simiar to the VHD interface. As stated earlier, you can mix and match VMDKs and VHDs.

For now I assign a rule called Windows 2012 RDSH to it to correspond and apply the FlexApp DIA package to correspond to the Citrix XenApp server I'm working on.

.....and that's it, I created a package (or AppStack as called in App Volumes) and assigned it to a configuration in ProfileUnity. UEM and application delivery combined. No hassle with scripting to make sure one knows that the other one is doing something like I faced earlier with App Volumes, it's integrated.

Is it Faster than App Volumes? My lab is not the place to test speed, I did however have a chat with my co-worker, Sven Huisman, about this for we have an old VRC lab running at PQR. That would a be good testing place for speed. For now, even in my underpowered lab, the process goes smoothly at login.

Comparing

One difference between App Volumes and FlexApp is that App Volumes can do an instant creation of the AppStack during a user’s session and FlexApp does it at logon. The problem App Volumes has with in session assignments right now is that VMware UEM (if you have that running) isn't aware of what App Volumes has done and therefore won't show any applications until you refresh the session yourself.

Until VMware issues a fix for that there is no use for that option and for me it doesn't count as a plus. On the other hand, you have to wonder how useful that option is, most times it will happen at logon.

Another difference is that App Volumes, VMware UEM and VMware Horizon view use different consoles and are not integrated yet. Until that is fixed it's kind of a hassle to move from console to the other in order to give your users what they ask. App Volumes doesn't have the rich context filters that FlexApp integration with ProfileUnity features. App Volumes only has the ability to define users, groups and OU’s which can be a somewhat limiting way to apply applications to users.

App Volumes - assingment

ProfileUnity and FlexApp are neatly integrated, packages you build on the FlexApp Packaging Console are instantly visible in the ProfileUnity Management Console and can be assigned to configurations.

ProfileUnity also is introducing ProfileDisk in this release. ProfileDisk saves the user’s profile as Windows sees it to a VHD or VMDK. This new approch works with ProfileUnity’s existing profile portability features to dramatically speed logons in non-persistent desktop enivornments. App Volumes had a similar profile to disk feature as part of their user writable volumes but according to recent release notes VMware has deprecated this feature.

So if we have go on Pros and cons here, it will be:

Pros for ProfileUnity’s FlexApp

• Integration with ProfileUnity.
• Profile Disk technology to speed logons for non-persistent desktops
• Ease of installation and creation of packages.
• Ease of setup of ProfileUnity.
• No workarounds to work together with the associated UEM solution.
• VHD and VMDK delivery methods both work seamlessly together.
• Not tied to a VDI vendor, if you switch between Citrix or VMware your delivery method stays.
• Massive filter options to determine context to apply apps and policies.
• Good option for VMware customers on Horizon Standard or Horizon Advanced.
• Good option for Citrix customers that don’t have full UEM and App Layering options.

Cons

• Third-party license to be bought for customer.

Pros for App Volumes

• Ease of setup and usage.
• Instant assignment is a minor pro - doesn't work properly with UEM.
• Available licensed in VMware Enterprise.

Cons

• Limited integration with other VMware products
• No detection of adding an AppStack by VMware UEM at logon
• Recently deprecated profiles to writeable volume
• Only cost-effective in the Horizon Enterprise license

So looking at the whole matter I think it's fair to point out that whenever a customer has a VMware Horizon Enterprise license they get the whole stack of products and will first try the included VMware options of App Volumes and VMware UEM. However if the integration of the product is not improved the whole stack is not usable together. For now, VMware UEM has no trigger at logon that knows when an App Volumes AppStack is connected and therefore it's always too early, showing no applications from the Appstack. So if integration is there and a customer has an Enterprise license, they may use the VMware’s stack but for now I don't see why or how they could.

If customers have a lower license from VMware they get the old VMware’s older profile solution known as Virtual Profiles, which is crap. They also don't get App Volumes, so at that point they might be interested in looking for a third party solution.Citrix customers also have a solid option in ProfileUnity and FlexApp where they have very limited profile options currently. Liquidware Labs ProfileUnity with FlexApp is a valid third-party solution that seems to be primed to hit a sweet spot in the market. It offers robust UEM features including Application Rights Management and fully baked integration with Application Layering that will strike the right chord with many customers. ProfileUnity v6.5 BETA was used in this review and Liquidware Labs is opening up the BETA program to the public this week so you’ll soon be able to download and try it for yourself on their web site. Liquidware Labs plans to make v6.5 GA next month.

Originally posted at http://www.robbeekmans.net/uncategorized/liquidware-labs-flex-apps-micro/

Liquidware labs FlexApp – Microisolation
Liquidware labs recently launched a new feature for their FlexApp product, micro isolation it is called. Micro isolation in short is away to differentiate between applications and file requests. In this article I’ll tell you a bit more on the why and how.

Quick history lesson

I’m an old guy born in the summer of ’69, so when I started in IT things were not that smoothly and applications used to have conflicts with other applications. fights about files they want to access, files with different version. Those days were called the DLL hell and boy did we have issues at that time.

To overcome the issues with the DLL hell Microsoft created the WinSxS folder. Wondering what the WinSxS folder is all about? Short answer, it is your operating system. All files you see that make up Windows and files that you install with installing applications are stored there and projected somewhere else. There is only one location where one version of the application is stored and that in the WinSxS folder also called the component store. 

Installing a new version of a file resulted in the file being added to the component store but not to the deletion of the old file. This was causing another issue, the WinSxS folder was bloated. You all been there wondering why that folder was so huge.

FlexApp micro isolation 

To make sure your WinSxS folder doesn’t get bloated we will handle files and applications differently. With FlexApp you have the ability to layer applications, you can layer multiple applications in one layer or create one application per layer.
Let’s focus on one application per layer.

Let’s say we have appstack1 and appstack2, both one application, both application requiring the same DLL but a different version.

• Layer1 is connected and the application can access the DLL on the system, no issues will occur.
• Layer2 is connected and the application would have an issue with the DLL on the system for that DLL is a different version. 

However with micro isolation the filter driver sees and intercepts the starting of the application. FlexApp sees that the application is requesting access to that one DLL and will redirect the application to access the DLL within it’s own layer.

This technique will make sure the conflicts don’t occur, which is pretty neat.
What other issues is it solving?

When you have multiple applications in a layer you might have a challenge updating applications in a layer. Updating one application could break another application, you won’t know up front if a file will be replaced.

With one application per layer you won’t have that issue, you can update as you want and conflicts will be resolved by a neat filter driver. 

One issue I see there is that if you have too many layers you won’t be able to connect them or things might get slow. I think it will need time to test this but it looks interesting to say the least.

Installing a set of applications in one layer and some other freaky ones in another is a scenario that would work. the filter driver will work out the conflicts and redirect where needed. Think about application suites that connect to internal application that are not standard. you don’t want those together in one layer.

Conclusion

I think it’s a good addition to the product, they are working hard to make the product more and more mature. Keep an eye on them, they are serious business. Like said before, need a demo

Originally posted http://vthoughtsofit.blogspot.co.il/2016/02/liquidware-labs-flex-apps-micro.html#.Vrnno1h96Um

Liquidware labs FlexApp - Microisolation

Liquidware labs recently launched a new feature for their FlexApp product, micro isolation it is called. Micro isolation in short is away to differentiate between applications and file requests. In this article I'll tell you a bit more on the why and how.

Quick history lesson

I'm an old guy born in the summer of '69, so when I started in IT things were not that smoothly and applications used to have conflicts with other applications. fights about files they want to access, files with different version. Those days were called the DLL hell and boy did we have issues at that time.

To overcome the issues with the DLL hell Microsoft created the WinSxS folder. Wondering what the WinSxS folder is all about? Short answer, it is your operating system. All files you see that make up Windows and files that you install with installing applications are stored there and projected somewhere else. There is only one location where one version of the application is stored and that in the WinSxS folder also called the component store. 

Installing a new version of a file resulted in the file being added to the component store but not to the deletion of the old file. This was causing another issue, the WinSxS folder was bloated. You all been there wondering why that folder was so huge.

FlexApp micro isolation 

To make sure your WinSxS folder doesn't get bloated we will handle files and applications differently. With FlexApp you have the ability to layer applications, you can layer multiple applications in one layer or create one application per layer.

Let's focus on one application per layer.
Let's say we have appstack1 and appstack2, both one application, both application requiring the same DLL but a different version.

• Layer1 is connected and the application can access the DLL on the system, no issues will occur.
• Layer2 is connected and the application would have an issue with the DLL on the system for that DLL is a different version. 

However with micro isolation the filter driver sees and intercepts the starting of the application. FlexApp sees that the application is requesting access to that one DLL and will redirect the application to access the DLL within it's own layer.

This technique will make sure the conflicts don't occur, which is pretty neat.

What other issues is it solving?
When you have multiple applications in a layer you might have a challenge updating applications in a layer. Updating one application could break another application, you won't know up front if a file will be replaced.

With one application per layer you won't have that issue, you can update as you want and conflicts will be resolved by a neat filter driver. 
One issue I see there is that if you have too many layers you won't be able to connect them or things might get slow. I think it will need time to test this but it looks interesting to say the least.

Installing a set of applications in one layer and some other freaky ones in another is a scenario that would work. the filter driver will work out the conflicts and redirect where needed. Think about application suites that connect to internal application that are not standard. you don't want those together in one layer.

Conclusion

I think it's a good addition to the product, they are working hard to make the product more and more mature. Keep an eye on them, they are serious business :)

Like said before, need a demo :)

What is most valuable?

How has it helped my organization?