Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 27)

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

Introduction

In part 26 of this article series revolving around what the Windows Azure service is all about as well as how you deploy an Exchange hybrid deployment in Windows Azure, we finished our Exchange hybrid configuration by enabling the OAuth configuration piece as well as talked about what OAuth is and how it relates to an Exchange hybrid deployment. That article also included a sidebar talking about the so called autodiscover domain feature.

In this part 27, we will continue where we left off in part 26.

Let’s get going…

Verifying the Exchange Hybrid Configuration

Now that we established a hybrid configuration between our on-premises Exchange 2013 organization and Exchange Online in Office 365, let’s take a look at the things that were created behind the scenes when we ran the Hybrid Configuration Wizard (HCW) in order to ensure they have been configured appropriately and to also provide you with an insight into what kind of magic is being configured, when you just click a few buttons.

Anyone remember the Exchange hybrid wizard days where you had a huge amount of documented steps to go through and perform something like 80 manual configuration steps? Bet Microsoft CSS had a lot of fun supporting customers with their hybrid deployments. Okay customer so you say step 67 fails? Hmm let’s go back from the beginning shall we!

All right, so let’s first look at the hybrid configuration object itself. We can do so by launching the Exchange Management Shell (EMS) and run the following command:

Get-HybridConfiguration

Image
Figure 1:
Listing the configuration for the hybrid configuration object in the on-premises Exchange organization

As you can see above in Figure 1, the settings (such as receiving and sending transport servers, on-premises smart host and domains) you specified when we ran the wizard have been set on the hybrid configuration object. But, this is far from the only thing that has been configured. You can also see which features have been enabled (“FreeBusy”, “MoveMailbox”, “Move Mailbox”, “MailTips”, “MessageTracking”, “OwaRedirection”, “OnlineArchive”, “SecureMail” and “Photos”), which are all features we want to have enabled between the on-premises Exchange organization and the Exchange Online organization in Office 365.

Important:
The “ClientAccessServers” parameter is deprecated and will be removed from Exchange Server 2013 sometime in the future, which explains why it is blank. Also, bear in mind that we no longer need to have any public IP addresses configured for the hybrid configuration. This was required in Exchange 2010 based hybrid deployments so that we could specify the IP addresses that were allowed to send to the inbound connector in FOPE.

Note:
Since we do not use Exchange 2010 Edge Transport servers or have enabled centralized transport, the “EdgeTransportServers” attributes is blank and “CentralizedTransport” is missing under “Features”.

In addition, the following has also been performed in the on-premises Exchange organization:

  1. A federation trust with the Microsoft Federation Gateway (MFG) has been established for the specified domain:

Image
Figure 2:
Federation Trust in the Exchange admin center

Creating a federation trust with the MFG is required in order to be able to set up an organizational relationship which again is required in order to share free/busy information and calendars between the on-premises Exchange organization and the Exchange Online organization in Office 365. With that said, it’s important to note that a trust isn’t set up with the MFG, instead the MFG merely acts as a trust broker between the involved Exchange organizations.

  1. “tenant_name.mail.onmicrosoft.com” (in our scenario “azurelab.mail.onmicrosoft.com”) has been added as an accepted domain:

Image
Figure 3:
New accepted domain in the Exchange admin center (EAC)

Adding the “tenant_name.mail.onmicrosoft.com” domain to the “Accepted Domains” list as an authoritative domain is required in order for the on-premises Exchange organization to accept inbound e-mail messages destined for a mailbox user located in Exchange Online. When a mailbox is moved from the on-premises Exchange organization to Exchange Online, the source mailbox user object is converted to a mail user object, which is configured with an external address of “[email protected]“. We will look more at this later in this article series.

  1. “tenant_name.mail.onmicrosoft.com” (in our scenario “azurelab.mail.onmicrosoft.com”) has been added as a remote domain. Since remote domains are not exposed in the Exchange admin center (EAC), we must use the “Get-RemoteDomain” cmdlet to see this.

Image
Figure 4:
New remote domains in the Exchange Management Console

A remote domain is an SMTP domain that is external to our Exchange organization. When a new remote domain is created, it’s possible to specify the remote domain is used for Exchange Online purposes. With a remote domain, we can configure out of office and message formatting settings and more. The HCW configures the ideal setting for a hybrid and enables the SMTP domain as the domain used for an Office 365 tenant, which is important in relation to provisioning of new remote mailbox users (users that get a mailbox created directly in Exchange Online).

  1. The default E-Mail Address policy has been updated so that it stamps a secondary proxy address ([email protected]) on mailbox user objects:

Image
Figure 5:
New SMTP address added to the default E-mail Address Policy

The SMTP address “[email protected]“ is added to the default E-mail address policy so that it can be stamped as an additional proxy address on the mail objects in the organization. As mentioned earlier, when a mailbox is moved to Exchange Online, the source mailbox user object is converted to a mail user object and in order to be able to set “[email protected]“ as the external e-mail address, it must already be stamped on the object.

Image
Figure 6:
Secondary proxy address stamped on mailbox user object

  1. In addition, the HCW will create a send connector that will route all e-mail messages destined for “tenant_name.mail.onmicrosoft.com” (in this scenario “azurelab.mail.onmicrosoft.com”) in our on-premises Exchange 2013 environment to Exchange Online in Office 365 (see Figure 7).

Image
Figure 7:
Outbound connector to Office 365

The send connector is configured to use DNS to look up the MX record of the destination server.

Image
Figure 8:
DNS used to lookup the MX record for the destination server

The send connector is configured with an address space of “azurelab.mail.onmicrosoft.com”, so that only e-mail messages destined for Exchange Online users in Office 365 is routed via this send connector.

Image
Figure 9:
Address space for the outbound connector to Office 365

Unlike with Exchange 2010 based hybrid deployments, the HCW no longer creates an Office 365 specific receive connector on our hybrid servers (see Figure 10).

Image
Figure 10:
No Office 365 specific receive connectors created by the HCW

  1. Finally, as we could also see back in Figure 2, an organizational relationship has been created to establish Exchange federation with the Exchange Online organization in Office 365. Detailed setting for this can be seen in Figure 11.

Image
Figure 11:
Listing details for the organizational relationship

Just like is the case with Exchange 2010 based hybrid deployments, by default, free/busy is enabled with limited details. In addition, mailbox moves, delivery reports, mailtips and online archive are enabled. Moreover, a target OWA URL is specified and by default set to: “http://outlook.com/owa/tenant_name.onmicrosoft.com”. The target OWA URL is the URL that a user will be non-transparently redirected to (we will look at this later in this article series), when he tries to access his mailbox using the existing OWA namespace (i.e. http://mail.domain.com/owa) after his mailbox has been moved to Exchange Online. Lastly, a target autodiscover Epr has been set by the HCW. This is the endpoint used to reach out to the Exchange Online organization for the configured features when a request comes from the on-premises Exchange organization to the Exchange Online organization.

Note:
With the release of Exchange 2013 CU8 and Exchange 2010 SP3 UR9, the target OWA URL on the set for the organization relationship is not only used for OWA redirection purposes, but also for automatic redirection of Exchange ActiveSync (EAS) based devices.

So as you probably remember, we configured OAuth back in our previous article. Let’s take a look at what is configured behind the scene on the on-premises side, when the OAuth (post)-step in the HCW is completed.

  1. First an authorization server object for the Exchange Online organization is created in the on-premises Exchange organization. You can see this by running Get-AuthServer | fl as shown in Figure 12.

Image
Figure 12:
Authorization server object for the Exchange Online organization

  1. Next, partner application is enabled and configured for the Exchange Online organization. This can be retrieve using the Get-PartnerApplication | fl cmdlet as shown in Figure 13.

Image
Figure 13:
Partner application enabled for the Exchange Online organization

  1. Lastly an Intra Organization Connector to the Exchange Online organization is created and configured with the on-premises discovery endpoint and the on-premises web service endpoint accordingly.

Image
Figure 14:
Organization Connector to the Exchange Online organization

If there was pre-Exchange 2013 servers in the on-premises Exchange organization, an availability address space would also have been configured on these to point to the Exchange 2013 server(s), but this is out of scope for this scenario.

This concludes part 27 of this multi-part article in which I provide you with an explanation of what Windows Azure is and how you configure an Exchange 2013 hybrid lab environment in Windows Azure.

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

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top