Scenario: New AADconnect server in new Forest - All mailboxes in EXO O365

Question

Hi all.
A challenging one, even though I've done dozens are of similar complex migrations, but this one is slightly different…

Scenario:
Customer has moved IT suppliers.
Existing environment is:
• AADConnect server syncing all users from Forest A into Azure.
• All mailboxes have been migrated to Exchange Online (approx. 500 mailboxes)
• All Distribution Groups are created and managed in Office 365
• Source of Authority of users is Forest A's Active Directory
• All new mailboxes are created direct in Exchange Online by assigning a license
• MX Records and Autodiscover DNS records all point to Exchange Online (autodiscover.outlook.com)
• There is no mail routing to/from on-premises Exchange environment, although Hybrid is still available (not yet decommissioned by current supplier).
• The current Exchange environment is only being used for any Administration/Management purposes only (as opposed to using ADSIEdit etc.)
• It is worth mentioning that although all AD user objects are in Forest A, the Exchange hybrid server and the AADConnect server are in Forest B (they were linked mailboxes before they got migrated to Exchange Online (If that is relevant))
• There is a non-transitive AD Trust between Forest A and Forest B

End Target goal:
• All mailboxes to remain in Exchange Online
• MX Records and Autodiscover to remain pointing to Exchange Online
• Source of Authority to be Forest C Active Directory instead of Forest A (by this, we will have soft or hard match immutable ID for set-msoluser) - not an issue
• When new users join the business, they're given a new AD account in Forest C, which is synced via AADConnect. Their mailbox is created in Exchange Online

New environment:
• New Active Directory Forest created (Forest C)
• Instead of migrating the AD user objects from Forest A to C, brand new AD user objects have been created in Forest C
• There is a two-way non-transitive trust between Forest A ('old' AD User objects) and Forest C ('new AD User objects)
• Robocopy has been used to copy over any file shares etc.
• Users are given new laptops in the new Forest C. They log in using their new Forest C credentials.
• Outlook clients are manually created in Forest C pointing Autodiscover to autodiscover.outlook.com
• We have now installed AADConnect in Forest C as Staging Mode.
○ We have added Forest C (new users) OU's in Scope to sync
○ Old supplier has added their Forest A credentials into our Azure AD Connect server and added OU's in Scope to sync
• We have now also installed Exchange 2016 server to extend schema for mail attributes
○ Straight after installation, configured ServiceConnectionPoint to $null to ensure Outlook clients that are internal on network do not query Active Directory for Autodiscover (although they shouldn't do because their Outlook profiles are manually created to point to Exchange Online for Autodiscover)
• As it stands, we have not yet ran the Hybrid Configuration Wizard (and I'm looking for the best way to achieve our end target goal without adding complexities of configuring HCW

Plan of action is:
• As the new AADconnect server in Forest C has the existing synced Forest A users and the new Forest C users in scope to sync, we will make the new AADConnect server as the primary AADconnect server (by asking the old supplier to enable their AADconnect server to Staging Mode)
• We will then set-msoluser accounts of all users to $null and then set to the immutable ID's of the Forest C synced AD Users

Identity - Query:
• Forest A and Forest C both have the same domain suffix of externaldomain.com - this may cause issues with 2 Forests syncing to the same Azure AD? Or will there be no issue with this?
• Externaldomain.com is the UPN which a user logs in, which also matches their primarysmtpaddress (as per common practice) - the existing AD users from Forest A use externaldomain.com as per their UPN.. And Forest C accounts will also use this too. So we're thinking of keeping the Forest C users with their @keyman .LOCAL account so by default they pick up a @tenantname.onmicrosoft.com UPN which we can manually change on a per user basis?

Exchange - Query:
• We have recently only installed Exchange into the Forest C environment. We have not performed any sort of Hybrid config, because we believe we don't need a hybrid organizational relationship between new Exchange and O365, as all mailboxes are in O365, no mail is flowing via Exchange etc.
• As it stands, the on-premise Exchange environment doesn't know anything about the O365 tenant - ECP is empty; as we now have Exchange in the Forest, what would you guys suggest we configure for Exchange on-premise to see the O365 mailboxes in on-premise ECP (as maybe O365 mailboxes or as Contacts) without having to run a Full HCW?
○ AFAIK a minimal Hybrid config is not recommended because it's for much smaller organisations who don't use AADC, so their SoA is not Active Directory.
○ We also don't want to go down the route of procuring a new cert, having external FW and DNS entries implemented, if we won't use any of the hybrid features. We just want to be able to manage O365 mailboxes
• I guess, although the mailboxes hosted in O365 are using their AD accounts synced from Forest A, and although Hybrid is not being used, the user accounts still much have links to some sort of settings from Forest A's ADSIedit environment, such as the Email Address Policy and Accepted Domains list that is in the Exchange Organization?
• One of the big hurdles will be the fact that we're using the same externaldomain.com on-premises across both Exchange forests. Maybe we need to take a calculated risk of this?

Any thoughts or questions for more clarity? It's a good one (challenging!) but will be good to get your ideas and concerns to anything that I haven't considered?

Thanks in advance!

Ron

P.S - apologies if I have posted this in more than one forum.

Answer 1

@LIT-RS

After reading your description, I think the following scheme is the best practice scheme:

1. Since you have migrated mailboxes to Exchange online, you can remove the hybrid and AAD connector from the forest A. Scenario one In this way, all mailboxes and AD accounts are in Office 365.
2. Remove forest A or remove the DNS which point to it. In this way, forest A will be isolated from the public network, it could prevent the issue cased by forest A and forest C using the same domain name.
3. Create AAD connect in forest C, sync accounts from AAD back to local AD (You don't need to install Exchange in forest C and create Hybrid configuration). In this way. you will could manage AD account from local AD and use local AD credential to verify account.

The above is the most convenient and safest method I can think of.

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Hi @KyleXu-MSFT @KyleXu-MSFT

Thanks for your response.

I have installed AADConnect in Forest C in Staging Mode. I have also had the old supplier to enter in their credentials from Forest A into my new AADconnect Server. So as it stands, I should only just need to ask them to enable Staging Mode on their AADconnect server, and I disable Staging Mode in our AADconnect Server.

I am aware that they're also synchronising the Disabled AD User Objects in Forest B that represent the old Linked Mailboxes (from Exchange) also into Azure AD. I'm not sure whether that is actually needed, as all mailboxes are migrated to EXO and the Immutable ID is linked to the enabled user objects from Forest A. Would you agree?

With regard to Exchange, I have installed Exchange into Forest C - but as there is no hybrid config, I do not see the EXO mailboxes showing up in my on-premises Exchange as either O365 mailboxes or Mail Contacts.
I would still need to manage some Exchange attributes from on-premises, I guess?