Office 365 Hybrid Configuring Using Windows Azure – Part 5

We are almost done with the preparation of the environment to work in the hybrid mode. In this part, we will be performing the final configuration of enterprise on-premises Exchange servers and Office 365 to work in the hybrid mode.

Given below is a list of activities to be performed in this series:

I. On-premises hybrid configuration verification and tweaking

II. Office 365 hybrid configuration verification and tweaking

Other part of the Articles can be found at below link

Office 365 Hybrid Configuring Using Windows Azure – Part 1

Office 365 Hybrid Configuring Using Windows Azure – Part 2

Office 365 Hybrid Configuring Using Windows Azure – Part 3

Office 365 Hybrid Configuring Using Windows Azure – Part 4

Office 365 Hybrid Configuring Using Windows Azure – Part 6

On-premises hybrid configuration verification and tweaking

Hybrid configuration has made the necessary configuration changes in the on-premises exchange organization and Office 365. Let us verify some of these configurations and also make necessary changes to suit the requirement.

1. Login go krisexch.green.com with the organization admin credential and connect to the Exchange admin center.

2. Click on Mail flow -> Email address policies. Hybrid configuration wizard updates the email address policy with the secondary email address as alias@checkwhatsin.mail.onmicrosoft.com. Hence forth every mailbox object created will also get the secondary email address stamped with the domain checkwhatsin.mail.onmicrosoft.com

3. Click on mail flow -> accepted domains. We should see that the new entry checkwhatsin.mail.onmicrosoft.com has added an accepted domain and it is marked ‘Authoritative’.

4. Authoritative accepted domain is to allow exchange organization to accept emails and deliver them within the exchange organization. This is not the desired configuration at on-premises for the domain checkwhatsin.mail.onmicrosoft.com. Since it is the authority’s domain at Office 365, change the checkwhatsin.mail.onmicrosoft.com as internal relay.

Internal Relay: If the target mailbox resides locally, then it will be delivered. If the target mailbox is in a remote organization, then it will use a send connector to route email to the remote office 365 domain.

5. Let us verify the connector to send an email to Office 365. The hybrid configuration creates a new “Outbound to Office 365” connector to route emails to the remote Office 365 domain.

To verify the same, click on mail flow -> send connectors.

6. Hybrid configuration does not make any configuration changes or additions to the receive connector to accept email from Office 365. Default <Servername> receive connector  will be used to accept email on port 25 from Office 365

7. Organization sharing settings allow everyone in the organization to share free/busy and calendar information between the federated exchange organizations.

Office 365 hybrid configuration verification and tweaking

Hybrid configuration has made some necessary configuration changes in the Office 365 to work with exchange on-premises organization. It allows the mail flow, free/busy and other calendar information between the organizations.

Let us verify some of the configuration and make the necessary changes, if required.

1. Connect to the ‘Office 365 Exchange admin center’ and click on ‘mail flow’ -> ‘accepted domains’.

2. Hybrid configuration adds the new authoritative accepted domain as checkwhatsin.com

3. Authoritative accepted domain is to allow exchange organization to accept emails and deliver them within the exchange organization. This is not the desired configuration for the domain checkwhatsin.com. Since, its authoritative domain is at on-premises domain.

In the Part 4 of the article series, we have changed checkwhatsin.com MX record to point to Office 365. If checkwhatsin.com is marked ‘Authoritative’, then only will it deliver to the target mailbox in Office 365. If it is not able to find the target mailbox in office 365, then it will send an NDR message to the sender

This is not the desired configuration since, all the mailbox for checkwhatsin.com is residing on on-premises. Hence, it has to be set to ‘Internal relay’. If the target mailbox is not found in Office 365 then, it will be routed to the on-premises exchange organization, via an outbound connector

4. Hybrid configuration also creates Inbound and outbound connects at Office 365 to send /receive email from premises exchange servers.

The Inbound connector is to accept email from on-premises Exchange Send connectors for the recipients with the email address @checkwhatsin.mail.onmicrosoft.com

The Outbound connects is to send emails to on-premises exchange receive connector for the recipients with the email address @checkwhatsin.com

5. Office 365 Inbound connector can be tweaked to accept emails only from the specific on-premises exchange server and domain

The snapshot shown below has the details with sender domain set to checkwhatsin.com and sender IP address set to the IPaddress Exchange 2013 server. (It’s a Krisexch01.cloupdapp.net windows Azure IP address)

6. With this configuration , we should be able to send and receive emails between office 365 and on-premises exchange organization

Email flow from cloud on non-Premises

Mail flow from on-premises to cloud.

Thus, we have completely prepared and configured on-premises and Office 365 to work on a hybrid mode.

In the next and final part of the article service, we shall be trying to understand how to make provision for a mailbox in the hybrid mode, and in that series, how to migrate the mailbox from on-premises to Office 365

Other part of the Articles can be found at below link

Office 365 Hybrid Configuring Using Windows Azure – Part 1

Office 365 Hybrid Configuring Using Windows Azure – Part 2

Office 365 Hybrid Configuring Using Windows Azure – Part 3

Office 365 Hybrid Configuring Using Windows Azure – Part 4

Office 365 Hybrid Configuring Using Windows Azure – Part 6

Exchange 2013 CAS Configuration In-detail

Exchange 2013 has brought major architecture changes and now there are just two roles – Client Access Server (CAS) role and Mailbox Server role, whereas the previous version of Exchange had five server roles.

Mailbox Server role: It includes traditional features like Mailbox Database, transaction logs, but now it also hosts Client Access protocol, Transport service and Unified messaging server.

Client Access Server role: It is an office client access protocol like HTTP, POP and IMAP and SMTP. Outlook no longer uses RPC to connect to the Client Access Server, it uses RPC over HTTPS (also known as Outlook Anywhere) and Outlook client doesn’t connect using fully qualified domain name (FQDN) or CAS Array as it was done in all previous versions of Exchange. It uses user’s mailbox GUID + @ + the domain portion of the user’s primary SMTP address to connect to the mailbox. This is a huge benefit to overcome limitations and complexity of Exchange 2010 RPC Client Access service on the Client Access Server.

To read about more on this topic, please use the below link at blog.netwrix.com

Exchange 2013 CAS Configuration – PART 1

Exchange 2013 CAS Configuration – PART 2