People love the simplicity and intuitiveness of the VMware Digital Workspace.

But under the hood lies a suite of products to secure and provide that experience. Here are the most common questions i get from my customers:

1. So what products power VMware Digital Workspace?
2. What are their capabilities?

Brian Madden even wrote a blog on it https://www.brianmadden.com/opinion/Just-what-is-a-Workspace

I am going to make it short and simple on a single canvas. Here it is!

Disclaimer: The is a simplified version and only the most prominent features are listed.

I lost count on how many times I ve been asked by an ADFS customer “Why VMware Identity Manager when I already have ADFS?” Since I ve hear it almost every week, I decided to pen it down. Here I go!

VMware Identity Manager(vIDM) can do many things. It can be your primary IDP for federating web applications or can co-exist with an existing IDP such as ADFS.

Following is how vIDM is different from ADFS and this may help you to decide whether to use vIDM or ADFS as a preferred IDP for future applications or think about migrating your existing ADFS applications to vIDM.

vIDM does much more than Federation

Though the name has “Identity” in it, vIDM does much more than Identity. Some of the key features:

1. Unified app catalog with native mobile application
2. Conditional access based on factors like location of user, device compliance checks, application blacklisting and so on.
3. Built-in 2 factor push authentication.
4. Single touch mobile SSO.
5. Integration to VMware AirWatch and Horizon

Support for all application types

Key question to ask yourself:

What types of applications do you have in your environment? Do you have iOS or Android apps? Do you have Horizon or Citrix?

vIDM is focused on building the seamless user experience on desktop and mobile across all applications such as:

1. internal web applications
2. SaaS applications such as SAP Concur, O365
3. virtual desktops and apps based on VMware Horizon
4. native mobile applications
5. Citrix

Virtual Desktops, applications and native mobile applications are key use cases for many of VMware’s customer which cannot be federated on ADFS.

vIDM is designed and built for Mobile and Cloud

ADFS is based on native Windows Operating System and Active Directory constructs such as STS (Secure Token Service) and Claim Rules. It is built for native domain joined Windows endpoints such as Windows 7,8. This explains why ADFS does not provide a native mobile experience and lacks native mobile single sign on.

vIDM is a modern Identity Provider designed and built for Mobile and Cloud native applications so that users can use any endpoint (iOS, macOS, non-domain joined Windows, domain-joined Windows) for seamless access on WorkspaceONE app on phone and browser.

Self Service and App Catalog for Presentation

ADFS do not provide a portal or application catalog to be presented to users. Users need to bookmark application URLs to be accessed. This causes inconvenience and adds Level 1 helpdesk tickets. The experience becomes worse when users use different devices where they will need to carry their bookmarks with them across devices.

Workspace ONE is unified catalog of all applications that presents single URL and mobile app for applications.  Find the picture below for a taste of it.

One of my customers asked me yesterday what Client ID represents on the Horizon Administrator Console.

My first reaction was to assume it was the MAC address of the Client device but quickly realized that was far from being true. I couldn’t find official documentation, so thought I ll write this one up.

“Client ID is the unique identifier that is generated by Horizon Connection Server for every client that connects to it”.

It is a random number generated by the combination of MAC address of the endpoint and the client type (HTML, iOS, Windows, Linux).

For egs, a Windows endpoint(with a single MAC address) installed with Horizon Client  can potentially have multiple Client IDs based on number of client types used to access VDI. One for the Windows thick client and a different Client ID gets created for each browser(Firefox, Edge, Chrome).

The important thing to note is that Client ID will persist across sessions if it is the same device/browser combination.

In the below example, from the same Macbook I am accessing Horizon using two different Horizon Clients clients 1) HTML client which is my Chrome browser and 2) MacOS client.

Access from MacOS Client

I am accessing two different desktop pools APAC-Win10AE and APAC-Win7 and the Client ID remains the same. Notice APAC-RDS when accessed using HTML Client shows a different Client ID.

Access from HTML Client

I am accessing two different desktop pools APAC-Win10AE and APAC-RDS and the Client ID remains the same. Notice APAC-Win7 Pool when accessed using MacOS Client shows a different Client ID.

Side Note: Client ID also helps Horizon Server to uniquely identify clients for several purposes such as 1) Kiosk mode login 2) allow or deny single or multiple sessions for a single Desktop Pool.

Migrating to VDI from a traditional laptop/workstations world is like relocating to a new city. Lesser the baggage, easier it is.

Migrating 1000s of applications deployed through SCCM (or any other tool) from laptop/workstations landscape to a VDI infrastructure is exactly that. You will first need to conduct few preliminary exercises to understand more about your application estate before formulating a deployment strategy for VDI. Introducing Windows 10 into the mix is certainly not going make it easier for you.

There are 3 steps before formulating Application Deployment Strategy:

1. Application Rationalization exercise
   
2. Application Compatibility Testing
   
3. Application Delivery Pilot
   

Application Rationalization Exercise

“Key goal of application rationalization exercise is to identify and if possible eliminate (or remediate) applications that are not suitable for VDI”.

For this exercise, let’s take an example of a typical enterprise customer with over 50,000 employees and 1000 applications.

Generally speaking, the applications will fall into the following categories:

1. Core Business Applications – Business owners will have list of applications that are used by their users for the core business workflows. If it is a bank it could be their core banking software and if it is a retail it could be their inventory system and so on. It is important to get an accurate list of required versions of these applications and installation/packaging details from the application vendor.
   
2. Core Applications – These are typically applications that are required by most users (if not all) to remain productive. MS Office, Instant Messaging and collaboration software like Lync, internal HR, employee portals, Google Chrome and so on.
   
3. Long Tail Applications – These are applications that are occasionally used by small group of users. Since it is hard to predict when they will be used it, it is common practice for IT to push it users who may need it. I wouldn’t be surprised if 20-40% of all applications fall into this category.
   
4. Redundant applications – Different versions of the same applications is common in the enterprise. It for the business owners and application vendor (if applicable) to confirm the version(v) or (v-1) of the application that is supported and recommended for their end users.
   
   1. Common reasons of seeing redundant applications are:
      
      1. OS and platform dependencies
         
      2. Inability to keep applications updated.
         
   2. VDI should ease the above two problems as users will be using a standard OS build and applications are updated centrally.
      
5. Unused Applications and/or Shadow IT – Every enterprise has applications that are not used anymore because business process has changed or there is no requirement. Typical example are PDF readers. It’s common to find 5-10 different PDF readers in the install base due to some specific functionality requirements at some point in time. Another common type of applications is the one that user runs themselves without the authorization or approval of IT known as Shadow IT.
   
6. End of life applications –Windows XP applications. Familiar? Enough said.
   

The application inventory can be retrieved from SCCM (or other tool) but for assessing how applications are used, you may need other tools like Lakeside SysTrack. Key data you want to find out are things like application sprawl, how often they are used, resource requirements and so on.

There may be applications that are listed in the SysTrack report but are not in the SCCM list. These maybe “shadow IT” where the user installs or runs applications that are not authorized or distributed by IT.

The question to always ask yourself when analyzing apps are:

• Do you really need this application?
  
• If not, do you want to keep it?
  
• Is there a newer version of this app that could make things easier here? Perhaps version 1.5 doesn’t work, but version 2.0 does work?
  

Application Compatibility

After the previous exercise of Application Rationalization, you may be able to eliminate large chunk of applications which fall in the last 3 categories (Unused applications, end of life or redundant applications). Of the 1000 applications in our example, through standardization, we may be able eliminate 400 applications which is 40% of the application landscape if you are aggressive.

The next step is to check for the compatibility of applications on OS platforms such as Windows 10 or Windows 2012 R2 (for VMware Horizon Apps or Citrix XenApp).

Applications can be classified broadly into 2 categories:

• Web applications
  
• Windows Applications
  

Note: For the scope of the discussion we will leave out native mobile applications based on iOS, Android and Windows.

Web Applications

We applications typically have the following characteristics:

• Browser supportability
  
  • IE version – Are applications certified on IE 11? If not what other versions?
    
  • Chrome/Firefox
    
• Plugin requirements – Typical are Flash, Quicktime,     custom plugins
  
• Java Requirements – JRE
  
• Permissions (elevated privileges in some cases)
  

Windows Applications

Windows applications typically have the following characteristics:

• Parity:
  
  • x86 – Is this application supported and function correctly on x64 OS such as Windows 10 or WS 2012 R2?
    
  • x64
    
• OS compatibility:
  
  • Windows 10 or Windows 7
    
  • Windows 2012 R2 or Windows 2008 R2
    
• Graphics requirements
  
  • Does this application vendor specify the use of specialized graphics hardware or is it just extra display memory and processing?
    
• Platform dependencies such as Dot NET, Java and so on.
  
• Permissions (elevated privileges in some cases).
  

There are various tools (Lakeside SysTrack, Citrix AppDNA, Dell ChangeBASE) in the market that will help do Windows 10 assessment and provide reports on application compatibility and remediation guidelines for applications. But at the end of the day you may still end up testing and validating the application on the OS platform if there is no application vendor support on that platform.

Applications that are not compatible with OS Build (Win10 or Win7 or WS 2012R2) will need to be remediated or updated to be compatible.

The point is to make sure you don’t go light on the remediation. It’s a hard step, it needs to be really discussed and discussed again. It’s a common find IT spending time and effort wrangling on an app to suit Windows 10 rather than simply switching to native web/SaaS.

Application Delivery Pilot

Once you have a list of applications that are VDI friendly, the next obvious step is to run a Pilot to test applications to validate few things:

• Compatibility with the OS
  
• Interoperability with the rest of the applications
  
• Right delivery methodology for the application
  
• User experience and performance
  

In a VMware EUC world, there are 4 ways to deliver applications:

1. Delivered as a part of the base OS
   
2. Delivered via ThinApp (Streamed or Installed)
   
3. Delivered via a Layering technology as App Volumes
   
4. Delivered via Horizon Apps via RDS
   

Each of the delivery techniques have pros and cons which are beyond the scope of this document.

At a high level, the following are the pros and cons of each of these delivery techniques.

The next step is to select applications that make a good sample set for the Pilot. This should include but not limited to the core applications, key business applications and applications that are most commonly used.

For example, you let’s say you have selected 50 applications of the remaining 600 applications. This 50 should be a good representation of the 600 so that it will help you formulate a deployment strategy. These 50 applications should be tested with App Volumes, ThinApp and RDS to gauge the most appropriate technique.

So based on factors such as technical complexity, operations and business requirements, you may formulate a strategy to arrive at what percentage of applications will be delivered through which methodology.

The following are the typical delivery considerations for VDI administrators.

• Limit the number of base OS images
  
• Able to update and manage applications independent of base images
  
• Provide good user experience
  
• Minimal infrastructure
  

The following ratios could be a “starting point” for the Pilot testing if your key objectives are the above:

Core applications such as MS Office, Lync, Google Chrome and company-wide used applications are installed in the base image. Since these are typically the most widely used applications and require best performance, this is a practice seen among customers. I ve also seen customers having base image for various functions such as “Contact center” user group where all commonly used contact center applications are delivered inside the base image.

App Volumes offer native user experience and helps bundle applications in “AppStack”. Typical use case is IT maintaining an AppStack for every department. In such a case, core applications will be delivered via base image and department applications are delivered via AppStack.

ThinApp applications can be packages and hosted in a SMB network share which can be accessed inside a virtual network. This is called ThinApp streaming. Alternatively, you can also deliver ThinApp as portable application or host in a RDS server.

Lastly, you can deliver applications via Horizon Apps by hosting applications on separate Windows RDS servers. This is especially useful for applications that are “occasionally used” where RDS session is only consumed when a user accesses it.

So, there is no “one size fits all” strategy and you will need to determine the right approach for your business during your pilot testing and validating against your business needs. The above are some guidelines with an oversimplified example.

Credits: Thank you my friend Ernest Nichols for the reviewing the draft and providing useful feedback J

Note: The above article is neither endorsed, reviewed or validated by VMware. This is purely based on my personal experience and what I see in the field.

Integration with Symantec Multi-Factor Authentication

Symantec Multi-Factor Authentication can be integrated with vIDM in two ways:

• via RADIUS using Enterprise Gateway
  
• via SAML using VIP Login service
  

Limitations of RADIUS integration

Integrating vIDM via RADIUS with Symantec Enterprise Gateway to use Security Code is seamless and straightforward.

References below:

http://pubs.vmware.com/vidm/topic/com.vmware.wsair-administration/GUID-79EF08F7-B2FD-4E85-A2A8-1FEA28DDD414.html

https://support.symantec.com/en_US/article.INFO3360.html

Typical RADIUS integration involves configuring a Validation Server on Symantec Enterprise Gateway. This validation server allows you to configure multi-factor authentication using Security Code.

As of writing this I have not been successful in configuring vIDM with Symantec Enterprise Gateway using RADIUS for authentication based on VIP Access “Push” mechanism.

I suspect this issue to be related to the fact that vIDM when configured with Enterprise Gateway via RADIUS always expect the Security Code to be entered and the field “RADIUS Passcode” is always displayed like shown below. This prevents the redirection to the subsequent Push Notification screen.

From the user experience perspective, it is not very convenient for the user to enter the Security Token during login. He has to take out his cell phone (or VIP token device), generate the one-time security code and key in the code in the vIDM portal. Quite cumbersome compared to you getting a “Push notification” on your cell phone that you need to be swiped to Allow.

Due to the above-mentioned limitations that I encountered, I integrated Symantec VIP Login using SAML.

Integrating Symantec VIP Login Service with vIDM directly (not through Symantec Enterprise Gateway)

For this integration, vIDM is the Service Provider(SP) to Symantec VIP login which is the second factor Identity Provider (IDP).

• Retrieve SAML certificate and Metadata XML file from vIDM

Download the Metadata XML file for vIDM as “SP” and the SAML certificate.

• Retrieve SAML certificate and Metadata XML file from Symantec VIP Manager

You can download the Metadata XML for VIP login as “IDP” and SAML certificate from the below section.

• Configure VIP Manager

Import the vIDM certificate and the XML file into the Symantec VIP Login. This will establish a SAML trust between vIDM as SP and Symantec VIP Login as the second factor IDP.

Enable Mobile Push as the authentication option.

• Configure Symantec VIP Login as a IDP in vIDM.
  

As shown in the screenshot below, provide the VIP Login Metadata XML, choose the domain and network range and leave all other values as default options.

Configure the default Authentication Method as “Push” and SAML context as Password.

• Edit the Network Policy to enable the previously created Push Policy

The user experience looks like this.

Lately, I have been getting a lot of queries around sizing RDS servers for Horizon Applications.

Though there is guidance around RDS sizing in the VMware Horizon 6 Reference Architecture Technical White Paper, there still seems to be lot of people requiring a simple tool do so.

Page 22, 23 and Page 25 of the white paper covers RDS sizing and provides you with details.

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-reference-architecture-horizon-6-view-mirage-workspace.pdf

The article provides a sizing spreadsheet which by changing 5 cells you can determine the number of ESX hosts required for your Horizon Apps RDS servers.

The aim of the sizing spreadsheet is to make things simple.

The only way in my opinion to accurately size RDS servers is to actually test it as there are so many factors that affects user density and scalability.

Some of them are:

• Clock Speed of the core. 2.4 Gz core offers better performance than 2.0 Gz core
• Number of sockets. 24 cores on a Quad core ESX host usually is less performant than 24 cores on a Dual core ESX host.
• Applications types. Outlook 2016 with O365 with large OST files takes up a lot of CPU, memory and IOPs.
• Application usage,
• Graphics,
• OS version. Windows 2008 R2 offers better user density than Windows Server 2012 R2 which offers better user density than Windows Server 2016

In the absence of real testing, the next best option is to do an application and workload assessment with tools like Systrack.

So assuming that we don’t have Systrack data and do not have the luxury of testing the load, my sizing spreadsheet should provide a conservative output for your RDS sizing.

Here it is: https://www.dropbox.com/s/jc1zryijswl03tl/RDSH%20Sizing%20v1.0.xlsx?dl=0

Here is how a 2000 users RDS sizing looks like:

Some guidance:

• Blue Boxes requires your input
• Purple Box is the output which is the Total number of ESX hosts.

Further Guidance:

• No overcommit for vCPU to pCPU. 1:1 mapping.
• Ratio is nothing but a percentage. 20% of heavy users = 0.2, 50% of medium users = 0.5, 30% or light users = 0.3
• VMware recommends 30 users per RDS server. Also recommends 4 vCPU per RDS server.
• Buffer Ratio is up to you: for 10%, the ratio is 1.1. for 30%, the ratio is 1.3 and so on.

For the simplicity, I have excluded IOPS and Storage. If you need a number you may assume 10 IOPS for heavy user, 5 IOPS for medium user and 3 IOPS for light user.

Hope you find this useful.

It is very common especially in the banking, insurance and government sectors to find numerous legacy applications still needing older Internet Explorer versions. Typical example is certain modules of core banking software.

This is even more painful when some of the organizations try to rollout out “BYOD” programs and there are MacOS users in the mix. That’s when VMware Fusion and ThinApp comes to your rescue.

I ll tell you exactly how.

Things you need to get started aka “Pre-requisites”

For the end user:

• VMware Fusion
  
• Windows 7
  

For the administrator:

• VMware Fusion or VMware Workstation or VMware vSphere
  
• VMware ThinApp
  
• Windows XP 32-bit SP3
  
• Windows 7
  
• Internet Explorer installers.
  
  • IE 7
    
  • IE 8
    

The following are the high-level steps:

• Virtualize IE 6
  
• Virtualize IE 7
  
• Virtualize IE 8
  
• Install IE packages on Windows 7
  
• Run the applications in Unity mode and create MacOS Doc shortcuts
  

Virtualize IE 6

I don’t want to re-invent the wheel. Refer to the below KB article.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026565

I have created a video below.

Virtualize IE 7

Refer to the KB article below.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026674

Files required can be downloaded from below link.

https://www.dropbox.com/sh/3id9xqq8uyzaz9e/AAAuKOldIWVJVkZmRRffPMRoa?dl=0

I have created a video below.

Virtualize IE 8

Refer to the wonderful blogpost below.

https://blogs.vmware.com/thinapp/2015/01/package-internet-explorer-8.html

Files required can be downloaded from the below link.

https://www.dropbox.com/sh/yhdadx6q5613psd/AAA8TdfgE-hzCid7zY2FHJtha?dl=0

I have created a video below.

Install MSI packages on a Windows 7 machine

In the previous videos, you created MSI packages which now needs to be installed on a Win 7 x64 machine.

Creating MacOS shortcuts

Creating MacOS shortcuts in the dock is simple. The following is what you need to do:

• Power On Win 7 x64 VMs that is already installed with IE 6,7,8.
  
• Run the programs in “Unity” mode instead of “Full screen” or “Window Mode” like shown below.
  

You will find the Internet Explorer Windows seemingly running as a part of the MacOS. Now all you need to do is “Keep in Dock” as shown below.

Full Video can be found below.

Thank you folks, hope they are useful

Introduction

One of my customers asked me about migrating Horizon linked clones (with persistent disks) from one Nutanix cluster to another.

Traditional way of doing this is to detach the persistent disks and then recreate the persistent desktops as documented below.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2086416

But if the requirement is to have minimum downtime and to minimize touching the production environment (no detaching of disks and recreation of current desktop), you can do a copy of disks and do an import as documented below.

Step 1: Make a list of all persistent disks and the users associated with them.

• Below is my VDI pool with 3 persistent desktops.

• If you go to the persistent disks portion, you ll find the names of the persistent disks and the associated users.

• Use Powershell to get a complete and detailed list.

Step 2: New Datastore creation

• Create a new datastore attached the new VMware cluster that you want to migrate to.
• Make sure that all users shutdown their desktops so that persistent disks are not being written to.
• Once all the VMs are shutdown, copy over the persistent disks to the new datastore.
• In my example, I have copied over the 3 disks to a new datastore as below.

Step 3: Create a new desktop pool on the new VMware Cluster

• You will now create a Desktop Pool for Persistent disk based desktops on the new VMware cluster.

Ensure that you select the new VMware Cluster, the correct parent VM, snapshot and the folder location.

New Desktop Pool gets created.

Step 4: Import the persistent disks and recreate desktops

Click on Persistent Disks and select the “Detached” tab. You will find no disks.

Import the persistent disks from the new datastore and assign users to them. You must refer to the user assignment list created earlier to assign the correct disk to the correct user.

The disks get listed as below.

Recreate the persistent desktops from the disks.

Desktops VMs get recreated.

Another possible option(I have not tested this myself):

1. Add the new Nutanix cluster into the existing vCenter Cluster. So you will end up having a single vCenter Cluster with 2 Nutanix clusters.
   • Schedule downtime and ensure users are not using the system.
2. A new storage(of the newly added Nutanix cluster) appears in the vCenter Cluster.
   • DRS and HA need to disabled.
3. You may migrate the persistent desktops using the “Rebalance” option. Something like this http://blog.purestorage.com/vmware-view-desktop-migration/
4. You should now migrate the VMs to the new Nutanix nodes from the old.
5. You will now have the desktops running off the new Nutanix clusters without changing any settings in Horizon.