FlexApp has a lot going for it. Architecturally it’s very different than other layering technologies. This difference gives FlexApp a much better application compatibility percentage when compared to being able to dynamically deliver layers to Windows.

A feature of FlexApp that isn’t talked about much is its ability to do Session Isolation in Remote Desktop Services environments. Session Isolation is the ability to deliver applications to a multi-user Windows system and only those users/groups assigned to that application can see and use it. Other users on the same system do not even know the application is there.

The most obvious advantage is the ability to consolidate multi-user systems. Typically, administrators have two choices when a new application is brought into the fold: One, add it to existing systems or two, create a new set of systems to deliver the application. The issue with option one is that you are, in reality, giving access to any other user that logs into that system. Even if you are doing published applications, the ability to run the application is still there. The issue with problem two is you are adding more systems to manage. At least two for redundancy if not more. Both solutions work but may not be optimal.

Session isolation gives the administrators a third option. Use existing systems BUT only those users assigned to the application can see and use the application. Take that a step further and you could potentially take other systems that you had set aside with option two and take those down and deliver the apps to other systems. Consolidating the applications and consolidating systems for less management overall.

With FlexApp admins are not limited by simple username or user group. I’ve talked about the power of the filters before and this is really where they shine. For example, an admin has created a filter for a single application. Let’s say, Notepad++. The filter states a user must belong to a specific user group AND the client machine is in a certain IP range. Both UserA and UserB belong to that user group. UserA logs in from a machine that is within the range to allow access to the application. They can see and use the application successfully. UserB logs in from a machine that has an IP that is out of scope of the filter. UserB does not get access to the application and is not able to see the application to even run it manually. If UserB had access to other FlexApps and successfully satisfied the filter criteria, they would get access to those applications. The admin could also create different filters for the same application to allow varying users to access the application. The admin could go as far as specifying a date and time that a group of users have access to the application. If they log into the environment outside of the specified date and time, they do not have access to it at all.

Another use case may be that you don’t want all the FlexApps a user has access to to be mounted on the same servers. For example, an application only works in conjunction with another application that is built into a particular image. Filtering would allow for the admin to specify the FlexApp is only mounted when the user logs into those systems. Any other system, they get a different set of applications. The flexibility of not having layers delivered by simply username or user group is one of FlexApps greatest advantages.

Power to the Administrator!