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.