Using the Office 365 Hybrid Configuration Wizard (Part 4)

by [Published on 28 June 2016 / Last Updated on 28 June 2016]

In the previous parts of this series we have configured pre-requisites for Office 365, gave our environment a once over, understood what the Office 365 Hybrid Configuration Wizard will do and then implemented the basic Hybrid Configuration into our environment. In this part of the series, we’ll begin post-Hybrid configuration steps.

If you would like to read the other parts in this article series please go to:

Basic changes to perform manually to complete Hybrid configuration

After the completion of the Hybrid Configuration Wizard most organisations need to make additional changes. These changes include:

  • Update of on-premises and Office 365 Sharing Policies to allow maximum sharing between both parts of the Hybrid Exchanged organization.
  • Creation of a Migration Endpoint to allow moves of mailboxes to and from Office 365.
  • Update of mailbox email addresses that do not use Email Address Policies.
  • Configure and enable Public Folder co-existence.
  • Copy and configure on-premises policies in Office 365.

We’ll configure the first four of these areas during this part of the series and continue to configure policies in the next part of the series.

Update Sharing Policies

Sharing policies are used to define the limits for Calendar and Contact sharing. By default the policies set up do not allow Exchange sharing using the native Federated Sharing features. To allow native Calendar and Contact sharing between all users, it is necessary to alter the default policies, or create new policies.

To allow sharing between all users in Office 365 and Exchange on-premises (and vice-versa) we will update the default sharing policies both on-premises and in Office 365.

For Exchange 2013 or 2016, navigate to the Exchange Admin Center and select Organization. Select the Sharing tab and then scroll down to Individual Sharing. Choose Default Sharing Policy (DEFAULT) from the list, then choose Edit:

Image
Figure 1: Exchange 2013 and 2016 Sharing Policies

For Exchange 2010, open the Exchange Management Console and navigate to Organization Configuration > Mailbox, then select the Sharing Policies tab. Double click the Default Sharing Policy:

Image
Figure 2: Exchange 2010 Sharing Policies

The Sharing Policy will open. Edit the Sharing with all domains rule (or * rule in Exchange 2010) to allow both the Calendar and Contact calendar to be shared. Typically organizations will want to allow All calendar appointment information to be shared between on-premises and Office 365.

Image
Figure 3: Updating the Sharing Policy

After making the changes, choose Save.

To perform the same change in Office 365, login to the Office 365 portal and from the Admin Center, select the Service Admin centers link, then choose Exchange:

Image
Figure 4: Navigating to the Exchange Admin Center in the Office 365 portal

The Exchange Admin Center for Office 365 will open. Repeat the same procedure within Organization>Sharing:

Image
Figure 5: Updating the Default Sharing Policy in Exchange Online

After this change is complete, users will be able to re-share their calendars between cloud and on-premises. Remember that this is only read-only access, and users who are migrated will need to re-share their calendar if the person they collaborate with is not also moved to Office 365.

Creation a Migration Endpoint

Without a Migration Endpoint it is not possible to move mailboxes to and from Office 365 using the Exchange Admin Center. Instead the New-MoveRequest cmdlets are required.

A migration endpoint allows a definition to be created in Office 365 that includes the on-premises Hybrid server name and a stored set of credentials that can be used to perform the move. This makes it easy to allow multiple administrators to perform migrations without knowing the on-premises migration account password.

First we will create the account that will be used with the Migration Endpoint. Note that you can use an Exchange administrative account, but it is best practice to create an account possessing the minimum permissions required.

Create the account using Active Directory User and Computers. In our example we have created an account name MigUser and set the account password to Never Expire. Next, we’ve added the account to the Microsoft Exchange security group Recipient Management, as shown below:

Image
Figure 6: Group Membership for the Migration Endpoint account

Next, we’ll navigate back into the Exchange Admin Center in Office 365. We’ll then navigate to Recipients, then choose the Migration Tab. Select the more (…) menu, then select Migration Endpoints:

Image
Figure 7: Creating a new Migration Endpoint

We’ll then see the list of currently defined Migration Endpoints. For a new tenant with a freshly ran Hybrid Configuration wizard, nothing should be shown. The next step is to begin the Migration Endpoint Wizard by choosing Add (+), as shown below:

Image
Figure 8: Choosing to add a new migration endpoint

After the New Migration Endpoint Wizard launches three options are shown; Exchange Remote, Outlook Anywhere and IMAP. For Hybrid configurations, Exchange Remote will always be used, so select it from the list, then press Next.

Image
Figure 9: Selecting an Exchange Remote migration

The Migration Endpoint Wizard will use Autodiscover to lookup the Migration Endpoint address. Enter both the email address to use for Autodiscover and then enter the account created in the previous steps as the Account with privileges.

Image
Figure 10: Entering an admin account alongside a test user account

Depending on your external URL configuration for other services like Outlook Anywhere, the Migration Endpoint name may be automatically populated. If it is not, then the Confirm the Migration Endpoint step of the wizard allows the opportunity to enter a server name.

This will typically be the same FQDN used for Exchange Web Services. Enter the server name if necessary, then choose Next:

Image
Figure 11: Entering or confirming the auto-selected Migration Endpoint FQDN

Finally, we’ll give the Migration Endpoint an identifying name and specify the Maximum concurrent migrations and Maximum concurrent incremental syncs. Across all Migration Endpoints (for example if you have multiple Hybrid Servers in different sites) you can have a maximum combined total of 100 concurrent migrations. When choosing the maximum concurrent incremental syncs, consider the split of incremental syncs you wish to reserve. In the example below, we can ensure at least 80 mailboxes will be able to perform initial syncs, with 20 reserved for concurrent incremental syncs:

Image
Figure 12: Entering a Migration Endpoint name and selecting endpoint maximum values

Update Mailboxes that do not use Email Address Policies

As part of the Hybrid Configuration Wizard, Email Address Policies are updated to include an additional address which will be used for co-existence. Each mailbox that will be migrated needs this address added, which is in the form of <alias>@<tenantname>.mail.onmicrosoft.com.

Mailboxes that do not automatically update email addresses based on the email address policy will not have these additional addresses added.

Image
Figure 13: Viewing mailbox email addresses

For each mailbox that does not have the email address policy automatically applied, there are two ways to add the missing address. The first method is to manually add a new SMTP address, as shown below:

Image
Figure 14: Adding a routing email address manually

The second, simpler way, is to change the mailbox back to Automatically update email addresses based on the email address policy applied to this recipient, as shown below:

Image
Figure 15:
Updating the mailbox to use Email Address Policies

Configure Public Folder Coexistence

If you are using Public Folders on-premises, and plan to either maintain access to Public Folders during Hybrid Co-existence; or migrate Public Folders to Office 365 from a legacy version of Exchange then you will want to configure access from Office 365 to on-premises.

Providing access to clients is relatively straightforward.

To ensure that mail-enabled Public Folders are listed in the Office 365 Global Address List and / or can be sent email from Office 365 mailboxes you should use Microsoft-provided script to create equivalent contact records in your Office 365 tenant.

After downloading the Sync-MailPublicFolders.ps1 and associated strings file to the same directory, execute the following commands to sync Public Folders. Note that this will delete any Public Folders in your existing tenant, so read the document for Exchange 2010 or 2013/2016 first.

$Credential= Get-Credential

.\Sync-MailPublicFolders.ps1 -Credential $Credential -CsvSummaryFile .\Summary.CSV

Image
Figure 16:
Executing the Public Folder Sync script

For a pure Exchange 2013 or 2016 environment then navigate to Public Folders and make a note of all Public Folder mailboxes. For Exchange 2010, you’ll need to follow a couple of more steps to create accounts, and potentially install additional server role.

These names will be used by Office 365 to return an address for the clients to use to discover the right location to connect to:

Image
Figure 17: Viewing Public Folder mailbox names

Next, login to Exchange Online PowerShell. Connect to Office 365, then use the Set-OrganizationConfig cmdlet to enable Remote Public Folders and then enter a comma-separated list of Public Folder mailboxes:

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session

 

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMailbox01,PFMailbox02

Summary

In this part of the series, we’ve performed a number of post configuration steps to enable functionality required for most organizations for Exchange Hybrid. In the penultimate part of this series, we’ll configure policies and then begin performing some core service tests.

If you would like to read the other parts in this article series please go to:

See Also


The Author — Steve Goodman

Steve Goodman avatar

Steve Goodman is an Exchange MVP and works as a Technical Architect for one of the UK's leading Microsoft Gold partners.

Advertisement

Featured Links