MITRE ATT&CK (tactics, techniques, matrix, IDs)
Prisma Cloud in 60s
Changed focus – The world of…
Horizon – Brokering
Horizon Golden Master – Best practice
Horizon Cloud on Azure
Horizon Cloud on Azure – How to start with subscription
App Volumes – Prepare provisioning machine / VM
Horizon Cloud on Azure – Onboarding
SAML SSO Okta Org2Org

Application delivery or when use what

Often I get the question when use what kind of Application delivery? What are the differences between them. In the following I will give you the answer and some use cases. In principal you should think about, what is the target and which use case you have. Three methods are useable.

 

1. Application Virtualization / Sandboxing (Thinapp)

In case of Application Virtualization aka Sandboxing, first you need a packaging VM. The packaging VM has the base OS installed nothing more! No other Application should be installed on that Machine, clean OS installation. Please have in mind, to make a snapshot, first after clean installation of the machine and second after installation of Thinapp Packager. Reason is that you can revert the snapshot in case of any issue. Now you can start. Pre scan the source System which is used to packing Applications. After that, you install the Application or x Applications you want to use on the System and configure it. Configuration in this case mean License acceptance, special settings like “look and feel” for an Application or and this is very important, some Applications create on first start an Profile (Firefox for example). This you have to do before further steps. After all configuration is done, you make a post scan of the System you installed the Applications on. The post scan is the Process which notice the changes in the System and packaging the Application and (create the Sandbox).

But at which situation you use that kind of of Application delivery? The main use case for that is to delivery the same Application in different versions to the same OS.

 

An Example:

The Company you support or work for use a internal self developed System. To work with this System, you need a certain version of an Application like Firefox or Adobe Reader not the newest one but an older versions. Or you need a combination of that. The strategy of the Company is to use all the time the newest versions of Applications and OS. What is the problem? A Firefox or Adobe Reader in a 4 years old version is not possible to use or supported on your current OS.

From another perspective another problem could be that the Company can´t migrate to the current OS version because of the dependencies to the old Application version.

This two use cases are perfect for Application Virtualization like VMware Thinapp. You can sandboxing the Application and abstract this from the underlaying OS. So the Company can upgrade to the newest OS, but also use the internal self developed System because of the sandboxed Application in the version you need. Such kind of Applications can run on the System without problems or incompatibility with native installed Applications even if the Applications are the same. Further you can configure some combinations of this Applications which can interact with each other.

 

Another cool example or use case for Thinapp is portable Apps. If you have created the sandbox / the virtualized Application, you can put this on an USB Media for instance and use it as portable App. Sure there are some limitations such OS version etc. but it´s really a portable Apps. One tip from my side, if you use Thinapp and create several Applications, store the source files of your work. If you need or want to update your Applications you will need them.

This pretty nice method can solve some use cases or restrictions on the one side but has some limitations on the other side. You can´t virtualize stuff which is near to the OS or interfaces like Printer Drivers.

 

2. Application delivery on demand (App Volumes)

Application delivery on demand is a pretty nice method. With VMware App Volumes currently in Verison 2.11 you can deliver Applications or a bundle of that to the virtual Desktop in a very fast way. In App Volumes you use

a) AppStacks – read only volume

b) Writeable volume – a volume on which the user can install Applications by himself

But how it works?

App Volumes (AppStacks) use .vmdk or .vhd files to delivery the Application or bundle of Applications to a virtual Desktop or RDSH Host or Farm. What you should think about is the difference between .vmdk and .vhd. In case of .vmdk the AppStack will be mounted directly to the Desktop. In case of .vhd it will streamed over the network. That is important for the Design of the Infrastructure and the Solution.

In case of App Volumes you have a so called packaging VM for installation and creation of the App Stacks (vmdk or vhd file with an Application or bundles) as well.

A pretty good use case for this method is, if you want the best of flexibility and a fast delivery.

 

3. Published Application 
Published Application is a method in which you install all your Applications on a RDSH or RDS Host (Terminal Server). The RDSH Host delivery the Application to the User but all Workload is on the RDSH Host.

Why you should use that?

Published Applications will be used if you want to centralize the Application and Workplace of the Users. Another reason is to increase the User density. Of course, costs for Licenses and Hardware are important. But this kind of Application usage has limitations as well. Not all Applications can be installed on an RDSH Server. This is a limitation of the Application himself.

 

So, before you start, think about your use cases and the kind of Applications you want to. Then you can start and you have fun with Applications and their delivery method.

591 Total Views 1 Views Today
twitterlinkedinmail

Leave a Reply

Your email address will not be published. Required fields are marked *