Introduction to Exchange Online- Uncovering BPOS (Part 3)

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

 

 

 

Introduction

 

In part 2 of this article series, in which we take a deep dive into Exchange Online, we went through the steps required in order to sign up for a 30 day BPOS trial.

 

In part 3 we will set up e-mail coexistence so that users located in the Exchange Online environment can send e-mail messages to users in the on-premise environment over a TLS secured connection and vice versa.

 

Adding our SMTP Domain to Microsoft Online Services

 

Now that we have signed up for a trial, and since this article series focuses specifically on the Exchange Online service, our very first task is to add our SMTP domain to Microsoft Online Services (MSOL). This is done by clicking Add your domain to Microsoft Online Services under Tasks I Need To Do in the MSOL Administration Center (Figure 1).

 


Figure 1: Main page in the MSOL Administration Center

 

When a subscription to BPOS is activated, a domain in the form of domain1.microsoftonline.com is created for us at the same time. This domain allows us to configure e-mail coexistence between Exchange Online and our on-premise Exchange Messaging environment. Before replication Exchange users, groups and contacts to MSOL, we should add our on-premise SMTP domain (domain.com) as an external relay domain as shown in Figure 2.

 

Note:
You could, in theory, use the domain1.microsoftonline.com domain for sending and receiving messages, but in order for migrated users to send and receive messages using your on-premise SMTP domain you must add it to MSOL. Also, adding your on-premise SMTP domain to MSOL makes user logins easier, since users would use [email protected] instead of [email protected] as their username when accessing their mailbox via Office Outlook Web Access, Exchange ActiveSync (mobile devices) and Office Outlook.

 

When you have entered your SMTP domain, click Create (Figure 2).

 


Figure 2: Adding the on-premise SMTP Domain to MSOL

 

We will now be taken to a Confirmation page saying that the domain was created successfully (Figure 3). Click Finish to close the Confirmation page.

 


Figure 3: SMTP Domain successfully added to MSOL

 

The domain we just added is now listed under All Domains, but the status of the domain is Unverified, as shown in Figure 4.

 


Figure 4: All Domain List in the MSOL Administration Center

 

Since the domain must be verified before it can be used with MSOL, click Verify now. We are told that in order to verify our domain, we must create a CNAME record at the DNS provider hosting the domain (Figure 5).

 


Figure 5: CNAME Record that must be create at your DNS Provider

 

Depending on the DNS provider, you may or may not have web-based access to create DNS records yourself. If you do not have access to do, you must tell the DNS provider to create the CNAME record and the destination address for you.

 

Most DNS providers allow customers to create DNS records via a web-based interface, but the method required to do so is different from DNS provider to DNS provider. The domain used in this lab environment are hosted by a free Danish DNS provider called GratisDNS (FreeDNS), and here I need to login to a DNS control panel in order to create a CNAME record (Figure 6).

 

Note:
For guidance on how you create a CNAME record via some of the more commonly used DNS providers, check out this link.

 


Figure 6:  DNS Control Panel at DNS Provider

 

When the CNAME record has been created, it should look similar to the one shown in Figure 7.

 


Figure 7: CNAME Record created at my Danish DNS Provider

 

When the CNAME record has been created, wait 15 minutes then go back to the Verify Your Domain page and click Verify. If the verification check fails, please bear in mind that it can take up to 48 hours for the CNAME record to be visible throughout the Internet. When it has been verified successfully, you should see the page shown in Figure 8.

 


Figure 8: CNAME Record Confirmation page

 

Now that the verification check has completed with success, open the property page of the domain and check Default user account domain followed by clicking Save (Figure 9). This will make sure the domain is assigned as the default domain to new users that are being created. By default the default domain is domain1.microsoftonline.com.

 


Figure 9: Property page of the new SMTP Domain
Note:
As you may have observed there is also an Inbound Messaging tab on the property page of the domain. This is the place where you can switch inbound mail to the respective domain, currently pointing at the Internet-facing transport servers in the on-premise environment, to flow directly to MSOL. However, we do not want to do this before all users, groups and contacts and been fully migrated to MSOL and the on-premise messaging environment has been fully decommissioned. If you plan on using Exchange Online in combination with your on-premise messaging environment (this scenario is also known as hybrid mode), you should not change the inbound message flow.

 

With the SMTP domain configured and verified, we could now go create a new MSOL user via the User List subtab underneath the Users tab (Figure 10). In addition, we could create groups and contacts via the Exchange Online subtab under the Service Settings tab (Figure 11). But since we do not want to create new objects, but instead replicate Active Directory objects from our on-premise Exchange messaging environment, we do not want to do this.

 


Figure 10: User List subtab under the Users tab in the MSOL Administration Center

 


Figure 11: Exchange Online subtab under the Service Settings tab in the MSOL Administration Center

 

Enabling TLS between Exchange Online and our On-Premise environment

 

When establishing e-mail coexistence between your on-premise Exchange messaging environment and Microsoft Online Services, it is recommended to secure all e-mail messages in transit between the two environments as the messages are sent directly over the Internet. This can be accomplished by enabling TLS on the Internet-facing transport server(s) in your on-premise environment.

 

Exchange 2007 Transport servers (both Edge and Hub Transport servers) have a feature called opportunistic (determinstic) TLS enabled out of the box. This means that if the Internet-facing SMTP server(s) in your on-premise environment is based on Exchange 2007, it/they will always try to deliver outbound messages to remote SMTP servers over a TLS secured connection.

 

Have in mind though that if the remote SMTP server does not support TLS connections (does not offer STARTTLS verb to clients), Exchange 2007 will instead try to establish an unencrypted SMTP connection to the remote SMTP server. Since MSOL or more specifically Exchange Hosted Services, through which all e-mail messages are sent, offers the STARTTLS verb to all clients (no matter if they have a valid certificate or not) e-mail messages in transit from your Exchange 2007 based on-premise environment will be delivered over a secure connection (Figure 12).

 


Figure 12: Telnet connection on port 25 to mail.global.frontbridge.com
Note:
In order to use TLS, you must have a certificate installed and enabled on the Exchange 2007 Transport server. As some of you may know, the Exchange 2007 setup wizard installs a self-signed certificate during the installation of a Hub or Edge Transport server. This means that unlike previous versions of Exchange Server you do not need to worry about either installing and enabling a certificate nor enabling TLS.

 

The Internet header shown in Figure 13 below is from an e-mail message sent from my on-premise environment, which only consist of Exchange 2007 servers. The Internet-facing transport server is an Exchange 2007 Hub Transport server which uses DNS MX records to route mail automatically (no smart host involved).

 


Figure 13: Internet header from a message delivered to an Exchange Online user

 

As you can see in messages are sent over a TLS secured connection.

 

So what about e-mail messages sent the opposite way? Will I need to configure anything in order to have e-mail messages in transit from Exchange Online to the Exchange 2007 Internet-facing Transport server in the on-premise environment secured using TLS? Nope, not unless you have changed the out of box settings of the Default <servername> Receive Connector on your Internet-facing Edge or Hub Transport server as these server roles also have TLS enabled for inbound connections as can be seen in Figure 14 below.

 


Figure 14: Authentication tab of the Default <servername> Receive Connector

 

The Internet header in Figure 15 is from an e-mail message sent from an Exchange Online user to a user in my on-premise Exchange 2007 based environment.

 


Figure 15: Internet header from a message delivered to a user in my on-premise environment
If you plan on establishing coexistence between an Exchange 2000 or 2003 environment and Exchange Online, you must install and enable a certificate on the Internet-facing bridgehead server as well as create an SMTP connector dedicated to coexistence between these environments. This SMTP connector should point to mail.global.frontbridge.com which is the MX record for Exchange Hosted Services (EHS). In addition, you must add the SMTP domain created by Exchange Online (domain1.microsoftonline.com) under the address spaces tab of this SMTP connector. Finally, you must enable TLS Encryption under the Advanced tab of the connector. Since this article is written with special focus on migrating Exchange 2007 based on-premise environments to Exchange Online, the steps necessary in order to install and enable a certificate as well creating the SMTP connector is out of the scope of this article series. However more information on this subject can be found in this section in the BPOS documentation on TechNet.

 

Note:
If the Internet-facing transport servers in the on-premise perimeter network are based on UNIX MTAs such as PostFix and SendMail or if you use a dedicated spam/virus filtering box like Barracuda, IronPort etc. you must follow guidance from the provider on how to setup TLS in such a specific scenario.
When you have enabled e-mail coexistence, you should create a test user in the MSOL Administration Center, and then test mail flow between this user and an on-premise user. To create a user in the MSOL Administration Center, select the User List subtab under the Users tab, then click Add New User in the right pane as shown in Figure 16.

 


Figure 16: Clicking Add New User in the MSOL Administration Center

 

In the appearing property window, fill out the fields as required (Figure 17). For this specific test user, you should select the domain1.microsoftonline.com domain as the domain used to generate the e-mail address. This is required, since no AD contact object with a forwarding address to the domain1.microsoftonline.com domain exist for this new user in the on-premise environment.

 

Click Next.

 


Figure 17: Filling out the required property fields of a new MSOL user

 

In the next window, make sure you choose to enable the user account (Figure 18). Then click Next.

 


Figure 18: Security Settings page of a new MSOL User

 

Now select an appropriate Mailbox size limit (Figure 19). Since this is a test mailbox 256MB should be more than sufficient. Then click Create.

 


Figure 19: Selecting the Mailbox Limit size of the new MSOL User

 

Now you need to specify an e-mail address to which the details for the new users should be sent (Figure 20). When you have done so, click Send.

 


Figure 20: Confirmation page of new MSOL user

 

On the Confirmation page (Figure 21), click Finish.

 


Figure 21: E-mail message with MSOL user information sent successfully

 

Now open the Property page of the new user (Figure 22). Notice the default e-mail address is [email protected]. Click Cancel.

 


Figure 22: Property page of new MSOL user

 

It is time to test mail flow between the environments, let us start out by sending a mail from a user in the on-premise environment to the user created above. You can do so via OWA or Outlook 2007 or any favorite e-mail client you may have. When the message has been sent, open the mailbox of the test user we create above. We will do so using OWA. But before we do so we must change the password of the user. This can be done by clicking on the My Company Portal link in the e-mail message that was sent to the address you specified back in Figure 20. This will bring you a screen similar to the one in Figure 23 below. Enter the new and old password and then click Save.

 


Figure 23: Changing the password of the new MSOL user on first login

 

You are then taken to the screen in Figure 24. Since we do not want to use the Office Outlook client just yet, click Go Directly to My Company Portal.

 


Figure 24: Clicking Go directly to My Company Portal

 

Click the highlighted Start Microsoft Office Outlook Web Access (OWA) link in Figure 25.

 


Figure 25: Launching Outlook Web Access

 

This brings you to the familiar Outlook Web Access logon page (Figure 26). Enter your credentials and click Log On.

 


Figure 26: Outlook Web Access Logon Page

 

Select language and time zone and click OK (Figure 27).

 


Figure 27: Selecting Language and time zone

 

You should now see the test message you sent from your on-premise user (Figure 28). Now reply to the message.

 


Figure 28: Test message received in OWA

 

If the reply is received in the other end, everything works as expected. You can now relax until the next article. Until then have fun!

 

Summary

 

In this part 3 of this article series which takes a deep dive into Exchange Online, we went through the steps necessary in order to configure e-mail coexistence between our on-premise environment and Exchange Online. More specifically we added our SMTP domain to Exchange Online as well as talked about enabling TLS in our on-premise Exchange messaging environment. Finally, we created a MSOL user so that we could test message flow between the environments

 

In the next part, we will install the Directory Synchronization tool and replicate AD users, groups and contacts from our on-premise Active Directory to Exchange Online as disabled user accounts. We will also take a geeky, behind the scenes, look at the Directory Synchronization engine which is based on the Identity Lifecycle Manager (formerly known as MIIS).

 

 

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

 

 

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

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

Scroll to Top