Skip to content
Let's Talk

Create a AVD Deployment with an Existing Azure AD / Office 365

Picture of MyCloudIT

This document provides general guidance for a simple Azure Virtual desktop (AVD) deployment via the MyCloudIT system with the plan to use an Azure tenant that already has Azure Active Directory users in it.

The primary use cases are:

  • You use Office 365 or Microsoft 365 and have current email / SharePoint / OneDrive users in the Microsoft platform and/or
  • You currently synchronize a traditional Active Directory forest (ADDS) to AAD via AADC/AADC-CS

Other considerations:

  • If you have a more complex environment with AD federation, multiple public domains, split DNS or other scenarios please reach out to MyCloudIT support for advice.
  • This guide does not cover if you have an existing active directory environment on-premises, in Azure or other via another method. Warning: If you do have existing AD do not use the same AD domain name for AVD.

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)

Process Overview

  1. When you deploy AVD via the MyCloudIT portal, we will install and configure AADC-CS. We also add your public domain (called custom domain names in AAD). This domain must be publicly registered and added to AAD prior to deployment.
    1. For more information, see KB - How to Create an AVD Deployment with a New DC
    2. Warning: Do not select a name for the "Domain Admin Username (SAM)" that already exists in AAD. Select something unique such as "dcadmin".
  2. The new AD instance (on the domain controller, we create on a VM called MSDC) will then be the master truth for all users and will replicated to AAD.

    1. You can check if you already have users in Azure Active directory by going to https://aad.portal.azure.com, logging in, and clicking the users.

    2. If you want to use these same users for AVD, then the domain you supply AAD Custom (public) Domain for the AVD question in the portal deployment wizard needs to be the same as these existing users. Warning: If you do have existing AD do not use the same AD domain name for AVD DC.

  3. Post deployment, you would then add these as new users to AD via the "Active Directory" screen in the MyCloudIT portal or via ADUC on the MSDC-001 machine. Make sure the following items are the same in AAD and AD, this will create a 'soft match' and the users will be considered "synchronized" and the same object.

    1. Make sure the AD "User logon name" (aka UPN) matches the ones that already exists in AAD

    2.  Make sure the AD "E-mail" matches the ones that already exists in AAD.

    3. In AD attribute editor make sure userPrincipalName is the same as the one from step A (example: user.A@myCompany.com).
    4. In AD attribute editor make sure proxyAddresses is the same as the primary email address in AAD but in the correct AD format (example:  SMTP:user.A@myCompany.com).
    5. The user is not a high privilege user in AAD (example: Global Administrator).
    6. See Appendix D for further information.

Example Use Case

You wish to deploy your first AVD system to your Azure tenant and subscription, with the custom domain name of "myCompany.com." Currently, you have 3 existing users that have Office 365 Business Premium licenses and use exchange online email and OneDrive. The users User Principal Names (UPN) are as follows:

  • user.A@myCompany.com
  • user.B@myCompany.com
  • user.C@myCompany.com

To start:

  1. You would first check that myCompany.com is verified and is the primary in https://aad.portal.azure.com under "Custom domain names".
    1. Warning: Data Loss potential! Since AD is the source of truth, this means AAD account information will be overwritten/removed. Review Appendix A before implementing AVD with existing AAD users.
  2. Next, you would Deploy AVD via the MyCloudIT portal, making sure that AAD Custom (public) Domain for the AVD deployment wizard question is answered as "myCompany.com".
  3. Wait for the deployment to complete and finish all post deployment steps.
  4. Next via the "Active Directory" screen in the MyCloudIT portal or via "Active Directory Users and Computers," add the three users. Make sure the domain specified for each users UPN is "myCompany.com."
  5. Check if synchronization is happening. For example, change an attribute such as "Office" for an AD user and then make sure that field is then changed in AAD.
    1. Note: Synchronization is not constant, it is performed at scheduled intervals so you may need to wait or force an AADC-CS "Restart Sync".

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 those fields in AAD/Office365. Any attributes filled out in Azure.

If an attribute for a user is populated in AAD/Office365 and that same attribute is not filled in AD, then both fields will become empty when ADDC-CS is activated.

  • 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 for this user, 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.

Appendix B: Password Changes

If users already exist in AAD and then you add the same user as per above to make then "soft match" then the password set on the AD account will replace the users AAD/Office365 password.

Once users are already synchronizing and if you change or reset a password in AD, the new password will also be applied to the AAD account.

  • Warning: Once users are already synchronizing and if you change or reset a password in AAD/Office365, the user will have 'mismatching' passwords. There are various ways to manage this challenge but that is outside of the scope of this document.

We advise that administrators only reset passwords via AD or the MyCloudIT portal. Users can change their passwords via their RDS or AVD sessions. A useful method is to put a "change password" shortcut on the desktop.

If you require two way synchronization of passwords, then you will need to configure "password writeback."

  • Tis requires an AAD Premium plan or Microsoft 365 Business Premium.
  • The list price for AAD P1 is US$6 per user per month.
  • At this time, AADC-CS does not support password writeback.

Appendix C: Email Considerations

We recommend for most customers one of two scenarios:

  1. If you use exchange online (often called Office 365 email), then the users' usernames in AD should be the same as their "Primary email address and username" in Office 365.
    1. If they have other email alias and shared mailboxes, this is fine but no need to specify them in AD. In this scenario, the AD attribute "E-mail" should be also the same as their username.
  2. If you do not use exchange online, then the "E-mail" attribute in AD can be the user's third party email address, Example: example@gmail.com.

These basic recommendations come from the fact that the way various AD attributes, such as 'mail' and 'proxyAddresses,' are synchronized can have unintended results.

Appendix D: AADC - Cloud Sync (AADC-CS)

The MyCloudIT portal uses AADC-CS to synchronize user objects. Compared to traditional AADC, it is more lightweight, syncs more often, and managed on the Azure plane. It is the better option for standard deployments.

However, it does not support all of the AADC features. Some things that AADC supports that AADC-CS does not are:

  • Writeback for passwords, devices, or groups
  • Pass-Through Authentication
  • Exchange hybrid writeback
  • Device objects (hybrid AAD computer join or windows hello)
  • Integration with ADFS
  • Advanced SSO scenarios

For further general information see: https://docs.microsoft.com/en-us/azure/active-directory/cloud-sync/what-is-cloud-sync

For information on matching new AD accounts with exist AAD accounts see: 

If you require AADC, we can assist with guidance on replacing AADC-CS with it, please reach out to MyCloudIT support.