July 22, 2020

Don't Use Your Physical Image in Your Virtual Environment

Are you using SCCM, WDS or other deployment tools or have been asked to when deploying your virtual desktops or virtual application servers? If so, there can be some serious issues with this. I am often asked about by folks wanting to deploy Citrix or VMware Horizon images using the same image that is used for physical endpoints. Not only is this a bad idea, it can present performance ramifications and also make it so that best practices are not followed.

I always have been a believer that hand building the operating systems for virtual desktops and application delivery servers is the best approach because it ensures we know what went into the image. I understand the grips of manually installing the applications and the extra work but the extra work now can save a lot of headaches later and the reason of "this is how we build out images" is not a good enough reason to justify using the same image in the virtual environment.  Often and in most cases the deployment person and the virtual desktop environment are not the same person. They build images on physical endpoints or on a completely different hypervisor, they never optimize the image and just let things fly. Since these are physical endpoints they have dedicated hardware and rarely if ever do they experience any issues from being unoptimized. In the datacenter, on a virtual desktop or an application delivery server which share host resources with other virtual machines we need to optimize things as much as possible.

Here are two examples of recent environments where there were issues with using SCCM to deploy the same image as physical endpoints:

  1. First was in the medical field and the customer wanted to move from persistent Windows 10 desktops to pooled non-persistent virtual desktops as the administrative overhead of having a persistent desktop and having to administer the desktops with deployment tools was not feasible. Also, when presented with justifying the need of having a persistent desktop pool and having the response be “that is how we have deployed it before” there really was no reason to have it. When it came time to build the Windows 10 non-persistent image, the customer completely disregarded my suggestion on building the Windows 10 base image by hand and used WDS to deploy the “standard” image that is deployed on physical endpoints. The end result was that a known bug in the image in which the start menu stopped responding to left clicks. This bug also existed on physical endpoints but was hacked around by copying profiles over the default profile but when this was done on the non-persistent desktop image, it caused Citrix Profile Management to create temp profiles on each login. After countless days of the customer trying to remediate this, the only successful way to do so was to break out the iso and install the operating system by hand and manually installing the applications and everything is functioning correctly. 
  2. A second example of this was a large law firm migrating from an on-prem Citrix environment to VMware Workspace ONE. When it came time to build their images for the RDS Linked Clone pool they stressed a need to use an existing task sequence that was built for Windows 10 and force it to target a Window Server 2016 operating system. The issue here is that applications were installed before the RDS Session Host role was installed afterwards. It has commonly been a known and best practice for RDS Session Hosts servers that the RDS Session Host role to be installed prior to installing applications due to the need to potentially capture applications settings into the RDS shadow key. In this environment, there are small abnormalities in application behavior even today due to the incorrect installation sequence.

Long story short, when building the images for your virtual desktops and application delivery servers be careful how you approach this. As the common adage is "you can’t build a house on a bad foundation" and doing things incorrectly could lead to a bad user experience.

Johnny @mrjohnnyma

July 6, 2020

Citrix License Usage Insights


This article describes a new Citrix Cloud service, License Server Usage Insights, that is available to all Citrix Virtual Apps and Desktop customers. Read on to find out why I think this is a big deal especially for customers that that have not transitioned to Citrix Cloud subscription licensing (aka own perpetual licenses).

Trend View: day view but month and year available


If you have a single on-prem Virtual Apps and Desktops license server OR have completely transitioned to the Virtual Apps and Desktops service then this new on-prem License Usage Insights may not be for you because Studio gives you a good view of license consumption.

This new service may be beneficial if you have a larger environment that has gotten complicated over the years and there is not a simple answer to, "how are we doing on Citrix licenses?".

Beneficial Scenarios

  • You are a Citrix architect or admin and use Excel to calculate Virtual Apps and Desktops license usage across your enterprise
  • Or you have more than one license server (for whatever reason)
  • Or you have license servers in completely separated Active Directory forests
  • Or you have more than one license type and this includes both Virtual Apps vs Virtual Apps and Desktops OR you own both concurrent and user/device licensing
  • Or your management likes to see pretty graphs of Citrix consumption from time to time
  • Or you would like to give someone in your organization access to consumption but do not want to give them RDP access to the actual Citrix license servers
  • Or you spend time logged into citrix.cloud.com and it would be more convenient to view license consumption there


If one or more the scenarios above apply to you then read on. License Server Usage Insights connects your on-prem license server(s) to Citrix Cloud. It can then aggregate usage from across many license servers and present them in a pretty dashboard.


  1. Upgrade your license server. You will need to be running version or newer. Download the license server here https://www.citrix.com/downloads/licensing/. Upgrade instructions https://docs.citrix.com/en-us/licensing/current-release/upgrade.html
  2. Enable Call Home on the license server.  If you do not have this enabled you will not get the blue "Register" button shown in the screenshot below. See the link in the next step for the details.
  3. Register the license server with Citrix Cloud https://docs.citrix.com/en-us/citrix-cloud/citrix-cloud-management/citrix-cloud-on-premises-registration.html
  4. Wait 24 hours for it to report in the first time. This is a very important step.
  5. Login to citrix.cloud.com and check. As mentioned above, no matter how many times I refreshed the page, it did take 24 hours to populate. Click on the menu on the left and choose Licensing.

You didn't think I would show a real code?

Click Register

FWIW, Citrix license server upgrades were a standard practice back when I was consulting anytime I was upgrading anything in the environment. Not only would you typically get security improvements and bug fixes but it would ensure that a component upgrade would not get halted due to newer license server requirements.

That is all there is to it. I hope this gives you better visibility into your environment.

SageLike Post ID: SL0025

Applies to:


Brian @sagelikebrian