If you would like to read the prevoius part in this article series please go to:
In part 32 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 took a look behind the scene at what happens with a mailbox user when his mailbox is moved to Exchange Online. Furthermore, we looked at how you can bulk assign licenses to the users.
Let’s get going…
Managing Exchange Users Going Forward
Depending on your specific scenario, your plan could be to keep a portion of your mailboxes on-premises (for compliance reasons etc.) 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. The latter is of course what most organizations strive for in order to reduce costs by eliminating server licenses, power needed to run the servers, cooling, storage requirements 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 should 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 Exchange attributes in order for Exchange Online to accept the object and convert it as necessary. Although we can prepare the on-premises objects relatively simply by populating the required Exchange attributes without using Exchange Management tools such as exchange admin center (EAC) and the Exchange Management Shell (EMS), it is highly recommended to use Exchange Management tools for the job. This is the case even in larger organizations, where you may have an iDM solution that does the proper provision. Here, you would implement the required logic by using remote PowerShell to stamp the objects with the necessary attribute values.
The important thing is that any on-premises Active Directory user objects are shown as valid mail-enabled user (MEU) objects in Exchange Online when synchronized from the on-premises Active Directory to the Azure Active Directory and from here to Exchange Online.
Already existing mailbox-enabled users will automatically show up as mail-enabled users in Exchange Online.
So to summarize. Provisioning and modifying Active Directory user objects that have Exchange attributes populated should be managed using the native Exchange Management tools. Using an iDM solution, ADSI Edit or a third party tool to populate Exchange attributes is not recommended and also not supported by Microsoft unless the respective tool utilizes the Exchange Management tools.
For this reason, you should keep an Exchange 2013 server in your on-premises environment for management purposes even when all mailboxes have been migrated to Exchange Online. Well, at least for the time where you have synchronization happening from your on-premises Active Directory to Azure Active Directory, which most organizations will have.
Managing Distribution Groups Going Forward
Ok so you have set up 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".
Figure 1: 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! After contacting the Office 365 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 Microsoft Identity Manager 2015 (MIM 2015). MIM 2015 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 use a browser based approach.
So the above suggestions are for distribution groups that were synchronized from the on-premises Active Directory to Exchange Online. Another approach is to create new distribution groups in Exchange Online or even better use the new Universal/Modern groups that not only act as distribution groups but more specifically is a group that can be used for shared workspace for email, conversations, files, and calendar events where group members can conveniently collaborate and quickly get stuff done. Office 365 groups are being improved to also integrate with SharePoint, Yammer etc. An Office 365 group is provisioned in Azure Active Directory and until the release of AADConnect, it was not possible to manage membership of these groups in the on-premises environment. This changed with AADConnect. With AADConnect, write-back from Azure Active Directory to the on-premises Active Directory of membership of these groups is supported (requires Azure Active Directory Premium). The idea with this group type is it should replace legacy distribution groups and a lot of resources are spent improving this new group type.
Exchange On-Premises Servers going forward
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).
For details on how you remove the Exchange hybrid configuration in your scenario, see this TechNet page.
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 dependent 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:
Table 1: Comparison of available relaying methods in Office 365
This concludes part 33 as well as this multi-part article series 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. I hope you learned something along the way.
If you would like to read the prevoius part in this article series please go to: