Configuring an Exchange 2013 Hybrid Deployment and Migrating to Office 365 (Exchange Online) (Part 17)

By /

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

Introduction

In part 16 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we logged on to the mailbox using Outlook Web App (OWA), Outlook Anywhere and Exchange ActiveSync (EAS) in order to verify we saw the expected behavior for a mailbox that had been moved from on-premises Exchange to Exchange Online. Moreover, we verified that availability lookups between Exchange Online and Exchange on-premises mailboxes worked as expected.

In this part 17, we will continue where we left off back in part 16.

Let’s get started.

Exchange On-Premises Servers going forward

So depending on your specific scenario, your plan is probably to keep a portion of your mailboxes on-premises and the other portion in Exchange Online or simply moving all mailboxes to Exchange Online in order to get rid of your on-premises Exchange servers altogether so you don’t waste money on what you may see as unnecessary things such as support, management, server licenses, power, cooling and hardware maintenance contracts.

Okay so here’s the thing. As you know, we have configured DirSync and made the on-premises Active Directory the so called source of authority. That means that we in general must perform any required changes on the objects in the on-premises Active Directory and not in Office 365 nor Exchange Online as most attributes on this side are read only.

As you know, we have also configured identity federation via ADFS in order to achieve single sign-on (SSO) for users that are domain-joined and domain-connected. With identity federation configured, we must provision new users via the on-premises Active Directory in order for the users to be able to leverage SSO.

Since users must be provisioned via the on-premises Active Directory, we also need to be able to provision them with the required mail attributes in order for Exchange Online to accept the object and convert them as necessary. This part is pretty simple and can be done relatively simple without using Exchange Management tools such as exchange admin center (EAC) and the Exchange Management Shell (EMS). As a matter of fact, in order for Exchange Online to accept an object synchronized from the on-premises Active Directory, we only need the following three mail related attributes (in addition to the other mandatory attributes that are stamped on an Active Directory user object, when created using a tool such as the Active Directory Users and Computers console or an iDM solution):

  • mail
  • proxyAddresses
  • targetAddress

An object with the above three attributes will be converted into a valid mail-enabled user (MEU) object in Exchange Online when it gets synchronized to the Office 365 tenant. And you would be able to simply assign it an Exchange license in order to make it a mailbox-enabled object.

So far so good. The place where things get tricky is if you need to enable more advanced Exchange features on the object. Things such as hiding the object from the global address list, adding additional email addresses would be relative easy to enable by using ADSI Edit or an iDM solution with this logic built-in. However, for most organizations configuring these features via direct attribute manipulation could quickly end in a nightmare. For this reason, the Exchange Product Group doesn’t support this approach. Not that it cannot be done, but you really need brilliant operational procedures in place in order to succeed via this route. There’s the Exchange PG recommends you keep an Exchange 2013 server with the Mailbox role on-premises in order to manage Exchange related features going forward no matter if all your mailboxes are located in Exchange Online or not.

Note:
If the on-premises Exchange is only used for hybrid and management and doesn’t host any mailboxes, you should bear in mind you aren’t required to pay for the Exchange license only the Windows server license as it then would be covered by the Exchange Hybrid edition license. With Exchange 2013 you don’t have to enter a product key. For further details, see the Exchange Online licensing FAQ here.

If you plan to have all your mailboxes hosted in Exchange Online and if you run Exchange 2013, you have the option to remove the Exchange hybrid configuration. You can do so with the Remove-HybridConfiguration cmdlet. Bear in mind though, this will only remove the HybridConfiguration object in Active Directory not the other configuration that the hybrid configuration wizard created and configured in Exchange. In order to get rid of all Exchange hybrid related configuration, you must also remove organization relationships (Remove-OrganizationRelationship cmdlet), federation trust (Remove-FederationTrust cmdlet), receive connector (Remove-ReceiveConnector cmdlet), send connector (Remove-SendConnector cmdlet), remote domains (Remove-RemoteDomain cmdlet) and the mail routing proxy address from the E-Mail Address Policy (tenant_name.mail.onmicrosoft.com). Depending on your scenario (centralized secure mail transport or not), you can delete the inbound and outbound connectors in Exchange Online Protection (EOP).

Switching SMTP Relaying to the Cloud

There is a pretty good chance that you have on-premises line of business (LOB) applications, printers, scanners, faxes, network devices, monitoring solutions etc. that are depending on being able to relay through your on-premises Exchange servers.

If you plan to only keep an on-premises Exchange server for management purposes, it’s recommended to point the applications or devices to either relay through non-Exchange SMTP servers located on-premises or simply relay through the cloud.

One of the things that has really been improved from the previous version of Exchange Online to the current version is the relaying possibilities. We now have the following three ways of relaying through Office 365:

  • Direct Send: Configure a user, device, or line-of-business (LOB) application to directly send email to Office 365 (& Internet) recipients
  • Exchange Online Relay: Configure a user, device, or line-of-business (LOB) application to send mail as a single SMTP address for a domain you own
  • Exchange Online Protection Relay: Configure a user, device, or line-of-business (LOB) application to send mail as multiple senders who may not have Office 365 mailboxes, including to Internet recipients

In the following, you can see a comparison chart between the three methods:

Image
Table 1: Comparison of available relaying methods in Office 365

The above comparison chart is taken from the Ignite Webcast SMTP Relay, which is a great Webcast, I highly recommend you watch it to get a deep insight into each of these three relaying options. You can find it here.

Provisioning Mail Objects

Provisioning a new remote mailbox (mailbox created directly in Exchange Online) via your on-premises Exchange 2013 server(s) is a straightforward task. You simply open the exchange admin center and under the “Enterprise” tab point to “recipients” > “mailboxes”. On this page, click the “plus icon” and select Office 365 in the drop-down menu as shown in “Figure 1”.

Image
Figure 1: Creating a mailbox in Exchange Online using an Exchange 2013 on-premises servers

In the “new Office 365 mailbox” wizard, fill out the required text fields and then click “save”.

Image
Figure 2: Filling out mandatory text fields

After a little while the Active Directory user object will be created in the on-premises Active Directory.

Image
Figure 3: New Active Directory User object in on-premises Active Directory

Since the object has been stamped with the mandatory mail attributes it is also visible in the EAC with mailbox type “Office 365”. Really just a MEU object associated with Exchange Online.

Image
Figure 4: New MEU object visible in EAC

If we switch to the Office 365 in order to list mailboxes in Exchange Online, we can see the new user isn’t listed.

Image
Figure 5: New User Mailbox not listed in EAC connected to Exchange Online

The reason for this is simple. DirSync only synchronized newly provisioned users and deltas to the Office 365 tenant every three hours, so in order to have the mailbox show up, we need to wait or force a DirSync.

Image
Figure 6: Forcing a directory synchronization

We can see a new Add for the export connector, which means the newly provisioned object has been exported to Office 365.

Image
Figure 7: New add on export connector

If we click “Adds”, we are dealing with the respective object.

Image
Figure 8: Attribute information for exported object

Now if we refresh the mailbox list, the new mailbox user shows up.

Image
Figure 9: New user mailbox in Exchange Online

Shared Resources

For shared resources (shared mailboxes, equipment and rooms), we should follow the same principles as when we create user mailboxes. That is they should be created via the EAC (or EMS if you prefer) and then they will be synchronized to Exchange Online.

Image
Figure 10: Creating equipment and room mailboxes in EAC connected to an on-premises Exchange server

Image
Figure 11: Creating shared mailboxes in EAC connected to an on-premises Exchange server

Distribution Groups

For groups, you would usually also create them on-premises and have them synchronized to Office 365 although it is possible to create them directly in Exchange Online. Bear in mind though the latter will result in objects being in two places. At the same time, creating them on-premises means it won’t be possible to manage group membership using the Outlook client or OWA as the GAL is read only in scenarios where DirSync is in use.

Image
Figure 12: creating groups in EAC connected to an on-premises Exchange server

Sidebar: Managing Distribution Group created on-premises

Ok so you have setup coexistence between your on-premises Exchange based messaging infrastructure and Exchange Online using the Exchange hybrid configuration wizard. Since an Exchange hybrid deployment also requires directory synchronization from your on-premises Active Directory forest to the respective Office 365 tenant, you also configured DirSync between the two organizations.

Everything works as expected. You can move mailboxes to Exchange Online and off board them again. Users can also see the same global address list (GAL) and look up free/busy information for other users, no matter if they still have a mailbox on-premises or have had their mailbox moved to Exchange Online. In fact, everything is just super-duper. Well, at least it was because suddenly you are contacted by a user that recently had her mailbox moved to Exchange Online. The user is complaining about no longer being able to manage distribution groups in her Outlook client.

This user has managed distribution groups using her Outlook client for years without any issues, you’re told to fix the problem. So in order to see if this is a general issue, you add yourself as manager to the respective distribution group. This turns out to work just fine. Hmm this is just weird don’t you think. Only difference you can think of is your mailbox hasn’t been moved to Exchange Online yet. But why should moving a mailbox to Exchange Online break this functionality?

You decide to create a test mailbox in the on-premises Exchange environment. You then add the test user to the Manager list for the distribution group and just like with the case when testing with your own user mailbox, it worked just fine.

You move the test user mailbox to Exchange Online and connect to the mailbox using the Outlook client. And yes the test user mailbox now faces the same problem. It can’t manage the distribution group in question. You see the following error message after having removed a couple of users from the group and click “OK“.

Image
Figure 13: Not able to modify group membership using Outlook

Then you try to create a new group directly in Exchange Online using the Exchange Online Control Panel (ECP) and add yourself as manager. This works!

You scratch your head (again).

Okay, so after contacting the Office 365 Front-end Support team, it all suddenly makes sense. It is explained to you that since you use DirSync, the group object synchronized to Exchange Online is considered read-only. You can’t make any writes to it using the Outlook client or the ECP for that matter. In order for a cloud user to manage a distribution group, the following options are available:

  • Let the IT department manage the groups using well-known methods such as the EMC, EMS, ECP or Active Directory Users and Computer (ADUC) snap-in.
  • Use cloud managed distribution groups (group created directly in Exchange Online). The drawback of using this method is that any on-premises mailboxes cannot see this group in the GAL since DirSync is one-way synchronization only (except for a few attributes).
  • Push a locked down version of ADUC to the respective user’s machine. The drawback here is that you need to install admin tools on the respective client machines.
  • Publish ADUC or EMC through Citrix or Terminal services.
  • Create a shortcut on the respective client machines that point to “C:\Windows\System32\rundll32.exe” dsquery.dll,OpenQueryWindow”. This will make it possible to access the “Find Users, Contacts and Groups” tool that normally is launched via “Find” in ADUC (thanks to Kyle Anna at MS for this tip!).
  • Use Forefront Identity Manager 2010 (FIM 2010). FIM 2010 includes a distribution group module that the user can access through a browser. The module lets a user manage his own groups and join or leave others. This is the approach used for group management internally at Microsoft.
  • Use a third party tool to accomplish the goal. There are many different ones to choose between and most uses a browser based approach.

The above story (from real life) is one of many reasons why the solution alignment workshop, assessment and remediation phases of an Office 365 migration project is so important.

Well well well, this concludes part 17 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online). And you know what? This was the last article in this adventure. I hope you learned something along the way.

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

About The Author

Read Next

7 thoughts on “Configuring an Exchange 2013 Hybrid Deployment and Migrating to Office 365 (Exchange Online) (Part 17)”

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