During the last couple of months I got a lot of questions about the different deployment methods that can be used to deliver an application to the end user in a BYOD enabled business. Within the VMware Horizon Suite there are multiple different solutions. But when adding AirWatch to your infrastructure, it can be quite difficult to choose the right method. Keep in mind that the most important thing when choosing a methodology is that you want to satisfy the end user. The end user needs to have the smoothest user experience possible. And you need to provide that smooth user experience to different kinds of endpoints (Windows PC’s, MacBooks, iPads, Android Phones, Crome OS, etc).
So where to start. First of all, applications come in different flavors. Windows applications are the most common, but not always the easiest to deliver. Web applications are often the most easy to deliver, but will not work on any browser. So it can be quite hard to choose the right application for the right device.
When choosing a delivery method, especially for enterprise environments, you need to understand that computer-related skills aren’t common with every employee. So when adopting BYOD, it needs to be through an intuitive interface which basically everyone could use. VMware Identity Manager is a solution that offers an App Store look to your BYOD environment:
To be able to add apps to the above portal, you need in-depth knowledge of the applications you would like to deliver. From a public cloud perspective, al lot of applications are predefined and choosable from the cloud catalog. Unfortunately, most applications aren’t. To get you started, I created this flowchart to help you choose the right delivery method:
So let’s run through it.
To start off, this flowchart is dedicated to help you if your complete EUC environment consists out of VMware’s portfolio. Of course, some of the applications like ThinApp could be replaced by App-V or RDSH by XenApp.
Let’s take a look at the first step deciding. As you can see, the first step in deploying an application is to primarily check if a native application exists for an endpoint. You see, these applications were already built with the purpose to run on a specific endpoint only. The app doesn’t need any special solution to distribute it other than our Enterprise Mobility Management solution called AirWatch. AirWatch has the ability to provision apps directly to an endpoint if it is enrolled in the Mobile Device Management part. See it as adding a Windows PC to a domain en get apps automatically distributed by GPO’s or SCCM. AirWatch supports a wide variety of endpoints like OSX, iOS, Android, Windows (RT), Chrome OS, etc. Examples are outlook, slack, Skype for Business, Google Maps and Dropbox (although there are better, enterprise ready, solutions than Dropbox).
If there isn’t a native app, you have a couple of options. The first is to check if there is a Windows App. If so, deciding the right windows based distribution method could also be challenging. Based on whether the app has certain features that doesn’t make it suitable to virtualize with ThinApp or provision in an appstack, the solution you could always count on is installing the app on an RDSH pool. Natively installed and just run it. Use UEM to make sure that applications settings are retained and saved to the segmented profile.
Using App Volumes to create an appstack will be your best practice though. Because creating containers with groups of applications makes it easier to maintain and upgrade and faster to deploy. Especially with VDI or RDSH pools. If an application conflicts with another, use ThinApp to create a container with the app and put the container inside an appstack. That still gives you the fast deployment of App Volumes, but with the isolation of ThinApp.
In both above cases (locally installed in an RDSH pool or via App Volumes/ThinApp in an RDSH pool) you will end up syncing the apps and entitlements with Identity Manager (vIDM, formerly known as Workspace Portal) so users have easy access from the intuitive interface.
If an app is already running in some cloud and is published by either Citrix XenApp or Microsoft RemoteApp, you just add the connection client as an app to the RDSH pool and configure the new app as a manual one in the Horizon App pool (if you want to distribute the icon via vIDM and you don’t manage the RDSH pool behind the app that is).
The often easiest apps to distribute are webbased apps. If it supports SAML for single sign-on, you’re the man. This will make sure users are happy. You simply add the app to vIDM, select the shared common entity (like email address) and bob’s your uncle.
If the app doesn’t support SAML, you just publish a the webapp without SSO. Although it seems easy, some apps require certain browsers. So be informed which ones try to figure out if they are supported on the browser of you endpoint.
Also, in this case the app is provisioned to the intuitive interface of vIDM and directly accessible by the enduser.
Since Horizon 6.2 and vIDM 2.4, all remote applications can be started as HTML5 app. So you don’t have to use another client like the Horizon Client or an RDP client to start them (I know, Blast is awesome!).
And since Horizon 6.2, the RDSH pool supports 3D acceleration. So less reasons to publish a whole desktop to an enduser.
I hope this will help you decide on how to deploy whatever application you need to deploy. Please keep in mind that there are always applications that are written “differently”. And these applications may need a different approach to deploy.
I will update the flowchart whenever it is needed. If you have any comment or feedback, please let me know as I hope that this is a method that could all help us.
And if you need any help on implementing solutions like this, please let me know as I am happy to help!
Latest posts by Johan van Amersfoort (see all)
- Commodity IT, the problem formerly known as Shadow IT - October 4, 2017
- VLOG 001: Video review of VMworld 2017 Las Vegas - August 31, 2017
- EUC Announcements at VMworld 2017 in Las Vegas - August 29, 2017