Multiple AVD Instance Options

Understand the considerations of managing multiple AVD instances under one tenant

This article provides general information for those who want to deploy more than one Azure Virtual desktop (AVD) deployment to a single Azure tenant (also known as Azure account). This is generally not recommended as there are various disadvantages with this type of deployment.

Acronyms used in this document:

• AAD - Azure Active Directory (Microsoft cloud hosted as a service)
• AD - Active Directory (An instance of an Microsoft Active Directory Domain Services install on a physical server, VM in azure, etc)
• AADC - Azure Active Directory Connect (One of Microsoft's systems you can use for facilitating AD hybrid identity)
• AADC-CS - Azure Active Directory Connect Cloud Sync (One of Microsoft's systems you can use for facilitating AD hybrid identity)
• AVD - Azure Virtual Desktop (Microsoft's platform for delivering Windows shared/personal virtual desktops/applications via Azure)

The MyCloudIT platofrm (MCIT) does not fully support this scenario as the use cases for this scenario are few and far between. We recommend you to reach out to discuss the other options for deployment as we may be able to recommend a better way to structure your environment other than to be locked into multiple AVDs per one Azure tenant.

• A tenant here refers to one Azure Active Directory instance or one Azure account. All tenants have a default domain associated with them.
• For example: mycompanyname.onmicrosoft.com. Note this has nothing to do with multiple subscriptions.

How to Manage Multiple AVD Instances

The suggested method for achieving the same result for most clients would be one of the two alternate configurations:

• Option 1: Create a second AVD deployment via a second Azure tenant
  
  • Use Case: You are a managed service provider and have multiple clients who want to take advantage of AVD. Each separate client should have their own Azure tenant which will ensure that there are no cross company security/technical/compliance issues as there can be with shared Azure AD environments.
• Option 2: Create a new AVD Host Pool (including workspace and application group) to manage the second entities virtual desktops.
  • Use Case: Your company acquires another company and wants to provide login to the existing host pool or create a new one. The acquired company already has their own public DNS presence and email addresses that you do not want to change. In this case you would bring their existing public domains into the existing Azure tenant and then add the domain names to the existing AD forest. Your IT security team will advise on the "shared" resource (the "domain controller") being hardened, so a bad actor does not compromise the domain controller if they compromise a session host. 

Please reach our for further advice on complex scenarios.

Considerations for Deploying Multiple AVD Instances in a Single Azure Tenant

If you would still prefer to deploy multiple MCIT AVD instances via a single Azure tenant then proceed below to read some considerations. The below should only be considered by experienced IT administrators. The MyCloudIT portal does will only assist you to deploy one AVD deployment per Azure tenant. 

• Note: Without a good understanding, testing or planning this type of deployment could mess up existing AAD / Exchange Online / other data.

The following are requirements for the multiple AVD per single Azure Tenant approach:

• Deployment name and resource group must be unique per MCIT AVD instance.
• The Deployment Prefix (and thus Host Pool name and Session Host names) must be unique per MCIT AVD instance.
• Public domain name must be unique per MCIT AVD instance. Example, if you have two AVD deployments you need two public custom domain names.

• The AD domain name must be unique per MCIT AVD instance and per AD instance.  Warning: Do not use a domain name that you have already used on another domain controller.

• Generally the two networks should be kept separate (EG no vnet peering , VPNs, etc).
• The IT administrator should consider and implement general security boundaries.
• The IT administrator should consider Azure portal security. Which administrators will have access to the shared AAD and other resources?
• The IT administrator will need to manage groups and users that have the same names in AAD.
• The IT administrator will need to manage Azure objects that have the same names.
• The IT administrator will need to manage Azure objects that have the same names.

More information will require knowledge of specific environment details so reach out for further advice.

Appendix

Appendix A: AD as the source of Truth

This should be reviewed carefully as data loss is possible and cannot be reversed. This is by design from Microsoft.

• As AD is the source of truth (as opposed to AAD) fields such as "Last Name", "First Name", "Office" and "Street Address" the values specified in AD will overwrite any in AAD/Office365. Any attributes filled out in Azure.
• If an attribute for a user is populated in AAD/Office365 then ADDC-CS is activated and that same attribute is un-filled in AD then both will become empty. Example: AAD user daniel.williams@myCompany.com has the "last name" attribute set as "Williams". You create a new AD user daniel.williams@myCompany.com and leave the "Last name" field blank. Once the first synchronization has completed this user will no longer have a last name in either AD or AAD/Office365.
• Note that the AD attribute "Full name" does not map to AAD. The "Display Name" attribute in AD maps to "Name" in AAD.