A fully supported scenario in Exchange is the so-called Resource Forest model. In this scenario there’s an Active Directory account forest where all user accounts and regular services exist, and there’s an Active Directory resource forest where Exchange is installed. This scenario is supported for Exchange 2010, Exchange 2013 and Exchange 2016 and I’ve seen this several times at several customers, with several Exchange versions.
So, Exchange is installed in the resource forest, and the mailboxes in this Exchange implementation are so-called Linked Mailboxes. The Mailbox here is linked to a user account in the account forest. There’s a user account for the Linked Mailbox in the resource forest, but by design this is a disabled account.
When provisioning a Mailbox, a user account is created in the account forest, an identical (but disabled) user account is created in the resource forest and a linked mailbox is created. Provisioning can be done using a Microsoft tool like Microsoft Identity Manager (MIM), a third party tool like Quest or using plain PowerShell scripts. The process is shown in the following figure:
This can be useful if you have multiple account forests that need to use one Exchange organization, a situation that I’ve seen at multiple customers. You end up with a scenario like this:
I must agree, things can become complicated pretty fast, but it’s a fully supported scenario and in some cases, it can be useful. One of my customers has implemented this scenario because of multiple acquisitions.
In my lab environment I’m working with the first scenario. I’ve installed an account forest (accounts.local) and a resource forest (resources.local). The installed Exchange version is Exchange 2010, there’s one multi-role Exchange 2010 server, and there’s one Exchange 2010 Edge Transport server. Both servers are running Service Pack 3 with Rollup Update 20. Accounts are created in the account forest, and a linked mailbox is created in the resource forest.
Every mailbox has a property called msExchangeRecipientTypeDetails, and this tells what kind of mailbox it is. When this property has a value of “2” it is a linked mailbox, if it has a value of “1” it is regular mailbox. An overview of this property and its values can be found in a blog from John Baily on TechNet.
The second important property of a mailbox is the msExchMasterAccountSID. For a linked Mailbox, the msExchMasterAccountSID attribute is populated with the value of the objectSID of the corresponding user in the account forest. When using ADSI Edit and checking the objectSID of the user account and the msExchMasterAccountSID of both account you’ll see that they have the same value. For a test user called Don Drop in the account forest you can see the following objectSID:
And for the corresponding disabled account in the resource forest we can see the following msExchMasterAccountSID:
Or if you prefer to use PowerShell, execute the following commands in a PowerShell window (in the Exchange forest) to retrieve the msExchMasterAccountSID:
Import-Module ActiveDirectory $MBXUser = Get-ADUser -Identity Don -Properties * $MBXUser.msExchMasterAccountSID | fl
To retrieve the user’s objectSID from the account domain execute the following PowerShell commands:
$AccountsCred = Get-Credential "accounts\administrator" Get-ADUser -Filter {ObjectSID -eq $MBXUser.msExchMasterAccountSid} -Properties * -Server accdc01.accounts.local -Credential $AccountsCred | fl Name,ObjectSID
Note. You will see this objectSID and MSExchMasterAccountSid again in the next blog on Azure AD Connect in this scenario.
To check permissions on the mailbox you can use the Get-ADPermission command against the output of the Get-Mailbox command:
Get-Mailbox -Identity Don | Get-ADPermission -User Accounts\Don | fl *
As you can see Don has the appropriate permissions on his mailbox.
Note. To convert a linked mailbox to a regular mailbox you can remove the value for the msExchMasterAccountSID by using Set-User command:
Set-User -Identity Don -LinkedMasterAccount $NULL
This will reset the msExchMasterAccountSID, but at the same time changes the value of the msExchRecipientTypeDetails from “2” (linked Mailbox) to “1” (normal Mailbox).
Summary
So, by now you should know more about the Exchange resource forest model. It is a little more complex than a single forest, single domain model with Exchange installed, but it is a fully supported scenario. And a scenario I see at customers very regularly.
In my next blog I will discuss more about Azure AD Connect in this resource forest model.
Hey Jaap, great series.. I suspect you mean the sentence “When this property has a value of “2” it is a lined mailbox, if it has a value of “1” it is regular mailbox.” be linked mailbox ?
LikeLike
Thanks for the feedback, corrected. I thin the letter ” ” is not wor ing correctly 🙂
LikeLiked by 1 person
Hi Jaap, Need some info on a project that am working on. We are performing a AD cross forest with O365 cross tenant migration due to company splitting in to 2 entities.
Source forest has exchange hybrid with 0365. Target forest is without any exchange environment. We are performing simple AD accounts & computers migration using ADMT and O365 mailboxes are being migrated through third party tool with o365 cross tenant capabilities. My question is primarily on the sequence that needs to be followed. What i have thought is below. Will it work ?
1. Add target forest in as additional forest for sync in source AD connect configuration.
2. Perform AD accounts & computers migration using ADMT.
3. Once all the AD accounts & computers are migrated to target forest, perform cross tenant migration for O365.
Can you please advise.
LikeLike
Hi Ahmed,
what do you want to achieve with step 1?
My initial thought would be to configure an Exchange server in the target forest (hybrid server for management purposes), use ADMT to copy users and workstations to the target forest, use Azure AD Connect to sync with target O365 tenant and then use 3rd party tool to perform cross tenant migration.
Cheers, Jaap
LikeLike
Hey Jaap,
So we have a customer that has a Account/Resource forest as you’ve described here. They have successfully migrated all their mailboxes to the cloud. setup adconnect etc.
Now, they would like to remove the “Resource Forest” from their existing environment, and leave their account forest in place.
How would they go about removing the resource forest? and leaving their account forest in place?
If they did remove the resource forest what would happen to their user accounts in the account forest?
Here is a better explanation:
https://techcommunity.microsoft.com/t5/exchange/resource-forest-account-forest-exchange-removal-questions/m-p/1277181
Thanks,
Robert
LikeLike
Hi Robert,
as you already mentioned you need an Exchange server in the account forest to manage the Remote Mailboxes. The thing is, you need to move all Remote Mailboxes (i.e. Mail-Enabled Users) to the account forest. The good thing is, you already have all users accounts there, so it’s just a matter of moving (merging) all Exchange properties of the linked mailboxes into the account forest.
Unfortunately I still have to figure out the most efficient way to do this (and write another blogpost in this series)
LikeLike
Hey Jaap,
Yes. Thats the issue.,
so it’s just a matter of moving (merging) all Exchange properties of the linked mailboxes into the account forest.
I thought we could just run the set-user command and unlink the mailbox, but i now chatting with you i dont know if that will work or not.
Would something like this do:
https://docs.microsoft.com/en-us/exchange/architecture/mailbox-servers/prep-mailboxes-for-cross-forest-moves-in-powershell?view=exchserver-2019
I am pretty sure you cannot just use a script and copy the exchange attributes as the GUID and SIDs etc would all be different.
Thanks,
Robert
LikeLike
What about just using ADMT to migrate/merge the accounts from the resource forest to the account forest?
All of this of course with the migration to office 365 already completed.
Thanks,
Robert
LikeLike