In May a blog article was posted on the Citrix website announcing a new feature VDA upgrade. With this functionality Citrix is offering a possibility to upgrade the Citrix Virtual Desktop Agent (VDA) on persistent VDIs from the Citrix consoles. This functionality is only available in the DaaS service (formerly known as CVAD Service/ Citrix Virtual Apps and Desktops Service). In this article I will take a look at this functionality.

While the transition to the Cloud is really starting also the move to the Citrix Cloud for the CVAD Control Plane components is becoming reality. Some organizations will make move the VDIs/Multi-session hosts to a Cloud platform as well, but there will be also a group that will keep the VDIs/Multi-session hosts still within their own on-prem datacenters. When using persistent VDIs (without Citrix provisioning techniques) one of the logical requirements would be that the user will be able to connect to his own VDI after the move to CVAD service. In this article I will discuss the possibilities to arrange this movement with preserving the current assignments.

I think most of the Citrix admins have already seen this behavior but did not bother much as it was just an IT admin that has the issue or a few sporadic users. However in some cases it can hit a lot of users and you need to do something about it. At a customer we run into this issue during the migration to Citrix Cloud, so I quickly created a script to fix this for their scenario. In this small article I will explain why the behavior is there and of course the script to fix it quickly.

When you are a returning visitor on my website you probably already know that I have done several product selections for VDI monitoring. Out of those selections I have knowledge and experiences with a large list of monitoring solutions around the VDI landscape…….for Windows operating systems. When a customer asked me to execute a product selection for Linux VDIs with the focus on End User Experience monitoring I could not use lot of my experiences. In this article I will write down my experiences during the product selection.

It does not look that long however the first version of the Linux VDA is already released almost six years ago. Citrix did work hard on the Linux VDA and added lots of functionality and enhancements in those six years. What I hear out of the field Linux VDAs are still a niche market, but the demand is growing especially in engineering companies. When you are a Windows guy (just like me) and start working with delivering Linux VDAs you will see there is still a (big) gap that (can) bring some challenges. In this article I will give my opinion where I see challenges with a Citrix Linux VDA.

For one of my customers we were optimizing actions, configurations and connections between the datacenters. One of the goals was to connect the VDIs in the datacenter to supporting components in the same datacenter while using one central image (PVS vDisk in this case). Not a big thing in my mind, but shortly somebody asked something similar. So probably there is a demand for it. In this short quick article I will share what I have set-up.

With the COVID-19 crisis the use of video meeting “products” became even more important than it already was in 2020. Logically the higher demand also caused that such functionality also needed to be started within a Citrix session. Beside the big ones like Zoom and Teams, there are also lot of other platforms. Although the use of webcam in Citrix is not rocket science, I noticed several questions/issues at customers. In this article I will dive into the requirements and configuration required to use a webcam within a Citrix session.

The infrastructure of Citrix Virtual Apps and Desktops (formerly known as XenDesktop and/or XenApp) exists of several components. Also Citrix Virtual Apps and Desktops need to communicate with other components within the total IT infrastructure. In this article I will go through the several components and their communication ports with other components.

In the earlier article How to combine multiple Citrix environments within different domains I discussed the possibilities to combine multiple Citrix environments available within different domains. With one of the solutions was based on SAML authentication, which has the disadvantage that you still have two access points. In this article I will go into more details which options you have to combine such a solution into a single portal.

Logically the number of sites is part of each Citrix Design. This topic is also addressed in the Citrix Virtual Desktop Handbook. There are three reasons specified in the handbook which validate the use of multiple sites: network, risk tolerance and security. The guideline however is to keep the number of XenDesktop sites (should we now call those Virtual Apps and Desktop sites?) should be kept to a minimum to reduce architectural complexity and administrative effort. I totally agree on this topic, but next to design environment other factors are there causing that multiple Citrix sites are in the picture which are not designed with multi-sites in mind. Reasons could be the acquisitions/mergers of companies or out-sourcing a business application to an Application Service Provider (ASP). In this article I will focus on this kind of multisite scenarios and what the options are to combine those from an end-user perspective.

For one of my customers I needed to set-up a Citrix FAS environment for using SAML authentication to achieve a single username and password (and providing this information once). To verify that the goals would be reached I first set-up Citrix FAS into my own (demo)environment, followed by a production environment on the customer infrastructure. I did this based on instructions created by fellows in the Citrix community and logically the Citrix documentation. In this article I’m not going to create another configuration article as those are already available. I will point you to these articles and share in this article tips and tricks of occasions I encountered. Most are already available somewhere on the Internet, but it is scattered and not always issue to found.

As a consultant I’m mostly engaged at the larger companies (large for the Dutch market) the Citrix Cloud was not come along my path a lot. Logically I followed the progress and enhancements made to the services. Recently I got involved at a smaller customer with currently did not have a Citrix environment yet (the party they acquired are using Citrix, so that’s why Citrix came into play). A perfect fit for Citrix Cloud as the environment is pretty small and the IT organization is not really familiar with Citrix. As size does not matter, the organization had to comply with specific regulations that are similar as Enterprise organizations.  However during the design phase and Proof of Concept phase we found out that there are still gaps between the on-premises and the cloud offering, that could cause that the Citrix Cloud solution is not ready yet for all/your organization(s).

In the earlier articles I wrote down how to install unattended the XenDesktop components. The article was based on the versions of XenDesktop 7.6 till XenDesktop 7.15 (dependent of the article).

It has been a while that I updated this article series. In this (small) article I will describe the uninstallation options for the most current version out there 7.15 CU2 and 7.18 (CR).

In the second part  we discussed the steps under the hood for each MCS deployment type when creation the machine catalog, when VDAs are added and what happens when the user session is ended. In this part we will continue with the steps when updates are required on the base disk and more detailed information about the configuration settings during the Machine Catalog wizard.

In the first part article we discussed the first steps for creating and maintaining Citrix Machine Creation Services (MCS). We talked quickly about creating the master image, followed by the available MCS deployment type with their characteristics. In this article we will discuss what happens under the hood when creating a MCS machine catalog per deployment type.