I’m currently working on a project where I’m migrating the customer’s users to a newly created Citrix Virtual Apps and Desktops (CVAD) environment based on Windows 2019 combined with Nvidia GPUs. This environment is based on Citrix Machine Creation Services (MCS). In the past, they decided to let their VMs run on local storage, which is a relatively normal choice in a small environment. Throughout the project, we needed to update the machine catalogs with a new version of the master image. Luckily this is all based on the code, so every image is recreated from scratch. But after every change, we needed to update the Machine Catalog using MCS. That’s usually not an issue if you use shared storage and have plenty of resources.
As you can guess, this isn’t the case with this customer. They have six hosts with GPUs and use local storage, as mentioned before. Within Citrix Studio, you create a Hosting Connection where you specify the storage used. As the customer uses local storage, you must select the local storage repository (SR) from all hosts.
When you update a Machine Catalog with a new version of the master image (Snapshot) during the MCS process, it will start a preparation VM when the copy task is completed. This VM is based on the original VM (Snapshot, which is just uploaded), So Memory, GPU, and CPU, but the network is disconnected. This is when the problem starts. Because Citrix studio can’t look at the available resources within a Hosting Connection, it will start the preparation VM on the first available host within the Cluster or Pool. When this host has no resources available, you get the error NO_HOST_AVAILABLE.
Solution
Citrix cannot look at the resources available from the hosting connection mentioned in this Support Article, so you need to look at other options. In our case, as we have a static environment and use GPUs in passthrough mode, we selected one host where the resources are available to start the preparation VM. To achieve this and make sure the preparation VM is always started on that host, the only option is to edit the hosting connection and only select the SR for that host. After this, all the Preparation VMs will start on that host, and every Machina Catalog update will be successful. The screenshot shows that the host used for the preparation VM is CH4 (Citrix Hypervisor).
Conclusion
Every company likes to use all the resources available within its environment. Of course, they will know they need to update the Master Image and need resources for the preparation VM. Still, it’s sad to see it’s not possible to specify one host within the studio to act as a Preparation VM host. Suppose you only have shared storage combined with GPUs and/or limited memory and don’t use the local storage within a hypervisor. Then you are screwed, it could be that the preparation VM is started on a host that currently doesn’t have resources available, and your Machine Catalog update will fail.
As a feature request for Citrix, it would be nice if you could specify a host within the hosting connection that will be used to run the preparation VM as long as they can’t check the available resources for the Hosting Connection.
Managing the endpoint and giving your users the same experience across multiple devices is a task that most companies give headaches. The Endpoints that are managed using an Endpoint manager are the least of their concerns, but all the user’s private devices are another discussion. You can’t manage them so it’s hard to configure the installed applications without having access to the device. When looking at the Citrix Workspace App (CWA) you can now control the settings on the endpoint(s) and give the users always the same experience on all the devices they use. Citrix gives companies (and their Citrix administrators) access to the Global App Configuration Services (GACS). GACS has multiple benefits, The two most important ones are:
It gives users the possibility to use their company e-mail address to configure the Workspace App (Discovery Records APIs)
You can configure the settings for the CWA on the user’s endpoint as mentioned before (Setting Records APIs).
I will help you make use of both the benefits; you can easily follow the guides below to set up a basic configuration and get you up to speed with using GACS.
Requirements
To make use of the Global App Configuration Services we need to look at the requirements:
Citrix Cloud Account
To get started with GACS you need a Citrix Cloud account with an active Citrix Workspace entitlement. This means that you need Citrix Cloud licenses, it doesn’t work when you only create a Citrix Cloud account sadly.
Domain Claims
The second requirement is that you need to claim your domain and if using an on-premises environment also claim your gateway URL. To claim your domain (and when needed your gateway URL) follow this guide.
Workspace App version support
Your users need to have a specific version of the Workspace App, see the below list:
CITRIX WORKSPACE APP PLATFORM
MINIMUM VERSION SUPPORTED
Windows
Current Release – 2106, LTSR – 2203.1
Mac
2203.1
iOS
2104
HTML5
2111
Chrome OS
2203
Android
2104
When your company meets the requirements, we can start configuring Global App Configuration Services:
Setting up Domain name configuration (Discovery Records APIs)
The first thing that you need to set up and give your users a better adoption of your (new) Citrix environment is to make it possible to use their company’s e-mail address to configure the CWA.
First we need to use the getAllDiscoveryApiUsingGET
Click on the “Invoke API” Button.
Set the values in the Header Parameters as follows:
Accept = set to “application/json”
Authorization:
Click the “Generate here” link
Client ID = API ID
Client Secret = API Secret
Citrix-CustomerId = Is the customer ID that you can find within Citrix cloud > Identity and Access Management > API Access.
Citrix-TransactionId = leave empty for now.
Click the “Execute” button
Make sure you receive the following response HTTP/1.1 200
Download the JSON and save it somewhere (you may need it as reference).
Now we go to the postDiscoveryApiUsingPOST
Click on the “Invoke API” Button.
Set the Header Parameters the same as in step 1
Set the Path Parameters value:
App = Workspace
Set the Body Parameters:
Fill in the ServiceURLs : https://<customname>.cloud.com:443
Fill in the claimed domain name = <domain>.<root>
Click the “Execute” button
Now we go to the getDiscoveryApiUsingGET
Click on the “Invoke API” Button.
Set the Header Parameters the same as in step 1
Set the Path Parameters value:
App = Workspace
Domain = <domain>.<root>
Click the “Execute” button
Now we go to the putDiscoveryApiUsingPUT
Click on the “Invoke API” Button.
Set the Header Parameters the same as in step 1
Set the Path Parameters value:
App = Workspace
Domain = <domain>.<root>
Set the Body Parameters:
Fill in the ServiceURLs : https://<customname>.cloud.com:443 (Make sure you type https, otherwise you receive an error message: Errorcode 3FF)
Fill in the claimed domain name = <domain>.<root> (same as step 2&3)
Click the “Execute” button
Now you can use your mail address to setup you Citrix Workspace App and you don’t have to give users the complex Citrix Workspace URL.
Now that we have made it easier for the end-user to configure the Workspace App, let’s start with the configuration of the Workspace app so this gives the user always the same experience.
Configure the Citrix Workspace App (Setting Records APIs)
The second part is the hardest part, as you need to create a JSON file that sets all the required settings, you can find an overview of all the available settings here. Below you see an example that’s also mentioned within the documentation.
To start, use the example Citrix created in their documentation, and add/remove the settings you wish to control. Make sure you verify the JSON before you try to use it in the Settings Records APIs.
Now we need to use the getAllSettingsApiUsingGET (If this is the first time you start with the Settings Record APIs, you can skip this step. You will receive a 404 error if there is no config.)
Click on the “Invoke API” Button.
Set the values in the Header Parameters as follows:
Accept = set to “application/json”
Authorization:
Click the “Generate here” link
Client ID = API ID
Client Secret = API Secret
Citrix-CustomerId = Is the customer ID that you can find within Citrix cloud > Identity and Access Management > API Access.
Citrix-TransactionId = leave empty for now.
Click the “Execute” button
Now we go to the postSettingsApiUsingPOST
Click on the “Invoke API” Button.
Set the Header Parameters the same as in step 2
Set the Path Parameters value:
App = Workspace
Set the Body Parameters:
Use the JSON file you created in step 1.
Click the “Execute” button
Now we go to the getSettingsApiUsingGET
Click on the “Invoke API” Button.
Set the Header Parameters the same as in step 2
Set the Path Parameters value:
App = Workspace
URL = Based 64 URL Encoded To get a Base 64 URL Encoding, I used the following site: https://www.base64url.com/ There I used the ServiceURL and that generated the Base 64 URL Encoding.
Click the “Execute” button
Now we go to the putSettingsApiUsingPUT
Click on the “Invoke API” Button.
Set the Header Parameters the same as mentioned in step 2
Set the Path Parameters the same as in step 4
Set the Body Parameters:
Use the JSON file you created in step 1 and used in stap 2.
Click the “Execute” button
You receive a Warning that you will change the production environment. Click Continue
Verify the settings using the Citrix Workspace App
Now that we have configured our required settings, let’s test it. I use the following setting for android, which sets the Audio Streaming but doesn’t allow the user to change (UserOverride: false) it as you can see below:
In the Screenshots from my Android Phone, you can see that the Workspace App is configured as mentioned.
Changes are active approximately 10 minutes after an Admin change anything, according to the Citrix documentation:
How does the service work?
From the client-side, the developer applies the following Citrix Workspace app settings that an admin provides:
The settings are delivered to the workspace app clients through the Content Delivery Network (CDN) URL. Admin adds settings for each URL and the client decides which setting to load as default serviceURL.
After an admin updates the settings on the Global Apps configuration service the CDN URLs are updated. It takes 10 mins approximately to purge the cache.
The Citrix Workspace app client team calls the CDN URL at regular frequency to fetch and update the latest settings on the Citrix Workspace app.
Conclusion
The Global App Configuration Services makes it possible to make it easier for your users to access your Citrix Environment, it also makes it possible to configure the Citrix Workspace app without access to the endpoint. As shown it’s not easy to setup and it toke me some time to figure it out. Hope this helps you get started with this nice feature.
The default traffic flow isn’t optimized when designing a new Citrix Virtual Apps and Desktops services (CVAD) environment. There are a couple of options that would result in a better traffic flow. The more you optimize the traffic flow, the better the User Experience, and I think that’s what everybody wants because happy users make happy admins. Some options are only for on-premises deployments, while others are for both on-premises and public cloud deployments. This article shows some options that don’t need any massive changes and are easy to implement.
The Default
The default traffic flow isn’t optimized, and it depends on a couple of different components that could all result in latency. When one of these components fails, it results in a disconnected session or even downtime. To better understand how the current traffic flows, look at the diagram below.
Default CVAD traffic Flow
As you can see, all traffic goes through your Cloud Connectors, causing a high dependency on your Cloud Connectors. That’s why you would like to have them redundant and give them the appropriate resources.
Now that you understand the default traffic flow, it’s time to look at the options to optimize your traffic flow and realize a better user experience.
Rendezvous Protocol Traffic flow
The first option to optimize your traffic flow is the Rendezvous protocol. With this option enabled, your users don’t depend on the Cloud Connectors when they have a session. This option is available for public Cloud, Private Cloud, and on-premises. Whit every new Citrix Virtual Apps and Desktop Services deployment, this option is enabled by default, but current deployments could benefit from enabling this option.
What’s the benefit of this for you and your end-users:
The user doesn’t notice any delay if the Cloud Connectors are overloaded or fail.
As the cloud connectors no longer proxies the VDA-Gateway traffic makes them more scalable.
Have a look at the below diagram where the Rendezvous protocol is enabled
CVAD Rendezvous Traffic flow
Requirements and validation
As mentioned before, Whit every new Citrix Virtual Apps and Desktop Services deployment, this option is enabled by default. An updated and detailed list of the requirements is available here. Below are some of the requirements you should take a look at:
Access to the environment using Citrix Workspace and Citrix Gateway service.
Control Plane: Citrix Virtual Apps and Desktops Service (Citrix Cloud).
VDA: Version 1912 or later.
2012 is the minimum required for EDT Rendezvous.
2012 is the minimum required for non-transparent proxy support (no PAC file support).
2103 is the minimum required for proxy configuration with a PAC file.
The VDAs must have access to https://*.nssvc.net
The VDAs must be able to connect to the addresses mentioned above on TCP 443 and UDP 443 for TCP Rendezvous and EDT Rendezvous, respectively.
Cloud Connectors must obtain the VDAs’ FQDNs when brokering a session. Accomplish this in one of these two ways:
Enable DNS resolution for the site.
DNS Reverse Lookup Zone with PTR records for the VDAs.
If you meet all these requirements, you can validate if the rendezvous protocol is enabled. The first thing you should look at is to see if the policy is enabled. This option is enabled by default but could have been disabled by another admin or a previous deployment. Below you can see the policy enabled.
When the policy is configured correctly, you can validate if the rendezvous protocol is working by following these steps:
Launch PowerShell or a command prompt within the HDX session.
Run ctxsession.exe –v.
The transport protocols in use indicate the type of connection:
TCP Rendezvous: TCP > SSL > CGP > ICA
EDT Rendezvous: UDP > DTLS > CGP > ICA
Proxy through Cloud Connector: TCP > CGP > ICA
Direct Workload Connection Traffic flow
When you have configured the Rendezvous protocol and notice it, your users undoubtedly notice this next option. The downside of this next option is that it requires that your workload is on-premises or your branch offices have a direct connection to your data center.
The default traffic flow and rendezvous protocol traffic flow directs all traffic through the Gateway Service, even when you sit next to your VDA. We don’t want to take a detour while you can use a direct route. A direct route gives us fewer dependencies and the best user experience, and that’s when Direct Workload Connection comes in place.
Whit Direct Workload Connection, your internal users connect to the VDA directly, without the traffic going through the Gateway Service. Although there are numerous Points of Presence (PoPs) for the Gateway Services to reduce latency, this is never the most optimized connection for internal users that connect to an internal VDA routed through an external Gateway. That is causing latency, and latency causes unhappy users.
How does Direct Workload Connection work?
When a user connects to the Citrix Cloud, the traffic comes from a public IP address. This address is used to determine if the user is an Internal or External user. But before Citrix Workspace knows which Public IP Address is associated with your on-premises VDA and internal users, you need to create these locations in your workspace management plane.
But why shouldn’t you use the internal Ip address, you would think? The answer is relatively simple. When using the endpoint/internal IP address, we quickly would run into issues. How many users, public places, and customers you visit have the following internal-only IP Address scheme (10.0.0.0, 192.168.0.0, 172.16.0.0)? Suppose you connect to Citrix Workspace with an endpoint with an IP address the same as you defined as internal. In that case, Citrix Workspace thinks you are internal and tries to bypass the Gateway Service, resulting in a failed connection.
Below you can see the diagram of how Direct Workload Connection is working. As you can see, the internal user has the same Public IP (I think everyone knows this one) as the VDA, which means the internal user connects directly to the VDA. The External user has a different Public IP address (non-existing) as the VDA, so this traffic goes through the Gateway Service.
To add the public IP addresses of your on-premises environment and branch offices that have a direct connection to your data center. Sign in to Citrix Cloud and go to the “Network Locations”, there you can see all previously added locations and add a new Network location.
Validate Direct Workload
There are two options to see if Direct Workload is configured correctly and is working
Option 1: Using the Citrix Director Go to a user’s session and then go to the Details of that session, there you see the Session Details. When the Connected via IP address equals its Endpoint IP address, Directworkload is working. See below two examples:
Option 2: ICA file logging
Navigate to the following registry key by using the registry editor:
Then start a new Citrix Session and open the log file, there you see that it shows the VDA’s IP INTERNAL address. See the image below:
Conclusion
There are a few options to optimize the traffic flow as described before. The Rendezvous Protocol can you use on-premises as in the public cloud, where Direct Workload Connection is only an option when you can connect to your VDA’s directly. Both options help you get a better user experience. Your external users will benefit from the rendezvous protocol, where your internal users will benefit from the Direct Workload Connection. All that matters is that happy users make happy admins.
This week we were having issues while connecting to Citrix Cloud using the Powershell SDK (more info) for Citrix Virtual Apps and Desktops services; we received the following error:
An error occurred while making the HTTP request to https://<customerID>.xendesktop.net/Citrix/SdkRouter/V2. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server.
Powershell SDK error
After some intensive troubleshooting, we discovered that it’s a .net Framework security issue. It took us 4 hours to discover this. 🙁
To solve this issue you need to modify the following registry keys:
Where you can change V4.0.30319 to a higher or lower number as it’s compatible with newer releases. That means that if you are using .net V4.8 and change the key in version 4.0 it works and you can use the Powershell SDK to manage your Citrix Cloud environment.
Hope I save you a lot of troubleshooting when you have this issue with Powershell SDK.
In the latest update, Citrix released a new feature called “Reauthentication period for Workspace app”. This enables the Citrix admin to set the reauthentication time for a user. This is one of the most frequently asked questions when I implement Citrix Virtual Apps and Desktops services with Citrix Gateway Services. People authenticate using the defined Identity Provider (IdP) (look here for choosing the correct IdP) and keep signed in, without the need to reauthenticate when they go home and continue to work there.
Yes, they authenticated when they started the Citrix Workspace app, and yes they authenticated when signing into their laptop at home. But for most IT managers it feels strange that when they sign on at the office where conditional access doesn’t require MFA, the user can go home and continue working without authentication with MFA. They think it’s a security risk, which I understand, but everything depends on the security of the mobile device.
Before Citrix released the feature “Reauthentication period for Workspace app” (which currently is in Tech Preview), the only option to control the authentication token is to set it with a GPO or Registry Key. The authentication tokens were designed so a user doesn’t need to reenter their credentials when the system or session restarted. The token is stored encrypted on the device, but it was not possible to set a maximum duration. As of Citrix Workspace app v2106, you are able to disable or enable storing the authentication token on the local device using the Global App Configuration Service
Configuring the Reauthentication period
The default setting requires users to sign in every 24 hours (1 day). You could specify a longer time up to 365 days (I won’t know why you would choose such a long time, but it’s possible). If you specify a longer period than 24 hours, the user always needs to reauthenticate after four days of inactivity.
To change the default reauthentication period, sign in to the Citrix Cloud console, go to the workspace configuration, and select preferences. Scroll down to workspace sessions, where it’s possible to change the current reauthentication period.
Supported Workspace app clients
The following versions of the Citrix Workspace app support this feature:
Workspace app 2106 for Windows or later
Workspace app 2106 for Mac or later
Workspace app for 21.6.5 iOS or later
Workspace app for 21.6.0 Android or later
Supported authentication methods
Staying signed in to the Workspace app is supported for the following authentication methods:
Active Directory
Active Directory plus token
Azure Active Directory
Citrix Gateway
Okta
I personally would like to set the reauthentication time to a shorter time than 1 day, let’s say 12 hours, this makes it more secure and the user will notice that he needs to sign in again when continuing work after going home. For more information regarding the reauthentication period, see the Citrix docs.
As more and more companies are moving from on-premises environments to a cloud and would like to make the best of their investments, we see a great demand in moving to Azure Active Directory (AAD). AAD gives you some benefits as you could utilize Azure Multi-Factor Authentication (MFA) with Conditional Access. With Conditional Access, it’s possible to give users the option to only sign on with username and password from trusted locations (think about HQ and branch offices).
This article explains how to set up a double-hop scenario with Citrix Virtual Apps and Desktop (CVAD) services (Citrix Cloud), where your identity provider (IdP) is Azure AD.
What’s a Double-Hop, and why use it?
A double-hop scenario is when you start a published app from other resources within your published desktop. An example:
You have an app that doesn’t support the OS you would like all users to have. In most situations, this will be Windows Server 2019 for multi-session purposes. The one app that you would like users to open is a legacy app and only supports Windows 2012 R2 as the latest supported OS. As your organization states that you only work with supported configurations, you can’t install this app on Windows 2019. To ensure the user can access the app, you create a dedicated delivery group based on Windows 2012R2 VM’s and use this delivery group to give users access to the app. Those users start this app within their published desktop as a seamless app and don’t notice if they are local or remote.
The above scenario is called a double-hop. As a company, you could have many reasons to use this scenario. Think about:
The app is for archive only;
The app doesn’t support the same OS as the desktop (mentioned in the example);
The app has conflicts with other apps;
The app can only be used by some users, and licenses don’t allow us to install it on the same image as the desktop.
Challenges when using double-hop with Azure AD as IdP
When you sign on to Citrix Cloud with your Azure and open your published desktop, your on-premises environment uses Federated Authentication Services (FAS) to sign on to the VDA. Look at the below diagram to see how FAS is working (thanks to Daniel Feller (https://virtualfeller.com/)).
When you would like to have SSO from your published desktop to Citrix cloud, it’s only possible to use Azure Active Directory Seamless Single Sign-On or using an on-premises StoreFront environment that supports FAS authentication. Azure seamless SSO requires the use of Pass-through Authentication (PTA) or password hash synchronization. The customer where I’m currently implementing CVAD services is transitioning to Azure AD, and they don’t have seamless SSO enabled. That’s the reason we need to use another option to create the double-hop scenario. The only other option, as mentioned, is to install an on-premises StoreFront that supports FAS authentication.
Configuring StoreFront and FAS
In this example, I only have one StoreFront server and one FAS server to keep this guide simple. Below you could see how the authentication is working using a double-hop scenario.
StoreFront & FAS
After you installed and configured StoreFront, we configure it to allow FAS as an authentication method.
First, enable FAS support on your Store, change “/Citrix/Store” to your store name:
Click Manage Delivery Controllers Usually, you would add your On-Premises Delivery Controller here, but now you need to add the Cloud Connectors here. You need to use port 80 (HTTP) and can’t use 443 (HTTPS) as a transport type.
As FAS is already working, the ADMX files are probably in the PolicyDefinitions central Store, so I skip the step to copy these ADMX files. For the StoreFront server, configure a GPO, so it knows which servers are FAS servers.Open the GPO and navigate to Computer Configuration/Policies/Administrative Templates/Citrix Components/Authentication Edit the Federated Authentication Service configure the DNS addresses of your FAS servers Perform a gpupdate /force to make sure the GPO is applied.
As FAS is configured to access your VDA, we only need to change the rule you use for FAS.
Open the FAS Administration Console and go to the tab rules
I only have 1 rule named “Default” click on the Pencil to edit the rule.
Go to Access Control Click Manage StoreFront access permissions
Here you add the Computer account of your StoreFront server. Make sure you remove the default “Domain Computers” as that one denies access. Click OK
Now click Apply, and your FAS configuration is ready for testing.
Testing
After you configured all the settings as described above, It’s time to test the configuration.
When you sign in to your published desktop, your Citrix workspace app (when configured correctly) is signing in to the StoreFront site, and you could start an app that’s published from your start menu. Please try, and let me know if this is working.
Update 16-12-2021: As of Citrix WEM version 2112 that’s just been released this function is also available for on-premises deployments. Read more about this version here.
You could use Citrix Workspace Environment Management (WEM) for a lot of things within your Citrix Virtual Apps and Desktops (CVAD) environment(s). It’s also suitable to use for your workstations, but I don’t see that very often. I only use it for CVAD environments, which includes our own and our customer’s environments. WEM can be used On-Premises with the Current Release or used as a service using Citrix Cloud.
As more and more of our customers are looking to simplify management, including all back-end (Citrix Delivery Controllers, Storefront, WEM Infrastructure) servers, we started to migrate to Citrix Cloud. This gives the customers the possibility to use still On-Premises workloads (Virtual Apps and Desktop VM’s) but makes management of the previously mentioned back-end servers easier as Citrix manages this. Below you could see a diagram of all “Managed by Citrix” and “Managed by Customer” components.
Citrix managed or Customer managed
Multi-Session Optimization
Back in October 2020, Citrix released a new feature called “Multi-Session Optimization,” which I recently discovered when going through the WEM Administration console. Sadly this option is only available within WEM Services and not yet available with the On-Premises release. I think this is a matter of time because Citrix Cloud is always a step ahead of the On-Premises version. Citrix Docs WEM
How it works
Multi-Session Optimization can be used with a supported Multi-Session. When a user disconnects his session, the WEM agents lowers the CPU and the I/O priorities of processes or applications associated with the session. This means that the applications a user leaves active are then managed by WEM and will use fewer resources. When you have large environments with multiple disconnected sessions, users can use the resources typically used by the disconnected sessions, and then you could have more users share a VM. We have multiple environments where users don’t understand how to sign out from their session and click disconnect. This is because they were used to click the start button and then click sign out. Starting with the release of Windows 10 (same layout for Windows 2016/2019), they need to click start and then click on their user’s icon and then select “Sign Out.” We created additional Sign Out buttons for our customers that we pinned to the start menu but, the clients keep disconnecting.
To enable Multi-Session Optimization you open the Citrix WEM Administration Console from your Cloud management page and go to the System Optimization in the user interface. There you see the option Multi-Session Optimization. Now check “Enable Multi-Session Optimization” and click Apply (see image below). To make sure the Agents receive the new setting you could perform a Cache Refresh. After you enabled Multi-Session Optimization you need to monitor this in your environment and if needed you could exclude some Groups or Processes.
Enable Multi-Session Optimization
Multi-Session Optimization in action
For this article, I only used one session to test this newly discovered option, but it shows how it could save many resources if there are multiple users disconnected from the Multi-Session OS. In the first screenshot, you see an active user with all applications open and you can see that this user is using 1.4GB of memory. This is not that many, but it’s just an example.
Active Session
In the screenshot below, you can see that the user is disconnected, and as you would normally see, the memory usage keeps the same or is even higher in this example.
Disconnected Session
After one minute of waiting, the WEM agents kicks in and changes the priority of the resources associated with the disconnected session. You see that the CPU usage goes from 6.4% to 0.1%, and the memory usage goes from 1.5 GB to 262 MB. This could have a large impact if you have multiple disconnected sessions on one VM.
WEM Kicks in
I’m now going to test this in this environment and keep you updated if I have some additional recommendations that would help you keep your users have the best user experience. The need for resources management is getting even more important as users are using more and more resources, and looking at VMs in the Cloud where you pay for CPU and Memory usage this could save you money. Eventually, users need to sign out because that’s the most effective way of saving resources.
Working from home (WFH) requires having a lot of video calls. I noticed a great demand from users that need to attend or organize a video call. The downside is that there are multiple vendors and that a company can’t force everybody only to use one solution. Users receive invitations from multiple organizations, and they all need their own client applications. When using an SBC\VDI based remote workplace, you need to manage all the clients and make sure the video call works great. Luckily, the vendors are working together and making sure that you could have a great experience even when working in a remote session. One of those vendors is Zoom, they have created a client that is created for a VDI deployment. Zoom currently supports Citrix, VMware, and WVD.
How it works
When making a video call the video rendering requires CPU and Memory, when using a multi-session OS this could cause other users to have a degraded performance. The users that are making the video call could notice latency during the call because every moving image has to be rendered and send to the client. To get a better experience Zoom created software that could offload the rendering to the local clients. How is that offloading working?
In most cases, the media plugin will offload the video encoding and decoding and communicates directly to the Zoom cloud, bypassing the VDI infrastructure. All other information is sent over the VDI channel. There are three options:
The three options
Everything is within the VDI and all the resources are used within the VDI, communication is from the VDi to the Zoom Cloud This won’t work with Citrix as described here: https://support.citrix.com/article/CTX270931
Only the Video encoding and decoding are rendered on the client and all communication is going from the Zoom media plugin through the VDI channel to the VDI and from the VDI to the Zoom Cloud.
Most of the communication is going from the Zoom Media Plugin to the Zoom cloud and only the Authentication and window location is going from the Zoom Media Plugin through the VDI channel to the VDI and then connects to the Zoom Cloud.
Installing
Time needed: 15 minutes.
Installing the Zoom VDI Installer in your base image and your client.
Download the latest Zoom VDI Installer client and the corresponding Zoom Media Plugin
This is basically a Next,Next,Finish installation.
Install the Zoom Media Plugin on the Client
To make sure you don’t receive an error when using Zoom, you need to run the installer as an Administrator. Close all Citrix, VMware, or WVD clients before starting the installation. Then follow the wizard.
Verifying Zoom installation
After installing the Zoom VDI and Zoom Media Plugin, the testing starts. I made a Zoom call with myself. As I’m not so photogenic, I will spare you these images. To give you a good view of how it’s working. First, I made a Zoom call (without video in my session as this isn’t working for Citrix https://support.citrix.com/article/CTX270931), you can see there is 9.7% CPU usage. This isn’t that much, but when there are more people on a VM and you share the CPU, this could be affecting the user experience of other users.
Zoom call without the plugin enabled
Below you can see that that the Zoom client shows it’s not connected to any plugin and is working as a regular Zoom client.
Zoom without VDI plugin connected
After the first test, I installed the Zoom Media Plugin (for Citrix) and made another Zoom call. This time I was able to use my local Webcam (Laptop integrated) and as you could see below the CPU usage is 0% within the Citrix Session (First Image) and uses 8.4% CPU on the local workstation (Second image).
Zoom Session CPU usage within the Citrix SessionZoom Session CPU usage local workstation
When looking at the statistics within the Zoom client you now see that the Zoom VDI plugin is Connected. The rendering is now completely offloaded to the Clients workstation and this saves you CPU and Memory on the VM (SBCB\VDI) and gives the user a good user experience during the call.
Zoom Media Plugin Connected
Features
When using the Zoom VDI client and the Zoom Media Plugin, you don’t have all the features that are available when using the Full Desktop version of Zoom. As this changes with every new release, I advise you to look at the comparison matrix that Zoom created and hopefully kees updated: https://support.zoom.us/hc/en-us/articles/360031441671-VDI-client-features-comparison
Tips and Tricks
I will update the Tips and Tricks section if new information is available or I needed to solve an issue that could help you as reader.
As mentioned in step 3, if you don’t install the Zoom Plugin on the local device, you could see an error. I only tested with the Citrix Media Plugin and can’t verify if the same happens with VMware or WVD. The error I received is:
Zoom.exe is using NTDLL.dll from an unknown publisher. Are you sure you want to run this software?
Error when Zoom Media Plugin is wrongly installed.
You could click on Yes as often as you like but that’s not going to work.
There are already many blogs about the pros and cons of using GPUs in VDI and SBC environments. I also would like to point out why I advise the usage of GPUs in these types of environments.
CPU vs. GPU
First, let me explain the difference between CPU and GPU. A CPU is designed to handle a few software threads at a time using its few cores and lots of memory cache. A GPU is designed to handle thousands of threads using their hundreds of cores.
In a production situation, the above difference means that when you have an application that wants to use a GPU but there isn’t one available, it will use the CPU instead. The downside of using a CPU is that it’s slower than a GPU and more expensive. A user can notice this when his programs are sluggish and not performing as expected. You can read more about the difference between a CPU and a GPU here.
VDI/SBC without GPU
In the early days, we had Windows 7 or Windows Server 2008R2 without a GPU and that would work perfectly. Users could do their work as if they were working on a local device. The architecture of the OS and most of the applications one was using, didn’t depend on a GPU. If they needed a graphics card and the server had none, Citrix offered a tool called OpenGL Software Accelerator and the VMware alternative was Soft 3D. This would work for some lightweight applications that required a graphics card and get fooled using the software.
In the last couple of years, we see increased usage of GPU accelerated programs like Chrome, Edge, Firefox, Dynamics, Teams, etc. Windows 10 is also more graphics-intensive than it was with Windows 7. A lot of applications already recommend or even require GPUs. They will function without a GPU but to get the best user experience (UX), you definitely should implement GPUs.
Maintaining the very best UX is exactly why I always advise the use of a GPU. I did several VDI projects where they were creating 3D drawings. In such cases implementing GPU is a no-brainer, because the 3D acceleration completely depends on it. You can read about one of those projects here. Those environments are not the ones that I would like to explain.
Looking back at projects starting with Windows Server 2012, users started to use more and more graphic intensive websites. They started consuming more video content like YouTube, online learning platforms, and websites that are more and more requiring GPU. Both Citrix and VMware developed solutions to keep giving the user the best UX without having to install graphics cards also. The downside of these software solutions is that everything is rendered using the CPU. That means you needed a faster (read: more expensive) CPU and when someone was using a graphics-intensive application, other users could start complaining that their system was slow. This all because the CPU couldn’t handle all requests fast enough.
VDI/SBC with GPU
And then came Nvidia, offering virtual GPUs (vGPU), where we could assign multiple VMs to one physical Graphics Card and give a portion of the card, this is called profiles. First, only Citrix supported this with Citrix Hypervisor (f.k.a. XenServer), and then also VMware supported this type of virtual GPUs. Nowadays we can create more VMs on the same physical server because we can assign more VMs to one GPU graphics card.
This all had a positive effect on the return on investment (ROI) for a VDI or SBC environment with GPU cards. Because of the profiles, we need both fewer physical servers and CPUs, resulting in less Rackspace, less maintenance, and fewer investments. Now we can start using the vGPU more often and help users get the best UX with the new and more graphics-intensive applications.
Almost always a GPU
Nowadays we almost always advise customers to buy GPUs for their VDI/SBC environment. We have a couple of reasons why we don’t advise GPUs:
When they have a small number of VMs (≤ 4) and adding them to their already existing backend VMware environment. To use the GPU profiles, VMware requires the use of VMware vSphere Enterprise Plus. When customers don’t already have an Enterprise Plus license, it’s usually too expensive to add GPUs;
That it’s just a temporary environment because they are migrating to local machines or the cloud.
Usage, some customers are using the EUC environment just for some users or only when they have to work in remote offices. When this isn’t a daily situation, we can decide to only use CPU.
Conclusion
Based on the above pros and cons, you definitely need to consider GPUs when upgrading or migrating your VDI/SBC environment.
In the beginning of this year I was asked to look at a Citrix Virtual Apps and Desktops (VAD) environment which wasn’t performing great. Customer’s users were constantly complaining about performance and stability. The environment was set up in a mix of outdated software versions, which weren’t always compatible with each other.
I was asked to look into this matter and create a working environment with the current Windows 10 version on their existing hardware. We also offered a temporary server with the latest Nvidia T4 graphics card, to let them experience the enhanced performance with this new kind of graphics card. A Nvidia T4 card is a graphics card that offers GPU’s, so the VDI’s (or RDS) can perform more powerful tasks than integrated graphics adaptors do.
The Proof of Concept (PoC)
I started of with a simple single non High Available (HA) “design”, where we combined as much components to one server as possible. This was done from both a cost and management perspective.
I prefer to work with software I have experience with, so I installed Citrix VAD 7.15 LTSR. Yes, this isn’t the best version to show every new 3D HDX improvement, but it is a very stable version and we were sure we could provide the customer a much better experience than they were having before. We installed all the required applications within their new golden image, without optimizing them or check for Win10 compatibility.
After a week the PoC users were able to test their brand new workspace and informed us constantly how they experienced the new PoC desktop. The results were great. Everyone was enthusiastic and could do their work from anywhere. You can imagine what the experience could be after best-practice deployment and some finetuning.
Covid-19
And then came Covid-19 ☹ Just a few weeks after the PoC the news came that Covid-19 didn’t stay in China and was spreading around the world. Many countries announced (complete) lockdowns and everybody was obliged to stay home. Traditional office workers were in need of a remote workplace. Our customer asked if it was possible to move and upscale the PoC setup (sized for 10 users max) to a production environment suitable for approximately 100 users. We were able to use existing hardware and expanded the PoC to 30 users at first. By doing so we bought some time for our customer to order new hardware for the rest of the users.
Because of the urgency we offered two separate hardware options. Based on the delivery times they decided to order the hardware that could be delivered as soon as possible. But by then, they weren’t the only company that needed extra hardware rapidly. So in the meantime we provided them with rental hardware instead and we were able to give them the extra resources they needed.
The hardware was delivered in batches because of the poor availability and so in just a couple of days we expanded the PoC with an extra 30 users on their own hardware in a production environment with 100 users, at that time on rental hardware.
Production
During the current Covid-19 pandemic, many customers requested changes and extra resources within their current deployments. Our PoC is still in production, the upside of this is that we now know a lot of design changes which we could do better when creating a complete new design and implementation for this customer. Currently we are planning the design and implementation for a new solid and HA Citrix VAD environment.
