Home / server / Questions / 1013492
In Process
Blue Tongue
Asked: 2020-04-22 22:41:15 +0800 CST

Does Multi-Forest Azure AD Connect support forests with the same UPN suffix?

  • 772

We have company A AD forest (forest domain a.com) and company B AD forest (forest domain b.com) linked by inter-forest trusts and each with On-Premises Exchange 2010 SP3.

We plan to migrate both Exchange Server to a single Office 365 tenant in an hybrid environment using multi-forest Azure AD Connect to synchronise both AD into separate directories in Azure.

a.com is using [email protected] as its UPN.
b.com is using [email protected] as its UPN.

Now because the 2 organisation is sort of merging its operations, we are exploring the possibility that both a.com and b.com staff to log on using the same UPN c.com like [email protected] as their UPN instead.
I know I can add c.om in a.com and b.com forest as a new UPN no problem but when it comes to AADC, it is a different arena.

When running AADC, I am not sure if it can go past this screen?

Is this supported at all?

Thanks in advance.

**enter image description here**

azure-active-directory

2 Answers

  1. ADConnect doesn't care about the AD UPN, only if it can be properly matched to an Azure AD UPN; so, if you have non-routable UPN suffixes such as "@domain.local", ADconnect will warn you about this; if an user account with such an UPN suffix gets synchronized, the Azure AD user will get the default UPN suffix ("@yourname.onmicrosoft.com"), because the original UPN will not be usable.

    If you add a third UPN suffix to your AD forest(s) and it can be properly matched to an Azure AD UPN suffix (i.e. a DNS domain you validated in Azure AD / Office 365), this will not be a problem at all; just remember to set your users' UPN to use the new suffix prior to starting synchronization.

    Also, be careful about duplicate UPNs: if you are syncing from more than one forest and duplicate UPN exist, this will lead to synchronization conflicts.

    Addendum: if you are migrating users between AD forests, or if you have duplicate user accounts in different forests because they are actually the same users, you need to take extra steps in order for ADConnect to correctly match them.

    • 1

  2. I'd suggest that the primary SMTP address is more important to you then the UPN. Every Office 365 login prompt asks the user for their email address. This is a bit of a misnomer. What the prompt is really asking for is the users Office 365 UPN, but assumes that it's the same as the users primary SMTP address. If you settle on a "common" UPN, and if that UPN is different than the users primary SMTP address then your users are going to be confused and it's going to generate calls to your support department when they can't login to Office 365 using their email address... because it's different from their Office 365 UPN.

    So... add your Office 365 verified domain for each AD domain as a UPN suffix in each respective AD and set it on the user accounts. Assuming that the UPN for each user then matches their primary SMTP address, their Office 365 UPN will match their email address and you'll avoid issues where the UPN and primary SMTP address are different.

    I see this problem all of the time. A users Office 365 UPN is John.Doe@company A.com but their primary SMTP address is [email protected]. They try to log into Office 365 as [email protected] and that of course doesn't work because their Office 365 UPN is [email protected].

    So make each users on premises UPN match their primary SMTP address and then sync them from your on premises AD to Office 365/Azure AD.

    enter image description here

    • 1