Using Microsoft Azure Disk Encryption with Your Farms and VDI Desktops in Your Horizon Cloud Environment

When you create an RDSH farm or a VDI desktop assignment in your Horizon Cloud pod in Microsoft Azure, you can decide to whether to enable disk encryption. When you enable disk encryption for a farm or VDI desktop assignment, all disks for all of the virtual machines (VMs) in that farm or VDI desktop assignment are encrypted. You specify disk encryption when you create the farm or VDI desktop assignment, and you cannot change the encryption state after the farm or assignment is created.

The workflows to create a farm and a VDI desktop assignment include a toggle for enabling disk encryption. For details of those workflows, see:

• Horizon Cloud Pods - Create a Farm
• Create a Dedicated VDI Desktop Assignment Provisioned by a Single Pod in Microsoft Azure
• Create a Floating VDI Desktop Assignment Provisioned by a Single Pod in Microsoft Azure

Note:

• This release does not support having disk encryption for floating VDI assignments that use image VMs with attached data disks.

Performance Impact of Disk Encryption

The disk encryption feature is provided by the Microsoft Azure cloud's Azure Disk Encryption (ADE) capability. ADE uses the BitLocker feature of Microsoft Windows to provide encryption for the OS and data disks of the VMs in Microsoft Azure. In general, BitLocker imposes a single-digit performance overhead, so the encrypted VMs might have a noticeable performance impact. The downsides of VM encryption are that it might increase data, network, or compute resource usage, which can result in additional license or subscription costs. Instead of simply reading data from the disk and writing data to an unencrypted disk, the VM must unencrypt the data to read it, then encrypt the data to write it back to the encrypted disk. In this process, keys are read from the key vault in Azure, which increases the network usage, and CPU cycles are spent on performing the encryption. See Azure Disk Encryption FAQ and BitLocker Deployment and Administration FAQ in the Microsoft documentation.

The Encryption Key Vault

The key vault used for the pod's encrypted farms and VDI desktop assignments is created in the same Microsoft Azure resource group that contains the pod's manager VM. A single key vault is used for all of the pod's encrypted farms and desktop assignments. The system creates this encryption key vault when the first encrypted VM is created as a result of creating the associated farm or VDI desktop assignment. Until that first encrypted VM is created, you will not see this key vault in your pod's resource groups.

The system generates the key vault's name using the pod's ID, which is an identifier in UUID form. To adhere to Microsoft Azure naming rules, the system sets the key vault name by:

1. Taking the pod's ID.
2. Appending the letters kv to the beginning.
3. Removing any non-alphanumeric characters.
4. Truncating characters as needed to keep to a maximum length of 24.

The following screenshot illustrates the items in the pod's manager VM's resource group when that pod has an encrypted farm. The screenshot shows two key vaults: one is the key vault for the pod itself, created during pod deployment, and one is the key vault created when the first encrypted VM is created as a result of creating a disk-encryption-enabled farm or VDI desktop assignment. In the screenshot, you can see that:

• The pod's ID is e1c80e74-7f6f-434f-bd79-c1e3772f6c5a, in the pod's manager VM's name.
• The encryption key vault's name is kve1c80e747f6f434fbd79c1, determined by taking that UUID, adding kv to the beginning, removing the hyphens, and truncating the name to 24 characters.

Caution: Do not delete any key vaults you see in the pod's manager VM's resource group. The encrypted VMs will not power on if the encryption key vault is deleted. The pod's manager VM will not power on if the pod's own key vault is deleted.

Creating and Deleting Encrypted VMs

An encryption secret is used for each encrypted VM. As a VM instance is created in an encrypted farm or VDI desktop assignment, a secret is created in the key vault. When a VM instance is deleted from an encrypted farm or VDI desktop assignment, the secret is removed from the key vault.

When you use the Horizon Cloud administrative console to delete an encrypted farm or VDI desktop assignment, the system deletes the associated secrets from the key vault. When you delete the pod itself, the key vault for the encrypted VMs is also deleted.

Note: Creation of an encrypted farm VM or desktop VM takes approximately twice as long as creating a non-encrypted VM. As a result, the end-to-end time to complete creating a farm or VDI desktop assignment that has disk encryption enabled is approximately twice as long as creating that farm or VDI desktop assignment without disk encryption enabled.

Also, when an image VM has a data disk, additional time is needed for creating an encrypted farm VM or desktop VM based on that image VM. Generally speaking, times for disk encryption of VMs with data disks that are running Windows Server operating systems are shorter times than for Windows 10 or Windows 11 VMs with data disks. The longest times occur for Windows 10 or 11 operating systems with data disks of larger, terabyte sizes.

When Scheduling Power Management for Farms and VDI Desktop Assignments That Have Large Numbers of Encrypted VMs

The time to power on an encrypted VM and have the VM become ready to accept an end-user connection takes longer than for non-encrypted VMs. When the VM has a small number of cores, like the A1 size, the time can take approximately 12 minutes. With a larger number of cores, the time is shorter, approximately 6 minutes.

When you are using the system's power management scheduling feature to have large numbers of VMs powered on it time to meet a predicted end-user demand, if the VMs are encrypted, you must consider the additional time it will take to have those VMs ready. The system powers on a maximum of 125 VMs concurrently. If your VDI desktop assignment or farm has more than 125 VMs, when a power management schedule says to power on the assignment or farm at 8 AM, the system starts powering on the VMs at 8 AM in batches of 125 at a time. When the VMs are of the smallest A1 size and are encrypted, this combination of 125 VMs per batch and the 12 minutes to be ready for connections gives an approximate time line that looks like:

• By 8:12 AM, 125 VMs are ready
• By 8:24 AM, 250 VMs are ready
• By 8:36 AM, 375 VMs are ready

As a result, if your VDI desktop assignment has 2,000 encrypted VMs of the small A1 size, the time it takes for having 100% of them powered-on and ready for end-user connections will be approximately 3.5 hours. If your goal is to have 100% of those encrypted A1 size desktops ready at 8 AM, you should consider setting the power management schedule to start at 4:30 AM.

For larger-sized VMs, the time to be ready is about half as long. So instead of 3.5 hours, an encrypted VDI desktop assignment of 2,000 encrypted VMs of a larger size like A4 would take 75 minutes to have 100% of them ready to accept end-user connections.

Similarly, an encrypted VDI desktop assignment that has less desktops will be ready faster than the large 2,000 pool size. For a pool of 500 encrypted desktops of the small A1 size, 100% of the pool will be ready in approximately 48 minutes. 500 VMs divided by 125 per batch makes 4 batches, then multiplied by 12 minutes per batch gives 48.