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

[LIT-RS]

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 @domain.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.

[#2]

As per your Query: One of the big hurdles will be the fact that we're using the same externaldomain.com UPN on-premises across both Exchange forests. Maybe we need to take a calculated risk of this?

Answer:
You’re going to do two separate things: remove Azure AD Connect and migrate Active Directory accounts from the old forest to the new. Firstly, execute: “Set-MsolDirSyncEnabled –EnableDirSync $false”. This will disconnect the relationship between Azure AD and on-premises AD. The objects in Azure AD will change from being synched to being Cloud-Only. The user IDs and passwords are all the same and users can log on to email, etc., and send and receive just as they had been doing up until now.

This enables you to focus on your Active Directory transition project without the worry that in 20 minutes you’ll have users breathing down your neck and clamoring to be in their Office 365 resources.

Your options are (at least) three:
ADMT from Microsoft: https://www.microsoft.com/en-us/download/details.aspx?id=19188
Migration Manager from Quest: https://www.quest.com/products/migration-manager-for-active-directory/
Active Directory Pro from Binary Tree: https://www.binarytree.com/products/active-directory-pro/

Azure AD Connect has come a long way over the years. The applicable feature in this case is SMTP Matching: https://support.microsoft.com/en-us/help/2641663/use-smtp-matching-to-match-on-premises-user-account.... The key factor in the migration process is to make sure the migrated source object in Active Directory and the target object in Azure AD have the same UPN and SMTP addresses. If the object you’re sending to Azure AD has the same UPN and/or SMTP address, the account will change from being cloud-only to being synchronized with the new Active Directory.

So I think since you have same Externaldomain.com UPN this should work. I would also suggest that you do a LAB first with a minimal set of AD users and ADMT tool. Also you can use the trial version of E3 or E5 for your LAB creation.

Reference https://anderseideblog.wordpress.com/2014/02/12/lab-migrate-office-365-synced-users-from-one-on-prem...

However the only difference in the above article LAB is the UPN's are different for Forest A and Forest C users.