In my previous blog post I’ve explained more about the Exchange resource forest model where user accounts are located in a dedicated forest with only the user account (and their regular resources) and where Exchange is installed in a resource forest. There’s a forest trust between the resource forest and the account forest, and the mailboxes are configured as linked mailboxes. This is shown in the following figure:
In this blogpost we will add an Azure AD Connect server to enable synchronization between the on-premises Active Directories and Office 365.
Exchange Resource forest and Azure AD Connect
If we want to create a hybrid scenario with our resource forest and Exchange Online we have to implement Azure AD Connect first. Azure AD Connect will synchronize account information from the account forest, and linked mailbox information from the resource forest. To achieve this, we have to setup a multi-forest synchronization model (which is also fully supported by Microsoft).
The Azure AD Connect server will be installed in the account forest. To retrieve the information about the mailboxes from the resource forest, a service account will be used as shown in the following figure:
In a typical environment there’s only one Active Directory containing both user accounts and exchange servers. As such, the user accounts have the corresponding Exchange properties. In a Resource Forest scenario there are two user accounts, where the user account in the Resource Forest is disabled and this disabled account contains the Exchange properties.
The Azure AD Connect server (which is running in the Account Forest) combines the two accounts based on the objectSID and MSExchMasterAccountSid and synchronizes this ‘joined’ account information to Azure Active Directory, as shown in the following figure:
The prerequisites for Azure AD Connect is a Resource Forest scenario are the same as for a regular environment, so I won’t go into too much detail about this. Of course you need an internet routable domain for your accounts (i.e. don@accounts.local won’t work, so this needs to be changed to don@exchangefun.nl), your accounts need to be checked for inconsistencies with the IDFix tool and of course you have to configure your tenant in Office 365. For more information regarding the process, please check my blog Implementing Directory Synchronization. It’s a somewhat older blog, but the steps remain the same.
You can download the latest version of Azure AD Connect from the Download Azure AD Connect. I will only show the most important screenshots when running the Azure AD Connect wizard.
Azure AD Connect can be installed using an Express setup, this is the default setting and is sufficient if you have a single forest environment with less than 100,000 objects in Active Directory and where using SQL Express is sufficient. In our Resource Forest environment we have multiple Active Directory forest, so a custom setup is needed, so select Customize in the Express Settings window:
Continue with the wizard until you reach the User Sign-in window. Here you have to select which authentication method is used when users sign-in into Office 365. Make your selection and click Next to continue.
After entering the (Global) tenant administrator credentials, the forests need to be added to the Azure AD Connect wizard. In the Connect your directories window the Active Directory forest where your Azure AD Connect server resides will appear. To add this directory, click Add Directory:
The Add Forest Account window will appear. Here you can select if a new service account for Azure AD Connect will be created, or that an existing service account will be used. An Enterprise Admin Account will be used to create this service account, and configure Azure AD Connect for first use. It must be an Enterprise Admin account because information is written into the Configuration partition of Active Directory. Enter the credentials of the Enterprise Admin (in your Account Forest) and click OK to continue.
Repeat these steps for the Resource Forest, so enter the forest name, select the radio button to create a new service account and enter the Enterprise Admin credentials in the Resource Forest as shown in the following two figures:
Continue with the wizard, select the Domain/OU filtering options for both Forest and make sure you select the containers containing the user accounts in the Account Forest and the corresponding Mailboxes in the Resource Forest as shown in the following two figures:
The Uniquely identifying your users is the most important window in the Azure AD Connect wizard. This is where the user account in the Account Forest and the corresponding mailbox in the Resource Forest are tied together. In the previous blogpost I’ve explained the objectSID and the msExchMasterAccountSID, so this option is selected.
Continue the Azure AD Connect wizard, and in the Optional Features select the Exchange Hybrid Deployment checkbox and click Next to continue.
You’re now ready with the Azure AD Connect wizard. In the Ready to configure window you can chose to start the synchronization immediately, or enable the Azure AD Connect server in staging mode. In this mode it will collect all information and fill the SQL Express database with data, but it won’t write any data to Azure Active Directory until you’ve checked everything. Select the option you want and click install to finish the wizard and install/configure Azure AD Connect.
At the configuration complete window there are some recommendations and/or remarks for your reference, click Exit to stop the Azure AD Connect wizard.
Now, when you logon to the Microsoft Portal you’ll see that synchronization has occurred:
And when you expand the users option you’ll see which users are synchronized.
When you logon to the Exchange Admin Console in Exchange Online and check the Recipients | Contacts folder, you’ll see the users appear here. This makes sense, since the on-premises Mailboxes are represented as Mail-Enabled Users in Exchange Online.
Summary
In this blogpost I’ve showed you how to implement Azure AD Connect in an existing Exchange Resource Forest model. The Azure AD Connect server combines the user account from the Account Forest with the mailbox from the Resource Forest and synchronizes this to Azure Active Directory.
In my next blog I’ll create a hybrid environment based on the Exchange resource forest model.
Ps. a special thanks to ‘Trekveer Harry’ for his continuous brainstorm sessions and good ideas 
Jaap Wesselius 
Awesome blog post serie Jaap. This helped me enormously for setting this up. Thanks for sharing this knowledge!
LikeLike
Hi Jaap,
Great article, I have done the same thing this year but the customer had enabled accounts in the resource forest for access to some legacy applications which really complicated things.
I have blogged about it here:
https://365guy.co.uk/2018/03/05/azure-active-directory-and-resource-forest/
The customer is also using ADFS
LikeLike
Hi Mitch,
Thanks for your feedback and thanks for the link. I am looking into provisioning and synchronization (and talking offline with Trekveer Harry (previous comment). Some of my customers are using Quest for synchronization, and this will also take care of some provisioning issues (especially the Enable-RemoteMailbox issues) but I’m going to dig into this as well. Please keep the feedback coming, thanks!
LikeLike
Great info again Jaap. Just want to add something which might not be a problem in most environments but I ran into it twice already so could be interesting to know: for AD Connect to be able to connect to the other forest, you have to make sure that DNS Forwarders for the other domain are correctly configured. When that is in place, you don’t even need a trust (as far as AD Connect is concerned).
LikeLike
You’re right about the DNS forwarders, recently I learned that again the hard way. But, you also need this in place for Linked Mailboxes to work correctly. Heck, you need a proper DNS for everything that has to do with Active Directory 🙂
But thanks for the feedback, much appreciated.
LikeLike
Great set of articles, if I have an EXISTING AADConnect install currently setup to the Account forest and I want to simply add the resource forest to the AAD Connect setup, I am not asked how to perform the linking. Is this a supported scenario, or am I better off to reinstall AAD Connect and then link both forests like you have shown?
LikeLike
Hi Eric, so when you run setup again and you add the resource forest, you are not asked about the linking? Do you get any message or does it just add the additional forest and that’s it?
LikeLike
Yes, I am in the same situation. i found this article, but it does not tell what rules we need to edit (because two instances of them exists – one for account and one for resource):
LikeLike
Jaap, thanks for the whole serie. FQDNs of resource and account forest here is the same: accounts.local (first visio picture).
According to Microsoft an Exchange Hybrid with ‘linked mailboxes’ is not supported:
‘Organizations that utilize a resource forest for user accounts, but maintain all Exchange servers in a single forest, aren’t classified as multi-forest in hybrid deployment scenarios.These types of organizations should consider themselves a single forest organization when planning and configuring a hybrid deployment.’ Link: https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/jj873754(v=exchg.150)
You’r post is the only one I could find about ‘Exchange Hybrid with linked Mailboxes’. Good job!
LikeLike
Hello Jaap. We are currently configured in this manner for 3 years now with multi forest hybrid with mailboxes in office 365. I want to eliminate the hybrid and go all cloud. To your knowledge is this even possible? I cant see how it would work without the on premise exchange server.
LikeLike
Hi Jaap,
Very informative post. I have a question:
Do the disabled Resource forest accounts need to have a routable UPN too?
My Resource Forest accounts are resource.local and Account Forest accounts are @accounts.com.
LikeLike
Hi Jaap,
Great post.
The mail attribute for a user in both resource and accounts forests is the same i.e. first.last@domain.com
UPN in the resource forest is first.last@domain.local
UPN in the account forest is first.last@domain.com
Should I update the UPNs in the resource forest to be their mail attribute i.e. first.last@domain.com ?
Thanks
LikeLike
Hello, Have you got any response on this? I’m in the same boat. Any advise would be great. Thank you!
LikeLike
If there’s a forest that has both user accounts and Exchange resources and additional forests that have user accounts (that have linked mailboxes in the Exchange resource forest) is it possible to have this as a supported scenario with AD Connect? Also, someday we’d like to merge the forest with user accounts into the one with both user and Exchange resources, not sure if this would be possible if we have sync and Office 365 already set up.
LikeLike
Hi Don,
two forests with Exchange and Office 365 is not a supported scenario, but it works as I’ve seen this before. I’m not 100% sure what will happen in your merging scenario, but I guess you’ll run into issues. The user account in Azure AD is linked to the user account in the account forest, so if you want to decommission the account forest you have to figure out a way to reconnect them to the accounts in the resource forest.
But, this is not something I’ve done before so I might be wrong….
LikeLike
My apologies, I meant there’s a single forest (let’s call it Forest A) with Exchange that also has users (as opposed to the scenario you have above where the users reside in a forest separate from the Exchange forest. In our case, there exists additional forests (let’s call them Forests B and C) with just user accounts. Users in Forest A have mailboxes on the Exchange server in Forest A, and users in Forests B and C have linked mailboxes that reside within Forest A. That said, if we setup Azure AD Connect now and get users in all forests migrated to Exchange online in Office 365, 1 is this a supported scenario and 2, if we decide we want to consolidate Forests B and C into A down the road is there a supported migration path for that? Thanks for all your help!
LikeLike
Hi Don,
I have worked on a scenario the same as the above, yes it is possible and supported. If possible I would recommend moving the accounts first if possible as subsequent changes will be a painful process. Also what authentication method are you using as ADFS will likely not work with your scenario as upn routing over multiple trusts breaks the authentication.
Happy to discuss further if you send me your email
LikeLike
Thanks Mitch, I’m on Gmail – donaldjones@
LikeLike
Thanks for the articles, I already have ADconnect setup with 2 forests. Forest A has accounts and mailboxes and ADconnect
Forest B has Accounts and using Linked mailbox in Forest A.
When I setup ADconnect I chose the option “Users are represented only Once across all directories” Where I should have chosen ” Match using ObjectSid and msExchMasterAccountSID” How can I change this? It seems impossible. Thanks
LikeLike
That’s a good question, I’m not sure but I think a reinstall of the Azure AD Connect server is the only way to achieve this.
LikeLike
In comment to Marcel Rond, i found an article from Dirteam that states that the user identification cannot be altered afterwards: https://dirteam.com/bas/2020/01/10/field-notes-how-is-your-azure-ad-connect-been-configured/
The only way to make this work is to manually add/alter sync rules to AD Connect, which nobody did before when i have to believe the Google search results on this.
I asked MS to assist us in this case and hopefully get some results out of it that i can share.
LikeLike
Thanks for the info René
LikeLike
Hey guys,
I have a problem with this setup.
The way it works for me is that the users are converted to Linked Mailbox via Set-User and synced through there from Azure AD Connect to the cloud. In the cloud only one user is shown thanks to the merging. Unfortunately, no user is then created as a mail user under Contacts.
Is AD Sync not aware that it is an email user or what is the problem? Do I have to do something in the sync rules?
Thanks
Niklas
Translated with http://www.DeepL.com/Translator (free version)
LikeLike
it is difficult to say with very little information, are all synchronised with Azure AD, do they show up as regular users in the admin portal? My first thought would be that something is wrong with the merging of accounts. What I typically do is changing one or two properties of the mailbox, and see if these changes show up in Azure AD.
A full sync instead of a delta sync can help too.
LikeLike
Hi,
I have 3 Forest Scenario.
Forest A is Resource Forest with Linked Mailboxes with Disabled Users.
ADConnect is configured with objectSID and MSExchMasterAccountSid to Office 365
Forest B is Account Forest which has MSExchMasterAccount.
Forest C is also New Clean Account Forest.
How Could I move the Users from Forest B to Forest C mapping to same linked Mailbox & Office 365 Resources.
What’s Your view?
Thanks,
DK
LikeLike
Hi Dinesh,
My first option would be to migrate the users from Forest B to Forest C using ADMT, this will basically clone the users so all properties will be re-used. But I have to admit, I have never done a migration in this scenario.
LikeLike
Appreciate Your genuine reply.
You are already doing a fantastic job & got logic built through Your articles.
ADMT works fine with flow to follow.
I have tested in morning & it’s so far working successfully in test environment after long hard work.
I have documented steps. Once I test it thoroughly, I will send You the document by mid of next week.
LikeLike
Thank you for this article.
In the case that you have multiples account forests, how you will manage homonymes ( with Same SamAccounName )
What would be the best AAD Rules and how to manage priorities.
Regards
LikeLike
To be honest, I have no idea anymore. This was a couple of years ago, and I haven’t seen a resource forest solution since then, I’m sorry
LikeLike