If you would like to read the other parts of this article series please go to:
Introduction
In part 9 of this multi-part articles series revolving around Exchange hybrid deployment based migrations to Office 365 or more precisely Exchange Online, we imported and assigned a third party certificate to IIS and SMTP on the Exchange 2010 hybrid servers. Moreover, we configured the miscellaneous Exchange URLs on these servers to point to “hybrid.office365lab.dk”, which is the hybrid deployment coexistence FQDN I have chosen for this specific environment.
In this part 10, we will continue where we left off in part 9. That is we will take a look at the existing Exchange publishing rules in our TMG stand-alone array and then re-configure them, so that the on-premise Exchange infrastructure can coexist properly with Exchange Online. Moreover, we will add our Exchange Online organization to the Exchange Management Console (EMC) as an additional Exchange forest. Finally, we will connect to the Exchange Online organization using Windows PowerShell.
Let’s get going…
Re-Configure TMG and/or DNS Records
So at this point, we have configured the URLs on the Exchange 2010 hybrid servers and imported and assigned the required 3rd party trusted certificate on each of them. Next step is to re-configure the Exchange autodiscover and Exchange Web Services (EWS) publishing rule on the TMG 2010 stand-alone array or the DNS A-record, so it points to the Exchange 2010 hybrid servers instead of Exchange 2007. If TMG is used, depending on how the publishing rule is configured, you may also need to change the authentication method currently used for this rule.
Note:
If you do not use TMG to publish Exchange in your environment, you just need to update the autodiscover and EWS DNS records in external DNS to point to the public IP address that NATs to the virtual IP address (VIP) that load balance traffic across the Exchange 2010 hybrid servers.
So in my lab environment, the following Exchange 2007 services are currently published to the Internet using a TMG 2010 stand-alone array:
|
Exchange Service |
FQDN |
Description |
|
Autodiscover |
Autodiscover.office365lab.dk |
TMG publishes Exchange 2007 autodiscover using a standard Outlook Anywhere publishing rule. |
|
Outlook Web Access 2007 (OWA 2007) |
Webmail.office365lab.dk |
TMG publishes Exchange 2007 OWA using this FQDN. The TMG publishing rule uses forms-based pre-authentication meaning that users are authenticated on the TMG prior to getting access their mailbox. |
|
Exchange ActiveSync (EAS) |
Webmail.office365lab.dk |
TMG publishes Exchange 2007 ActiveSync using a standard EAS publishing rule. |
|
Outlook Anywhere (OA) |
Webmail.office365lab.dk |
TMG publishes Exchange 2007 autodiscover using a standard Outlook Anywhere publishing rule (same as the one used for autodiscover). Exchange Web Services (EWS) is also published using this rule. |
|
SMTP |
Smtp.office365lab.dk (MX record) |
TMG publishes Exchange 2007 Hub Transport servers using a SMTP access rule. |
Table 1: Exchange 2007 URLs prior to introducing Exchange hybrid
Here’s the “Paths” and “Listener” configuration for the Exchange 2007 – OWA, Exchange 2007 Autodiscover/Outlook Anywhere and Exchange 2007 ActiveSync publishing rules:
Figure 1: Exchange 2007 OWA paths and listener on TMG
Figure 2: Exchange 2007 Outlook Anywhere paths and listener on TMG
Figure 3: Exchange 2007 ActiveSync paths and listener on TMG
And here’s the inbound SMTP access rule:
Figure 4: Exchange 2007 Inbound SMTP access rule on TMG
In order to support a hybrid configuration, we need to adjust the existing rules a bit and create two new ones. When it comes to a hybrid deployment, features such as free/busy and mailbox move between on-premise Exchange and Exchange Online uses certain autodiscover and Exchange Web Services (EWS) endpoints. The respective features requires pass-through authentication on the TMG publishing rule in use. Since we have configured the Outlook Anywhere rule with pre-authentication, it cannot be used for free/busy and mailbox moves between Exchange Online and Exchange on-premise.
To work around this situation, we can create a brand new rule that publishes specific autodiscover and EWS endpoints and is set with higher priority than the existing publishing rule, which is used to publish autodiscover and EWS.
The following table lists the Exchange 2007/2010 services and associated FQDN with a brief explanation.
|
Exchange Service |
FQDN |
Description |
|
Autodiscover & Exchange Web Services (EWS) |
Autodiscover.office365lab.dk |
TMG publishes Exchange 2010 autodiscover using a standard Outlook Anywhere publishing rule. |
|
Outlook Web Access 2007 (OWA 2007) |
Webmail.office365lab.dk |
TMG publishes Exchange 2007 OWA using this FQDN. The TMG publishing uses forms-based pre-authentication meaning that users are authenticated on the TMG prior to getting access their mailbox. |
|
Outlook Web Access 2010 (OWA 2010) |
Hybrid.office365lab.dk |
TMG publishes Exchange 2010 OWA using this FQDN. The TMG publishing rule uses forms-based pre-authentication meaning that users are authenticated on the TMG prior to getting access their mailbox. |
|
Exchange Hybrid (AutoD & EWS) |
Autodiscover.office365lab.dk & webmail.office365lab.dk |
TMG publishes the specific autodiscover and EWS endpoints used for hybrid features such a free/busy & mailbox moves. |
|
Outlook Anywhere (OA) |
Webmail.office365lab.dk |
TMG publishes Exchange 2007 autodiscover using a standard Outlook Anywhere publishing rule (same as the one used for autodiscover). Exchange Web Services (EWS) is also published using this rule. |
|
Exchange ActiveSync (EAS) |
Webmail.office365lab.dk |
TMG publishes Exchange 2007 ActiveSync using a standard EAS publishing rule. |
|
Inbound SMTP |
Smtp.office365lab.dk (MX record) |
TMG publishes Exchange 2007 Hub Transport servers using a SMTP access rule. |
|
Inbound SMTP |
Hybrid.office365lab.dk |
TMG publishes Exchange 2010 Hub Transport servers using a SMTP access rule. This rule will be used for mail flow between Office 365 (FOPE) and onpremise. |
Table 2: Exchange 2007/2010 URLs set to support Exchange hybrid
After having re-configured existing TMG publishing rules and created two new ones, the list of publishing rules on the TMG should look similar to those shown in Figure 5 below.
Figure 5: Exchange 2007/2010 publishing rules on TMG after the re-configuration required by an Exchange hybrid
Configuring an SPF Record
In order to prevent spoofing and phishing many organizations use so called SPF (sender policy framework) records. An SPF is a text (TXT) record that we can create in our external DNS hosting our SMTP domain. In a nutshell an SPF record verifies the domain name from which e-mail messages are sent. This is done by validating the origin of the e-mail messages by verifying the IP address of the sender against the alleged owner of the sending domain.
When introducing an Exchange hybrid where we both have mailboxes in Exchange Online and in the on-premise Exchange based messaging environment, outbound e-mail messages usually route through the on-premises messaging environment prior to reaching the destination server. When this is the case, it’s recommended to add the IP address for your on-premises server to the TXT record. To do this, we can use the following TXT record:
v=spf1 ip4:192.168.6.220 ip4:192.168.6.221 include:outlook.com -all
Where 192.168.6.220 and 192.168.6.221 are the IP addresses configured for the outbound e-mail servers that should be considered authorized for the respective SMTP domain.
To begin configuring the SPF record for your domain, open the Office 365 portal and click > Domains, and then open the properties page for the respective SMTP domain. Under DNS management, you can find information and relevant links in order to create your specific SPF record.
Figure 6: SPF record required for integration with Exchange Online
When creating the SPF records, the SPF Sender Framework wizard from Microsoft is useful.
Add the Office 365 Tenant to the Exchange Management Console
Part of setting up a hybrid configuration between Exchange Online and the Exchange On-premise environment is to add the Exchange Online tenant as an additional Exchange forest in the Exchange Management Console (EMC) on the Exchange 2010 based hybrid servers. This will allow you to move mailboxes to Exchange Online as well as offboard mailboxes from Exchange Online using the EMC itself. In addition, we can configure certain settings for mailboxes stored in Exchange Online.
To add Exchange Online as an Exchange Forest in the EMC, right-click on “Microsoft Exchange” in the upper left corner, and then select “Add Exchange Forest” in the context menu as shown below.
Figure 7: Adding the Exchange Online organization as an additional Exchange forest in the EMC
In the “Add Exchange Forest” wizard, enter a friendly name for the Exchange forest (such as Exchange Online (Office 365) and then make sure “Exchange Online” (don’t tick “Logon with default credentials”) is selected then click “OK”.
Figure 8: Enter a friendly name and selecting “Exchange Online” as the URL
Now enter the credentials for the “Global Administrator” on Office 365. Also make sure to tick “Remember my credentials” (so you’re not prompted for these every time you launch the EMC) and then click “OK”.
Figure 9: Entering the credentials for an Office 365 Global Administrator
After a little while, you will see the Exchange Online tenant is added as an extra Exchange forest in the navigation pane (Figure 10).
Figure 10: The Exchange Online organization has now been added as an additional Exchange forest in the EMC
You can now expand the work center nodes under the Exchange Online tenant and check out the different configuration settings on each level. We will take a close look at this as we move on in this article series.
Connect to Exchange Online using Windows PowerShell
So while we can connect to Exchange Online using the EMC, the GUI of course has limitations to what you can do compared to when using Windows PowerShell.
So let’s also look at how you connect to Exchange Online using Windows PowerShell. First off, it’s recommended, you use Windows PowerShell and not the Exchange Management Shell (EMS) as you will otherwise need to use the “AllowClubber” parameter when importing the PS session. This will shadow the existing local cmdlets, but when doing so you will no longer be able to use those cmdlets against on-premise Exchange servers. At least not without prefixing the nouns of the imported commands.
Figure 11: Couldn’t create shadow commands for the on-premise nouns
So personally, I just have a PS session running against Exchange Online in a Windows PowerShell window and use the Exchange Management Shell against the on-premises Exchange servers in order to avoid having to create prefixes for the Exchange Online nouns.
Okay, so with the Windows PowerShell window opened, enter the following command in order to create a variable that stores the credentials of the Office 365 Global Administrator you wish to authenticate with:
$TenantCreds = Get-Credential
Figure 12: Entering credentials for an Office 365 Global Administrator
Then we need to connect to the Exchange Online service using the credentials stored in the variable. We can do this with the following command:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $TenantCreds -Authentication Basic –AllowRedirection
Figure 13: Connecting to the Exchange Online service using Windows PowerShell
Now that we have connected to the Exchange Online service, we have to import the session. We can do this using the Import-PSSession cmdlet:
Import-PSSession $Session
Figure 14: Importing the PowerShell session
We can now run cmdlets directly against Exchange Online in Office 365. For instance, we can retrieve statistics for all mailboxes that exist in our tenant:
Get-Mailbox | Get-MailboxStatistics | ft -a
Figure 15: Statistics for mailboxes in Exchange Online
Or maybe you want to retrieve a list of the accepted domains for your tenant:
Get-AcceptedDomain
Figure 16: Listing accepted domains in Exchange Online
When you’re finished administering Exchange Online, it’s a good habit to remove the PS session. You can do this with:
Remove-PSSession $Session
This concludes part 10 of this multi-part article in which I explain how you configure Exchange hybrid deployment followed by migrating to Office 365 (Exchange Online).
If you would like to read the other parts of this article series please go to:
