Speeding up the Exchange Hybrid wizard in global deployments

If you ever ran the Exchange Hybrid wizard in an environment with servers all over the world, it is likely that it took a few hours to run. But why?

 

If we look at the wizard’s logs ($exinstall\Logging\Update-HybridConfiguration), we will see that most of the changes are fairly quick. However, it eventually goes on to run a Get-WebServicesVirtualDirectory to analyse the EWS virtual directories (VDs) across all Exchange servers in the environment to determine if any need to be configured. If this comes back true, then the wizard runs the same cmdlet again followed by a Set-WebServicesVirtualDirectory to enable the MRS Proxy for VDs that currently have it disabled. After all the necessary EWS VDs are configured, the wizard runs a Get-WebServicesVirtualDirectory for a third time to validate the configuration/changes made.

 

The problem here is running the *et-WebServicesVirtualDirectory cmdlet between servers in different countries or even continents. How long does it take for you? Usually it should be a few minutes for each server, but I have seen cases where it takes 30 minutes or more. Now multiply that by the total number of Exchange servers and it can quickly turn into hours and hours...

 

If, for example, your environment also has Exchange 2007 servers, although these do not use or have the MRS Proxy service, because the wizard simply runs the Get-WebServicesVirtualDirectory cmdlet, this returns 2007 servers (instead of filtering them out...), which contributes to delaying the process.

 

So, to speed things up a bit, you can manually login to all the servers, enable the MRS Proxy and only then run the Hybrid Wizard. Typically I was only enabling it on the Hybrid servers or servers that I was planning to use for mailbox migration, but the wizard enables it across estate anyway...

 

 

To recap, the Mailbox Replication Service Proxy (MRS Proxy) facilitates cross-forest mailbox moves and remote move migrations between an on-premises Exchange organization and Exchange Online. During cross-forest and remote move migrations (aka hybrid migrations), a Client Access server acts as a proxy for incoming move requests for the Mailbox server. The ability of a Client Access server to accept these requests is disabled by default. To allow the Client Access server to accept incoming move requests, we have to enable the MRS Proxy endpoint.

Azure Active Directory Connect Public Preview

The latest version of the Azure AD Connect has been released – the March 2015 Public Preview update.

The Azure AD Connect wizard Public Preview provides a guided experience for integrating one or multiple AD forests with Microsoft Azure AD. Optionally you can configure Exchange Hybrid deployment, password change write-back, ADFS and Web Application Proxy.

Azure AD Connect encompasses functionality that was previously released as DirSync and AADSync. These tools will eventually stop being released individually and all future improvements will be included in updates to Azure AD Connect.

This latest version has been updated with new capabilities, support for additional sync options, Additional Tasks and “Pilot Mode”.

You can download it from the Connect website.

How to change AADSync credentials

When it comes to changing the credentials AADSync uses to connect to the on-premises Active Directory (AD) or to Azure AD, one might think that re-running the wizard and updating the credentials there would do the trick:

 

However, if you re-run the wizard again, you will see that the old credentials are still being used... So how can we change these credentials?! To do this, we need to use the miisclient.

First, navigate to "install dir"\Microsoft Azure AD Sync\UIShell and run missclient.exe. Then, click in Connectors. Here you will have two connectors, one is used to connect to the local AD and the other to connect to Azure AD:

 

To update the credentials used to connect to the local AD, double-click the respective connector and then go to Configure Directory Partitions. Here, select Alternate credentials for this directory partition, enter the new credentials and click OK:

 

To update the credentials used to connect to Azure AD, double-click the respective connector and then go to Connectivity. Here, enter the new credentials and click OK:

 

Job done!

Dynamic Distribution Lists in a Hybrid Environment

In a hybrid deployment environment between Exchange Online and on-premises Exchange organizations, neither DirSync nor AADSync can be used to synchronize dynamic distribution lists (DDL) to Exchange Online. Therefore, mailboxes that have been migrated to Exchange Online cannot see DDLs in their GAL or email them.

 

To work around this issue, create a MailContact in Exchange Online for the DDL, and then grant permissions so that only authenticated senders can submit messages to the new contact. This object should have the following mappings:

 

On-Premises DDL	Cloud MailContact
Name	Name
proxyAddress	ExternalEmailAddress
Alias	Alias

 

You should also consider the scope of the DDL before mailboxes are moved to Exchange Online. If the scope included only mailboxes, the scope must be expanded to include mail users and mail contacts. To do this, open the properties of the DDL and on the membership tab (in Exchange 2013), also select Mail users with external email addresses. If using the Shell, add MailUsers to the IncludedRecipients property of the DDL.

 

Exchange Online users can now select the DDL from the GAL. When they do, messages will be delivered to the members of the group as defined by the settings for the group.

Exchange Online Protection Conditional Mail Routing

Simply put, Conditional Mail Routing, also known as Criteria Based Routing, is a way of configuring Exchange Online Protection [EOP] connectors in order to send or receive mail a certain way based on the condition of the individual email. For example, we can force TLS for a specific sender or route email based on recipients’ properties to different email server locations.

 

I was recently working on a global Exchange migration to Office 365. This particular client had an Office 365 tenant hosted in Europe with a Hybrid deployment in India. On top of that, there was a separate Exchange organization deployed across the United Kingdom and the United States of America.

For us to be able to update the MX records to point to the client’s Office 365 tenant, two requirements had to be met because of security and legal reasons:

• Requirement 1: emails sent from partners to certain business application mailboxes (hosted on-premises in the UK) had to go directly from Office 365 to the Exchange servers in the UK, i.e., without being routed through India;
• Requirement 2: emails addressed to US users had to go directly from Office 365 to the Exchange server on-premises in the US, i.e., without being routed through India.

To see how we can meet these 2 requirements using Conditional Mail Routing, please check my Exchange Online Protection Conditional Mail Routing article at MSExchange.org.