Complete Setup of Citrix Virtual Apps and Desktops 1912 with High Availability and Secure XML Load Balancing

The video begins with a clear outline of the tasks ahead: installing and configuring the Citrix Delivery Controller, creating a Virtual Apps and Desktops 1912 site, adding a second delivery controller for high availability (HA), securing the XML service with SSL certificates, load balancing delivery controllers on the NetScaler, and introducing the Local Host Cache.

"In this video we'll be installing and configuring our delivery control once... we'll be creating our virtual apps and desktops 19:12 site." 0
"We'll also create a load balancing virtual server VIP on our NetScaler for our delivery controllers." 1:08

Key points:

• Installation of delivery controller and site creation using empty databases on SQL Always-On Availability Groups.
• Adding a second delivery controller for HA.
• Securing XML traffic with SSL certificates.
• Load balancing delivery controllers via NetScaler.
• Introduction to Local Host Cache.

---

The installation process starts with mounting the 19.12 media and launching the setup. The presenter emphasizes the importance of hardware specs for delivery controllers, recommending 4 vCPUs and 8-12 GB RAM due to the resource demands of the Local Host Cache.

"It's very important to spec your delivery controller right... I typically set my delivery controllers to 4 V CPUs and 8 gig of memory or 12 gig of memory." 1:50
"You always want 1 or 2 more delivery controllers for high availability." 2:46

Key points:

• Delivery controller installs .NET Framework, C++, and PowerShell prerequisites.
• Recommended hardware specs: 4 vCPUs, 8-12 GB RAM.
• Separate roles for delivery controller and Studio recommended for enterprise environments.
• Ports required: 80/443 for communication with VDAs and StoreFront, license server ports (27000-27079, 8082-8083).
• Automatic Windows Firewall rule configuration during install.

---

Before creating the site, the video covers SQL permissions needed: DB Creator, Security Admin, and DB Owner roles. The presenter shows how to assign these permissions via SQL Server Management Studio, including adding oneself to the sysadmin role for ease.

"You need to be DB creator, security admin, and DB owner... I tend to give myself sysadmin role within SQL." 7:12
"If you can't get sysadmin permissions, you can generate SQL setup scripts for your DBAs." 9:19

The site creation uses Always-On Availability Group listeners and empty databases created earlier. The presenter inputs the database names and listener, then validates permissions and database presence.

Key points:

• SQL permissions critical for site creation and schema updates.
• Use Always-On Availability Group listener for database connection.
• Site named "lon-XD" as an example of regional naming conventions.
• License server connection established, with trust prompt due to missing certificate.
• Site creation populates database schemas and tables.

---

Once the site is created, the presenter explores the Citrix Studio console and the SQL databases. He explains the new database architecture replacing the old IMA datastore with three databases: Site, Monitoring, and Logging.

"The structure of the SQL database has completely changed... we now have three different databases." 16:15
"FMA services connect to the SQL databases using DB connection strings stored in the registry." 17:10

He shows how each delivery controller gets its own SQL login mapped to the necessary databases with appropriate roles.

Key points:

• Three databases: Site, Monitoring, Logging.
• FMA services connect via DB connection strings stored in registry keys.
• Each delivery controller has a dedicated SQL login with mapped roles.
• Runtime permissions are automatically configured during setup.

---

Using PowerShell, the presenter retrieves all DB connection strings for FMA services, highlighting the need to add the multi-subnet failover parameter for Always-On Availability Groups to improve failover reliability.

"We need to add the multi subnet failover string into our DB connection string... recommended when using Always-On Availability Groups." 21:12

Key points:

• PowerShell can list all DB connection strings for FMA services.
• Multi-subnet failover parameter improves failover in multi-subnet clusters.
• Citrix provides scripts to automate this update.

---

The presenter walks through the main nodes in Citrix Studio:

• Machine Catalogs: For creating desktop and server OS catalogs using various provisioning technologies.
• App Disks: Deprecated, replaced by App Layering.
• Delivery Groups: Assign machines and permissions, publish apps and desktops.
• Applications: Organize and configure published apps, including Application Groups (recommended over publishing directly to delivery groups).
• Policies: Can be created in Studio or Active Directory GPOs; warns about conflicts and recommends managing policies in one place only.
• Logging: Configuration logging database stores all site changes.
• Administrators: Role-based access control; recommends creating separate admin groups for full admins and help desk admins.
• Controllers: Lists delivery controllers in the site.
• Hosting: Setup for hypervisor connections (e.g., vCenter, Hyper-V, Azure).
• Licensing: Displays license info and allows license management.
• StoreFront: Defines StoreFront servers for delivery groups.
• App-V and AppDNA: Integration options, not used in this lab.
• Zones: Useful for multi-region or multi-datacenter deployments, allowing satellite zones and zone preference.

"App disks has been deprecated and replaced by App Layering." 22:35
"Policies can be created in Studio or AD GPOs, but only do it in one place to avoid conflicts." 23:44
"Zones are good if you've got multiple regions and mobile datacenters." 33:40

---

The Local Host Cache (LHC) is reintroduced, replacing the older connection leasing. The presenter explains the architecture: a local SQL Server Express instance on each delivery controller stores a copy of the site database for failover scenarios.

"The local host cache is now back... it installs a local copy of SQL Server Express and creates a database for the local host cache." 36:13
"Config Synchronizer service syncs data from the principal broker to the high availability service, which syncs to the local host cache database." 37:07

He discusses event IDs to monitor for successful syncs (505 = success, 505 = failure), common causes of failure (e.g., orphaned SIDs from deleted AD accounts), and the election process for primary secondary broker.

Limitations:

• Pooled VDI desktops do not work well with LHC unless shutdown-after-use settings are adjusted.
• Site management is not possible in LHC mode; SQL must remain highly available.

Key points:

• LHC improves resilience by caching site data locally.
• Sync process involves multiple services and databases.
• Monitoring event logs is critical for troubleshooting.
• Pooled desktops require special handling.
• SQL Always-On remains essential.

---

The video shifts to securing the XML service on delivery controllers, which StoreFront uses to communicate with them. The presenter creates a custom certificate template on the domain CA, allowing private key export and subject alternative names (SANs) to cover the load balancing VIP and individual delivery controllers.

"We want to secure that XML traffic with a certificate... so we'll set up and install our certificates on our delivery controllers." 0:49
"We need to provide all the subject alternative names in the enrollment process because we'll be load balancing our XML service." 43:35

He requests the certificate on the first delivery controller, specifying:

• Common Name: Load balancing VIP DNS name (e.g., CitrixXMLVIP.carmo.com)
• SANs: Load balancing VIP plus each delivery controller's FQDN.

The certificate is then bound to the broker service using netsh commands, requiring the certificate thumbprint and the broker service's app ID.

Key points:

• Custom certificate template created with exportable private key and SAN support.
• Certificate request includes load balancer VIP and individual delivery controller names.
• Certificate bound to broker service via netsh HTTP SSL cert commands.
• This secures XML traffic between StoreFront and delivery controllers.

---

The second delivery controller is installed and joined to the existing site via Studio, which creates the necessary SQL login and permissions automatically.

"Once studio opens we get the option to connect this delivery controller to an existing site... it will create a SQL login for this delivery controller." 55:57

The presenter exports the certificate from the first delivery controller as a PFX file (including private key), copies it to the second delivery controller, and imports it. The same netsh commands are used to bind the certificate to the broker service on the second controller.

Key points:

• Second delivery controller added to site with proper SQL permissions.
• Certificate exported as PFX from first controller and imported on second.
• Certificate binding repeated on second controller using netsh.
• Ensures consistent SSL security across delivery controllers.

---

The presenter logs into the NetScaler and creates a load balancing service group for the delivery controllers using SSL protocol on port 443. Both delivery controllers are added as service group members by FQDN.

"We're going to create a load balancing service group for our delivery controllers... protocol is SSL." 1:06:41

Next, a load balancing virtual server (VIP) is created with an unused IP address. The service group is bound to this VIP.

The previously created certificate is imported into NetScaler by converting the PFX to PEM format. The certificate is then bound to the load balancing virtual server.

Key points:

• Service group created with delivery controllers as members.
• Load balancing virtual server created with VIP IP and SSL protocol.
• Certificate imported and bound to the virtual server for secure communication.
• Load balancing method changed to round-robin (recommended for delivery controllers).

---

A dedicated Citrix delivery controller monitor is created on NetScaler to replace default TCP or ping monitors. This monitor authenticates using a service account created in Active Directory specifically for monitoring.

"We're going to use the dedicated DDC monitor... it probes the backend delivery controllers to make sure they're healthy." 1:15:48
"Created a new AD user account for the monitor to validate credentials." 1:16:06

The monitor is bound to the service group. The presenter tests the monitor by stopping the broker service on one delivery controller, which causes the monitor to mark that node as down, demonstrating effective health checking.

Finally, a DNS A record is created pointing the load balancing VIP name (e.g., CitrixXMLVIP.carmo.com) to the VIP IP address.

Key points:

• Dedicated DDC monitor authenticates via XML service to check delivery controller health.
• AD service account created for monitor credentials.
• Monitor detects stopped broker service and marks node down.
• DNS A record created for load balancing VIP to enable StoreFront connectivity.

---

The video concludes with a summary of accomplishments:

• Installed and configured the first delivery controller and site.
• Added a second delivery controller for HA.
• Installed and bound SSL certificates on both controllers.
• Configured NetScaler load balancing with dedicated monitor and SSL.
• Created DNS record for load balancing VIP.

The next video will cover installing and configuring Citrix Director and StoreFront, including load balancing for those components.

"We've successfully load balanced delivery controllers... that concludes this video." 1:22:08
"In the next video we'll be installing Citrix Director and configuring StoreFront server group." 1:22:15

---

This detailed walkthrough captures the full technical process and rationale behind each step, preserving the presenter's practical style and focus on real-world deployment considerations.