Pointers for setting up, optimizing and customizing a Windows 11 Multi-Session image for Citrix DaaS

Introduction

In order to run Citrix Virtual Apps and Desktops with Multi-Session machine catalogues, one requirement has always been that the target machines must run a Windows Server operating system. Besides correct Citrix licenses, RDS CAL licenses were necessary as well for allowing the multi-session setup to come into existence.

Enter the dawn of Azure Virtual Desktop and the fact that a majority of my Citrix DaaS clients have already resorted to Azure as their resource location of choice, the playground has changed.
You see, when AVD released together with the Windows 10/11 multi-session SKU’s (unique to the Azure platform) the license requirement included the Microsoft 365 E3/E5 licenses, in which almost all of my Citrix DaaS clients already had for ensuring that their employees could use Microsoft 365/ Office apps.
To put it simply, it virtually became a no-brainer to migrate these clients’ Citrix DaaS workloads to a Windows 11 multi-session SKU, therefore cutting license costs by not needing to renew the expensive RDS CAL licenses anymore.

Having worked intensely with both Azure Virtual Desktop and Citrix DaaS with Azure as the resource location, I figured I would share some pointers, tips and lessons learned on what a baseline configuration of the Windows 11 multi-session image could consist of. This with the perspective of the image being used primarily in a Citrix MCS catalogue and in a non-persistent scenario.
Keep in mind that this is not a complete outline and that some recommendations could be irrelevant depending on your case. I have personally not seen a similiar writeup and merely want to share a guideline to lean against should this be a new type of setup for you! 🙂

Continue reading “Pointers for setting up, optimizing and customizing a Windows 11 Multi-Session image for Citrix DaaS”

A lesson when relying on the FQDNs allowlist for Citrix Cloud Connectors

INTRODUCTION

If you are working regurlarly with Citrix Cloud it may be common knowledge by now that the fundamental connectivity requirement of the Cloud Connectors, on each resource location, is to open up port 443 for outbound connections towards the Internet.

In my experience this is fine and dandy and all, however this won’t be enough for a client’s criteria sometimes. Occasionally we need to jot down the explicit domain names (FQDNs) in which the Cloud Connectors accesses, thus only open up the standard HTTPS port towards these known FQDNs.
This very demand was something I was recently met with so in this post I will share a lesson on pursuing this route.

Continue reading “A lesson when relying on the FQDNs allowlist for Citrix Cloud Connectors”