Exchange Resource Forest and Office 365 – Part IV

In the past three blogposts I’ve showed you the basics of Linked Mailboxes in a Resource Forest, how to implement Azure AD Connect is this environment and how to setup Exchange Hybrid in a Resource Forest model.

Another challenge is how to provision users in a Resource Forest setup, especially when it comes to provisioning mailboxes directly in Office 365.

In a normal, single forest environment you would create a new user in Active Directory and execute the Enable-RemoteMailbox command in Exchange PowerShell to directly create a Mailbox in Office 365. In a Resource Forest model you will run into some issues though….

In this blogpost I will show you how to manually create Linked Mailboxes and the accompanying user accounts and how to create a Linked Mailbox, but directly in Office 365. I’ll show you the unsupported way using ADSI Edit (for educational purposes) and the supported way to achieve this.

Provision a Linked Mailbox

To provision a Linked Mailbox a new user account in the Account Forest need to be created and a (somewhat) identical, but disabled user account need to be created in the Resource Forest.

The most basic option to do this is to execute the following commands in PowerShell on a Domain Controller in the Resource Forest:

Import-Module ActiveDirectory
$AccountsCred = Get-Credential Accounts\administrator
$Password = ConvertTo-SecureString -String "P@ss1w0rd!" -AsPlainText -Force

New-ADUser -Name "C.Smith" -Server ACCDC01.accounts.local -Credential $AccountsCred -UserPrincipalName -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Accounts,DC=Local" -AccountPassword $Password -Enabled:$TRUE

This will create a new user account in the Accounts Forest. Next is to create a similar, but disabled user account in the Resource Forest by executing the following command:

New-ADUser -Name "C.Smith" -Server RESDC01.resources.local -UserPrincipalName C.Smith@resources.local -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Resources,DC=Local" -AccountPassword $Password -Enabled:$FALSE

To create a new Linked Mailbox for this user account, we can execute the Enable-Mailbox with the -LinkedDomainController and -LinkedMasterAccount options against this new user account in the Resource Forest. This should be executed in the Exchange Management Shell, but you can also start a Remote PowerShell session in the current regular PowerShell window using the following commands:

$AdminCred = Get-Credential resources\administrator
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://RESEXCH01/PowerShell/ -Authentication Kerberos -Credential $AdminCred
Import-PSSession $Session

Note. You can also execute Import-Module ActiveDirectory in an Exchange Management Shell window on the Exchange server, but my Exchange 2010 server is running on Windows 2012. This is PowerShell 2.0 and generates an error when importing the Active Directory module.

So, the command to create the Linked Mailbox and user the user account we’ve just created in the Accounts Forest should be:

Get-User C.smith | Enable-Mailbox -LinkedCredential $AccountsCred -LinkedDomainController ACCDC01.accounts.local -LinkedMasterAccount "C.Smith"

With commands shown in the previous blog on Linked Mailboxes we can check the objectSID and the MsExchMasterAccountSID:


Azure AD Connect will make sure (just like in the previous blog posts) based on the objectSID and MsExchMasterAccountSID that the new user account and mailbox information will be synchronized with Azure Active Directory and it will appear in the Office 365 address book.

Now we can move this Mailbox to Office 365, but it’s not the most efficient way to create new Mailboxes, especially when the new Mailboxes should be created in Azure Active Directory.

Enable-RemoteMailbox in a Resource Forest with ADSI Edit (Not Supported)

The Enable-RemoteMailbox PowerShell command seems like a much more efficient way to provision Mailboxes in Office 365. The problem however is to connect the user account in the Account Forest with the disabled account in the Resource Forest. Let’s give it a try…

Create two users, one regular account in the Account Forest and one disabled account (acting as a placeholder) in the Resource Forest. When Azure AD Connect kicks in you’ll see two user accounts appear in Office 365 for this user.


The unlicensed account originates from the Account Forest, the blocked account originates from the Resource Forest. This is treated as two separate accounts because Azure AD Connect cannot create the joined identity as it does with a regular Linked Mailbox, because there’s no objectSID value stamped on the MsExchMasterAccountSid property. There’s no MsExchMasterAccountSid at all since there’s no Linked Mailbox, and we’re at this point not planning to create a Linked Mailbox either, sigh…

An option (but totally unsupported) to overcome this is to stamp the objectSID value of the regular user account on the MSExchMasterAccountSid property of the disabled account, prior to the next synchronization cycle of Azure AD Connect. When properly set, Azure AD Connect connects the two accounts and synchronizes only the regular user account with Azure AD Connect and only this user account will appear in Azure Active Directory.

You can try this by copy-and-paste this value using ADSI Edit, it gladly accepts the hexadecimal value as shown in the following figure:


Using PowerShell is easy for scripting, but involves a bit more work. Right after creating the two user accounts you have to retrieve the objectSID value of the user account in the Account Forest using the following commands:

$objectSID = Get-ADUser -Filter {SAMAccountName -eq "j.doe"} -properties * -server accdc01.accounts.local -Credential $AccountsCred | Select SID

The command $objectSID.SID.Value will show the value of the objectSID:


Setting the objectSID on the MsExchMasterAccountSid using Set-ADUser works with the -replace option. Use the previous command to retrieve the user account, and use the pipe command to parse it into the Set-ADUser command (only the Set-ADUser command is shown here):

Set-ADUser  -replace @{msExchMasterAccountSid = $objectSID.SID.Value

Now the two accounts are tied together (when it comes to Azure AD Connect) and you can execute the Enable-RemoteMailbox command:

Get-User -Identity j.doe | Enable-RemoteMailbox -RemoteRoutingAddress

Again, this works fine but it is not supported. I primarily explained this to show what’s going on under the hood.

Enable-RemoteMailbox the supported way

A better and most likely supported way (thanks to fellow MVP Mike Crowley) is to create a Remote Mailbox and connect the disabled user account in the Resource Forest to the user account in the Account Forest using the Set-User command (with the -LinkedMasterAccount option) before Azure AD Connect runs and synchronizes the information to Azure Active Directory.

All steps would be:

  1. Create a user account in the Account Forest
  2. Create a disabled user account in the Resource Forest
  3. Enable-RemoteMailbox this disabled user account
  4. Set the LinkedMasterAccount properties

In PowerShell this would be:

Import-Module ActiveDirectory
$AccountsCred = Get-Credential Accounts\administrator
$ResourceCred = Get-Credential resources\administrator

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://RESEXCH01/PowerShell/ -Authentication Kerberos -Credential $ResourceCred
Import-PSSession $Session

$Password = ConvertTo-SecureString -String "P@ss1w0rd!" -AsPlainText -Force

# Create the user account in the Account Forest
New-ADUser -Name "Clyde Smith" -SAMAccountName C.Smith -Server ACCDC01.accounts.local -Credential $AccountsCred -UserPrincipalName -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Accounts,DC=Local" -AccountPassword $Password -Enabled:$TRUE

# Create the disabled account in the Resource Forest
New-ADUser -Name "Clyde Smith" -Server RESDC01.resources.local -SAMAccountName C.Smith -UserPrincipalName C.Smith@resources.local -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Resources,DC=Local" -AccountPassword $Password -Enabled:$FALSE

# Create a Remote Mailbox for this user (in the Resource Forest)
Get-User "C.Smith" | Enable-RemoteMailbox -RemoteRoutingAddress

# Set the LinkedMasterAccount properties
Get-User "C.Smith" | Set-User -LinkedCredential $AccountsCred -LinkedDomainController ACCDC01.accounts.local -LinkedMasterAccount "Clyde Smith"

Now two user accounts are set, the Remote Mailbox in Office 365 is created, the account in the Resource Forest is linked to the account in the Account Forest. All set and fully supported!


When using an Exchange Resource Forest with Linked Mailboxes and you want to provision new Mailboxes in Office 365, the most common way is to create a Linked Mailbox and move the empty Mailbox directly to Office 365. While this works will it is not the most efficient way and moving mailboxes can be time consuming, even when they’re empty.

Another way is to create two user accounts and fiddle around with ADSI Edit and create a Remote Mailbox in Office 365. This is fun to do in a lab environment, but not supported.

The best way to achieve this is to create two user accounts, and create a Remote Mailbox on the disabled account in the Resource forest. Once created use the Set-User command with the -LinkedMasterAccount option to link the Remote Mailbox to the user account in the Account Forest. The only catch here is to run all commands before Azure AD Connect kicks in, otherwise you will get unexpected results (i.e. multiple accounts in Azure Active Directory).

In part V of this series I’ll discuss how to upgrade this resource forest from Exchange 2010 to Exchange 2016. If you don’t want to upgrade but have moved everything to Office 365 you can go to part VI of this series where I explain how to decommission a resource forest in this environment.

21 thoughts on “Exchange Resource Forest and Office 365 – Part IV”

  1. Excellent series. Suggestion for part V – how to remove the on-premises components once all mailboxes have been migrated.


  2. Hi Jaap

    nice article (the complete series) and really appreciate for sharing these unique case studies for the greater benefit of the community.

    I have one question whereas I have a similar situation but in this case we need to discard the resource forest completely after we migrated the mailboxes to office 365 . In that case can we follow the standard way of discarding the resource forest (on prem exchange and the resource forest AD). OR do we need follow some additional steps.




    1. Hi Muralee,
      That is an excellent question is a typical response when people don’t know the answer 🙂
      Same is true for me, but I’ve never thought of it at this moment. I will get back on this, but in short, you have to remove the resource forest from Azure AD Connect, and add an Exchange server for management purposes to the account forest (the official supported way, but there are more). Let me work on the details (but I’m at Ignite now, and working on some Exchange 2019 stuff) so I need some time.

      Liked by 1 person

  3. Hi Jaap and hi Muralee,
    Besides of an Exchange as Admin Station in your user forest you will have to write all the Exchange attributes on the users in your user forest. Also don’t forget to change mailrouting if centalized mail transport was in place.



    1. I have this exact scenario and want to remove my exchange resource forest. The “write the exchange attributes to the user forest” is where I’m stuck.


  4. All good – and it works really well up

    What can be done when the time comes to that the resource forest is to be decommissioned.

    account forest – AAD Connect server on dedicated member server
    Accounts get created OK office 365 following the AAD sync

    resource forest with Exchange 2010 Server – hybrid installed

    All mailboxes already migrated to Office 365

    Local Account forest still holds resources required


    1. You have to prepare the account forest for Exchange 2016, install the Exchange management server and make sure all related properties from the Remote-Mailboxes in the resource forest are correctly copied to the corresponding accounts in the account forest.


      1. Hi Jaap,
        Very informative blog! Thank you.

        Wondering if you could add to your comment noted above where you state “make sure all related properties from the Remote-Mailboxes in the resource forest are correctly copied to the corresponding accounts in the account forest”.

        Is there a specific list of attributes that would require copying? Is this just a export/import operation or is there a specfic tool/method required for this operation?


      2. I haven’t run into this specific scenario (decommissioning the resource forest I mean) so I don’t have a list of related properties. Let me discuss and get on this, it is an interesting question.


  5. Hi I too am interested in what it looks like to decommission the resource forest. I have a customer that through acquisitions have accumulated 36 different account forests with linked mailboxes in their single resource forest. They now want to spin off these 36 different domains into their own O365 tenants. I’m able to use Azure AD Connect to sync from both the account and resource forest and use OU filtering to only sync the users I need, but would like to offer a way to remove that resource forest from sync after the mailboxes are migrated. Any suggestions on what that would look like and what attributes need to be copied onto the user accounts in the account forest would be great. Thanks!


    1. 36 accounts forests? Synchronizing simultaniousy? Must be a provisioning nightmare.
      My ‘problem’ is that I need my account/resource forest lab environment for one of my clients. I can move everything to Office 365 and decommission the resource forest, but then I have a test environment that doesn’t match my customer environment in any way. I have to figure that one out first i’m afraid.


      1. Hi Jaap, yeah, the scenario is the same that you describe in the article, so it means I have a Resource Forest (active directory and exchange) and then more logon active directories. As for creating a new user, I’m following the approach that you suggest:
        1)create the user in my logon active directory
        2)create a disabled user in the resource active directory
        3)create a Remote mailbox and connect the disabled with the user that I have in my logon active directory.
        So, when Azure Ad Connect syncs, everything will work (cool).
        Now, I wonder if it’s possible to manage in the same way as the distribution group. From my experiments, I can’t handle a distribution group stored in my account distribution group and one in the Resource forest because then I will have two distribution groups in the cloud when Ad Connect synchronizes.
        Of course, I tried to create my distribution group in the Account Forest, but then I can’t define one organizational unit in my logon active directory.
        Is there the right way to manage distribution and security groups?
        I hope my scenario is a bit clear. Thanks a lot for whatever you would suggest to me.


      2. I know what you mean and there’s no solution for that. You have to maintain groups in two directories. Distribution Groups in the resource forest and Security Groups in the account forest. There’s no way to mix and match. What you can do is use Security Groups in the account forest and store them in an OU that is not synced with Azure AD. This will prevent duplicate groups in Azure AD.

        Liked by 1 person

  6. It is the first clear and complete answer that I have received about this topic, so thank you a lot Jaap.
    So, as for adding members, I should add members in both cases (Resource and logon active directory).
    As for the Resource Forest, I may add members (I suspect that I have to use disabled users) from different logon active directories. Is it right? So if I’m right, a group in the logon active directory will have not the same members of the group in the Resource forest (those two pictures could be a bit different)


    1. Thanks for your nice comment 🙂
      Keep in mind that for the Distribution Group (in the resource forest) you only have to add the mailbox (i.e. the disabled user) to the Distribution Group. That’s all, and this will be synced with Azure AD so that the same DG is available in Exchange Online.
      The Security Groups in the account forest have nothing to do with Exchange in the resource forest.

      Liked by 1 person

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s