Tag Archives: Resource Forest

Exchange Hybrid

Exchange Resource Forest and Office 365 Part V

2 Comments

Upgrade to Exchange 2016

Two years ago I wrote a number of blogpost regarding an Exchange Resource Forest model and Office 365 starting at Exchange Resource Forest and Office 365 part I. There are four articles, all based on Exchange 2010 and at the end of each article you’ll find a link to the next article. In the more information section at the end of this blogpost you’ll find all links.

Over the years I have received numerous requests on how to continue; moving to Exchange 2016 in a Resource Forest or when all mailboxes are in Exchange Online, decommission the Resource Forest. This is not a problem, but brings a new challenge when it comes to the last Exchange server for management purposes that need to be kept. And yes, this blogpost is the preparation for the ‘decommision the resource forest’ blogpost 😉

I have a few customers running a resource forest environment, and all have this same problem. They must move away from Exchange 2010, either to Exchange 2016 or to Exchange Online (or both). In this blogpost I’ll discuss the upgrade from Exchange 2010 in a Resource Forest to Exchange 2016 (in the same Resource Forest of course) in a hybrid scenario. In one of the next blogs I’ll discuss the way to decommission the Resource Forest in a hybrid scenario.

Note. I did a webinar recently for Kemp on the Upgrading Exchange 2010 topic. It’s a Brighttalk hosted webinar that you can find here The Best Known Methods on Upgrading Microsoft Exchange.

Upgrading Exchange 2010 to Exchange 2016

Upgrading Exchange 2010 in a resource forest is not different then upgrading any other Exchange environment, not even when running this in a hybrid environment. These are the steps that need to be taken:

Design your Exchange 2016 environment (won’t cover that in this blogpost).

  1. Prepare Active Directory for Exchange 2016.
  2. Build your Exchange environment.
  3. Change client access to Exchange 2016.
  4. Run Hybrid Configuration Wizard.
  5. Move Resources to Exchange 2016.
  6. Decommission Exchange 2010.

Prepare Active Directory for Exchange 2016

Before you can install the first Exchange 2016 server, Active Directory needs to be prepared. This is only true for the resource forest, there’s no need to do this at the account forest.

You can prepare the Active Directory schema using the following command:

C:\> Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

It is possible that the following error message is shown:

A hybrid deployment with Office 365 has been detected. Please ensure that you are running setup with the /TenantOrganizationConfig switch. To use the TenantOrganizationConfig switch you must first connect to your Exchange Online tenant via PowerShell and execute the following command: “Get-OrganizationConfig | Export-Clixml -Path MyTenantOrganizationConfig.XML”. Once the XML file has been generated, run setup with the TenantOrganizationConfig switch as follows “/TenantOrganizationConfig MyTenantOrganizationConfig.XML”.

This issue is covered in a previous blogpost: A hybrid deployment with Office 365 has been detected.

Build your Exchange environment

Exchange 2016 can be installed on Windows Server 2012 R2 and Windows Server 2016, I always recommend the latter because of support lifecycle. Windows Server 2019 and Windows Server Core are not supported for running Exchange 2016.

I prefer to install the Exchange 2016 server unattended, especially if you must install multiple servers. You can use a command similar to this:

C:\> Setup.exe /Mode:Install /Roles:Mailbox /DbFilePath:”F:\MDB02\MDB02.edb” /LogFolderPath:”F:\MDB02\LogFiles” /InstallWindowsComponents /IAcceptExchangeServerLicenseTerms

Unattended Setup

After installing the Exchange server, the server should be configured:

  • Virtual Directories; make sure you use the same internalURL and externalURL as the Exchange 2010 servers.
  • SSL Certificates.
  • Storage, Databases and Database Availability Group (when needed of course).
  • Relocate (IIS) logfiles.
  • Send and Receive Connectors (SMTP Relay).

Change client access to Exchange 2016.

When you have configured the Exchange 2016 it is time to test the proxy functionality from Exchange 2016 to Exchange 2010. The easiest way to test this is to edit the HOSTS file for the webmail.contoso.com and Autodiscover.contoso.com entries on a client and point it to the Exchange 2016 server.

hosts file

From the client, connect to the new Exchange 2016 server and start OWA with an Exchange 2010 mailbox. You should see the initial blue OWA screen:

Exchange 2016 OWA Login

And after logging on the yellowish Exchange 2010 OWA user interface. It will automatically proxy to the correct Exchange 2010 mailbox server:

Exchange 2010 OWA Login

The same should happen when you request the Exchange Web Services page on https://webmail.contoso.com/ews/exchange.asmx, this should also successfully proxy to Exchange 2010:

EWS proxy

One important thing here is that this is a down-level proxy only. This means that when a client does a request to Exchange 2016 for a resource on Exchange 2010 (down-level proxy, like in the previous example) it should work. If a client does a request to Exchange 2010 for a request on Exchange 2016 (i.e. up-level proxy) it fails. This is shown in the following figure, and it does not work.

downlevel uplevel

When all is configured and tested, DNS (internal and external) can be changed so that webmail.contoso.com and Autodiscover.contoso.com point to the new Exchange 2016 server. All clients will now connect to the new Exchange 2016 server and connect to their mailbox on Exchange 2010 without a problem.

One thing you must be aware of is RPC/TCP traffic (the original MAPI connection) between Outlook and Exchange 2010 if you are not running Outlook Anywhere. Outlook will still use RPC/TCP to connect to the CAS Array (this is the RPC Endpoint for Outlook) which is running on the Exchange 2010 servers. You can see that when checking the connection status in Outlook. In the following screenshot, outlook.exchangefun.nl is the CAS Array.

Outlook 2010 Connection Status

There are two entries shown, one is for the regular mailbox, the second is for accessing a shared mailbox on Exchange 2010.

When performing the Test E-mail AutoConfiguration check on Outlook 2010, you can see that RPC Connects to outlook.exchangefun.nl, but that OWA, EWS and OAB want to connect to webmail.exchangefun.nl, which is the Exchange 2016 server now.

Outlook 2010 Test Email AutoConfiguration

So, Outlook connects using RPC to the Exchange 2010 server and using HTTPS to connect to the Exchange 2016 server. From Exchange 2016 the connection is proxied to the correct Exchange 2010 server.

Note. Be aware that if you have configured Kerberos authentication in your Exchange 2010 environment you have to upgrade this to Exchange 2016 as well. This is documented in the Microsoft articles Recommendation: Enabling Kerberos Authentication for MAPI Clients, How to Enable Kerberos Authentication for Accessing Exchange in a Resource Forest andExchange 2013 and Exchange 2010 Coexistence with Kerberos Authentication. For Exchange 2010/2016 coexistence you can follow that last link.

Run the Hybrid Configuration Wizard

When all is running well it is time to upgrade the Hybrid Configuration by running the HCW on the Exchange 2016 server. You can find the latest version of the HCW on http://aka.ms/hybridwizard.

The HCW will detect the optimal Exchange server to configure (which should be automatically the Exchange 2016 server). You should select the Exchange 2016 server for the Receive Connector Configuration and the Send Connector Configuration. For the Organization FQDN I typically use the default FQDN (like webmail.contoso.com) to keep everything consistent. Sometimes I see admins use something like hybrid.contoso.com but that doesn’t bring much, except for more complexity.

HCW Organization FQDN

When reaching the end of the HCW you can select to upgrade the Hybrid Configuration. The original Hybrid Configuration was created on Exchange 2010, but now it is upgrade to Exchange 2016 so I don’t see any reason to not check the checkbox.

HCW Upgrade current configuration

The easiest way to check the new Hybrid Configuration is to see if free/busy works cross-premises. Open a mailbox in Exchange Online and check if you can plan a meeting with a mailbox in Exchange 2010 and check the availability of this mailbox. Baron’s mailbox is in Exchange Online, my mailbox is in Exchange 2010 (still). The free/busy request is sent to webmail.exchangefun.nl which is now the Exchange 2016 server. From there it is proxied to the Exchange 2010, and it works like a charm:

Cross-premises freebusy

To check if cross-premises mail security you can send an email from an online mailbox to an on-premises mailbox. If you check the headers, the SCL should have a value of -1 (which means it is treated as an internal message) and the X-MS-Exchange-CrossTenant-AuthAs should have a value ‘Internal’.

At this moment there is an Account and Resource Forest environment, where the Resource Forest contains an Exchange 2010/2016 coexistence environment. All clients, including Exchange Online connect to Exchange 2016 while recipients are still on Exchange 2010.

Exchange 2010 2016 Coexistence

Move Resources to Exchange 2016

At this moment, mailboxes can be migrated from Exchange 2010 to Exchange 2016. And to be honest, this is not that exciting. It is fully transparent for users. It is an online process, so the mailbox content is copied from Exchange 2010 to Exchange 2016 while the user continues to work. Only when the move is finalized, the user is presented the following message box and needs to restart Outlook.

The Microsoft Exchange Administrator has made a change

Now back to the RPC/TCP (MAPI) part earlier in this post. Exchange 2016 does not support RPC/TCP anymore, so when a mailbox is moved from Exchange 2010 to Exchange 2016, the protocol changes as well. In this case, it changes from RPC/TCP to Mapi/Http for Mailboxes, and to Outlook Anywhere for Public Folders (still on Exchange 2010, but Exchange 2010 does not support Mapi/Http).

Outlook 2010 Connection Status Exchange 2016

Public Folders (if any) must also be moved to Exchange 2016. This can only be done when all mailboxes are moved to Exchange 2016. A mailbox on Exchange 2016 can access Public Folders on Exchange 2010, but a mailbox on Exchange 2010 cannot access Public Folders on Exchange 2016. The Public Folder migration is covered in my previous blogpost Exchange 2010 Public Folder migration, which was also performed on my Exchange resource forest environment.

In an Exchange 2010/2016 coexistence environment there are two Offline Address Books:

  • Default Offline Address Book – used in Exchange 2010
  • Default Offline Address Book (Ex2013) – used in Exchange 2016 (the name was not changed when Exchange 2016 was introduced, not sure if this is a cosmetic bug but it does work correctly).

When configuring the Mailbox databases makes sure the \Default Offline Address Book (Ex2013) is set on the OfflineAddressBook property of the Mailbox database.

One pitfall that always takes more time than expected is the Receive Connector configuration, especially for SMTP relay purposes. Multiple devices (scanners, faxes), printers, applications, access on IP level, lack of documentation etc. Use the Protocol logging features on the various Receive Connectors to figure out what devices or applications are using these Connectors and configure them to use the Exchange 2016 server. But beware, this can take a lot of time ☹

Edge Transport Server

You might have noticed I have an Exchange 2010 Edge Transport server running. This is used for SMTP traffic to and from the Internet. My MX record is pointing to the Edge Transport server, but cross-premises SMTP is delivered directly on the Mailbox server.
When is the best time to upgrade the Edge Transport server to Exchange 2016? There’s no real rule of thumb for this. The Exchange 2010 Edge Transport server works fine with an Exchange 2016 Mailbox server, but the other way around also works fine. I typically upgrade the Edge Transport servers to Exchange 2016 after installing the Mailbox servers, but before moving Mailboxes. But there are much more options when doing this.

Decommissioning Exchange 2010

When all resources have been moved to Exchange 2016 you can decommission the Exchange 2010 environment. This is just a matter of:

  • Decommissioning Mailbox database copies.
  • Decommission the Database Availability Group.
  • Remove Mailbox databases.
  • Remove the Public Folder databases (if not removed earlier).
  • Change/Remove Send and Receive Connectors (also see previous section).

When all prerequisites for the decommissioning process have been met, the actual Exchange 2010 servers can be uninstalled. I still see admins just removing the Exchange VM’s but this is not a good idea since the Exchange configuration continue to exist in Active Directory.

Properly remove the Exchange 2010 server using Control Panel and Uninstall or change a program by deselecting all options as shown in the following screenshot.

Uninstall Exchange 2010

After a few minutes the Exchange 2010 server will be fully installed (the official way).

Summary

In this blogpost I explained how to upgrade Exchange 2010 to Exchange 2016 when running in a resource forest configuration, and in a hybrid configuration. The process is not very different from an upgrade in a ‘normal’ single forest, single domain environment, not even from a hybrid perspective.

The process is simple, upgrade Active Directory, install and configure the servers, change client access to Exchange 2016 and run the Hybrid Configuration Wizard. When done you can move resources to Exchange 2016 and when finished decommission the Exchange 2010 environment.

In part VI of this series I’ll discuss how to decommission a resource forest in a hybrid configuration.

More information

Exchange Hybrid

Exchange Resource Forest and Office 365 – Part IV

21 Comments

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 C.Smith@exchangefun.nl -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:

image

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.

image

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:

image

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:

image

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 j.doe@exchangefun.onmicrosoft.com

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 C.Smith@exchangefun.nl -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 C.Smith@exchangefun.mail.onmicrosoft.com

# 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!

Summary

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.

Exchange Hybrid

Exchange Resource Forest and Office 365 – Part II

27 Comments

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:

image

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:

image

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:

image

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:

image

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.

image

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:

image

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.

image

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:

image

image

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:

image

image

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.

image

Continue the Azure AD Connect wizard, and in the Optional Features select the Exchange Hybrid Deployment checkbox and click Next to continue.

image

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.

image

At the configuration complete window there are some recommendations and/or remarks for your reference, click Exit to stop the Azure AD Connect wizard.

image

Now, when you logon to the Microsoft Portal you’ll see that synchronization has occurred:

image

And when you expand the users option you’ll see which users are synchronized.

image

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.

image

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 Smile