There has not been a single week at VMware so far that I have not been asked to clarify vSphere for Desktop licensing.

Last week, two of Singapore’s biggest FSI customers contacted me on exactly this. I thought it will be a good idea to document some of the clarifications that was needed.

Introduction

vSphere for Desktop is a license to run “VDI and related” workloads.

Note: All details that follows is as of 1 July 2016. VMware has all rights to change licensing in the future.

For starters, the following are some of the salient aspects you will need to remember:

• vSphere for desktop is only meant to run VDI and related workloads. This includes Windows Desktop OS workloads and Windows Server OS workloads to run Remote Desktop Services based applications or desktops. This license also includes VDI management components such as Connection brokers, profile servers, application delivery controllers that are used as in a VDI environment. Monitoring tools are also covered by this license. So in a nutshell, anything related to VDI is covered by the license.
• vSphere for desktop licensing is NOT based on CPU or sockets.

vSphere for Desktop for VMware Horizon VDI

• All editions of VMware Horizon are bundled with vSphere for Horizon.
• Horizon licensing is based on named user or concurrent user. It doesn’t matter to vSphere for Desktop how many hosts you use for your Horizon VDI and related workload. As long as you only host VDI and related workloads and not other non-vdi server workloads, you are free to use this license on as many hosts.
  • o For egs, lets say you have 300 VDI desktops. You may host 300 desktops and Horizon Management cluster on any number of physical hosts and this license covers all.
• vCenter for Desktop is also included as a part of Horizon. So you may run as many vCenter Servers for your Horizon VDI infrastructure.

vSphere for Desktop for non-VMware VDI (for egs: Citrix)

• vSphere for Desktop can be bought separately to host VDI and related workloads from another vendor such as Citrix.
• The licensing is NOT based on CPU or sockets or named users or concurrent users.
• The licensing is based on number of “Powered On” VMs. This means that the total number of “powered on” vms are counted. For egs, if you have 10 vms for VDI management, 100 desktops for user workloads, you will need to license 110 VMs as a part of vSphere for Desktop.
• Please note XenApp or RDS VM is also considered as a VM even though you can host multiple sessions or users on a single RDS or XenApp VM. So a single XenApp or RDS workload will only consume a single vSphere for Desktop license.
• vSphere for Desktop does not include vCenter for Desktop.
  • You will need to purchase vCenter separately to manage your VDI infrastructure.
  • As of writing this, you CANNOT buy vCenter for Desktop separately. vCenter for Desktop is ONLY bundled as a part of VMware Horizon and not available for non-Horizon customer. So you will to buy the “normal” vCenter Server to manage your VDI workload.

References:

https://www.vmware.com/products/vsphere/vsphere-desktop

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

One of the features of Horizon 7 is the ability to redirect USB and Client Drives as Read-only.

This is extremely useful for customers who are security conscious and do not want users to modify files on drives or usb devices connected to the endpoint devices from their virtual desktops.

A good example is a customer who is using VDI for Internet Separation. Lets a Govt Agency do not allow internet access on their production network. They may choose to publish Internet Explorer for users for web browsing via VDI or RDS. In such a case, IE browser runs in a totally isolated environment from the production network. Users are not allowed to download files or make modifications to the endpoint devices on the production network. However, they may still want users to upload files to external websites or use data on the endpoint. This can be done redirecting Client Drive and USB devices on the client endpoint to the virtual desktops.

This functionality is achieved by pushing down a group policy as below. Documentation reference.

Preventing Write Access to Shared Folders

To prevent write access to all folders that are shared with the remote desktop, create a new string value named permissions and set its value to any string that begins with r, except for rw.

HKLM\Software\VMware, Inc.\VMware TSDR\permissions=r

USB and Client Drive Redirection without the Policy

The client drives and USB drives are seen as below.

Users are able to write/modify files on the Client Drives and USB

USB and Client Drive Redirection with the Policy

Registry setting is modified

Users get an error while trying to write to the drives.

Recently I had a high profile customer having a terrible connection experience launching ICA sessions.

I checked the usual suspects like connection timeouts, disabling session reliability, checking for NAT settings and so on. No improvement.

However one thing I observed was launching the ICA session from within the same desktop network did not exhibit this behavior. So it must be something at the level of the client network settings or the ICA file itself.

After some Googling and messing around, it turned out to be Client Proxy settings inherited by the ICA file from the Internet Explorer Proxy settings. The users had proxy settings configured in their Internet Explorer. So the ICA connection first goes to proxy server before making a direct connection and that explains the long delay in establishing the connection.

Fix

Configure Client Proxy settings in StoreFront to None instead of the default “auto”. Use this CTX article http://support.citrix.com/article/CTX136516

Thanks,

Arun.

On my recently completed project, I spent quite a bit of time debugging Storefront as I missed seemingly irrelevant but important practices. I also burnt my fingers few times because I failed to fully understand the basic principles of a redundant and fault tolerant Storefront implementation from a design perspective.

The following are the 3 important things that I learnt:

Always have two Storefront Server Groups and not ONE.

Why?

Previously, in a typical Web Interface implementation, we have two WI servers load balanced by a NetScaler LB. WI servers are nothing but IIS servers which are independent of each other. Each WI server needs to be configured individually and doesn’t have any dependency on the each other.

However, Storefront servers are different. Though Storefront is also an independent IIS server, but when joined in a server group propagates changes from the master Storefront server (the Storefront server on which the change is made and you choose to execute “Propagate changes”) to all other servers. This implies that if there is bad configuration on one of the Storefront server and you propagate changes from that server, all the servers in the server group gets affected and that makes the server group a single point of failure. And this happens more often than you think. Hence, there is a need for a secondary server group.

What’s a good practice?

• Create two Storefront server groups with the same base url. Each server group is recommended to have 2 or more Storefront servers.
  
• Create two NetScaler LB Service Groups for each of the Storefront server groups.
  
• On the NetScaler LB VIP for Storefront, only one Service Group will be active at any point in time. The other Service Group will be a “Backup vServer” which will be active only when first Service Group is down.
  
• If your environment does not have NetScaler, I suggest having a secondary URL for the secondary Storefront server group. For example, let the first Storefront server group have the base url storefront.company.com and the second one being storefront1.company.com. Though it may look untidy and may require users to key in another url on their browsers if their first url is not functional, it still allows them to login and consume their desktops and apps.
  

Adding Domain user to Local administrator group of Storefront Servers

Until recently I used to add users to “local administrators” group of a machine through “Restricted Groups” which is a horrible idea with bad consequences. Since it removes all other users from “local administrators” and only keeps what you specified in the “restricted groups”, it breaks Storefront as storefront places few built-in users into “local administrators”.

This is how the local administrators group of a Storefront server looks like soon after installation of Storefront.

As you can see there are accounts such as CitrixClusterService and CitrixConfigurationReplication that are local accounts also added automatically into the local administrators group during installation. These accounts must remain there for Storefront to function correctly. Using “Restricted Groups” removes these accounts and replaces them with only those domain user accounts that you specify. So refrain from using “Restricted Groups”.

Here the right way of adding a domain user as a local administrator on a machine. Use a GPO -> Computer Configuration -> Preferences. This way, it just adds users to the group and doesn’t replace the existing users who are already in the administrators group.

Base URL resolution

Storefront server group is always configured with a base url. Base url is just a FQDN such as storefront.company.com that points to the NetScaler load balancing VIP for Storefront. This VIP will translate to one of the Storefront servers’ IP address.

But sometimes I ve observed that it may not resolve correctly resulting in the occasional dreaded error “Cannot complete request”. If you check the error logs, you will find that the Storefront “Discovery Service” has failed.

The Discovery Service can fail due to many reasons but more often than not it’s because of DNS resolution of the base url to one of the Storefront Servers. Discovery Service is nothing but a service that runs on every Storefront server that queries data about itself. It contacts the base url which returns the IP address of one of the Storefront servers’ IP address. It uses that IP address to fetch the required information.

But the simple fact is that all the information that a Storefront server ever needs is already known to itself and it doesn’t need to go via the long path of contacting the base url -> NS LB VIP -> Storefront IP.

So I suggest to you create a “hosts” file entry on every Storefront server for base url to point to its own IP address. For example, if the Storefront IP address is 10.1.1.12 and base url is storefront.company.com, I suggest create a hosts file entry for 10.1.1.12 storefront.company.com. This way when the discovery service runs, it doesn’t need to go to the NetScaler LB VIP and then resolve to one of the Storefront servers, instead it can just get all the information from itself. Hence the discovery service of the Storefront Server does not depend on NetScaler or DNS for it’s functioning.

You must be wondering that DNS and NetScaler are perhaps fundamental blocks it is supposed to be working reliably all the time, which is true. But I was quite surprised by the number of times people make random configuration changes to DNS records, clearing caches, adding aliases, reusing URLs and so on. So fewer dependencies, better.

• RPC
• Baseline Filtering
• COM related Services
• Baseline Filtering Service
• IPSec related services
• Print Spooler Service.

If you are installing XenApp 5.0 on Windows Server 2003 SP2, please ensure that the following services are turned on.

• RPC (Remote Procedure Calls)
• Server
• Workstation
• Windows Management Instrumentation Driver Extensions
• IPSec related
• Print Spooler service
• COM related services

Thanks,

Arun.P.C

Though this topic is covered at many places, I couldn’t locate one that was direct, simple and concise. Hence writing this on my own.

Backing up

• On the Web Interface Server, stop the IIS Server. On the command line of the Web Interface server type “iisreset /stop”
• Create a backup of the site folder. For example: Backup Xenapp to Xenapp-backup
• Start the IIS Server. Type “iisreset /start”

Restoring Web Interface

• On the Web Interface Server, stop the IIS Server. On the command line of the Web Interface server type “iisreset /stop”
• If you have site created already with the name of the backup, you may just rename to backup from Xenapp-backup to Xenapp,
• On the Citrix Web Interface Management Console, select the site, right click and select “Repair”. This will reload the site properties and as good as the fresh website.
• Start the IIS service by typing “iisreset /start” on the console.

Related article:

http://support.citrix.com/article/CTX114889/

Thanks,

Arun.P.C