Why Haven’t You Finished Your Microsoft 365 Migration Yet?
Microsoft 365 is not new. It’s been around for well over a decade, both in its current form as well...
The functionality in Exchange Hybrid is now quite mature. It’s been available since the launch of Office 365 (or even before if you include the embryotic support in Live@EDU) and provides the rich co-existence functionality that allows organizations to mix mailboxes on-premises and in the cloud, retaining much of the normal sharing capabilities people rely on for day-to-day collaboration.
For mailbox moves in any medium to large organization that doesn’t fancy a heavy hands-on approach, Hybrid is a no-brainer. However, even four years in, there are some gaps around collaboration available between the on-premises Exchange forest and the Exchange Online environment.
Within Exchange there are a number of ways people can provide access to shared information. When migrating to the cloud, this results in a number of scenarios to consider. Understanding them, and the impact of where people share, will help guide how you migrate people to Office 365.
One of the most common pain points with mailbox moves to the cloud is when people access shared mailboxes. Often this will include a team accessing a shared mailbox for client enquiries, or a PA accessing multiple VIP mailboxes to help manage their mail. In this scenario, the person is granted Full Access permissions to the shared mailbox by an IT administrator, along with Send-As permissions to be able to send out emails as the shared mailbox email address. They’ll find the mailbox displayed in Outlook alongside their own mailbox.
This has traditionally caused a challenge with migrations because it has not been possible for a user to open a mailbox on-premises once they have been migrated to the cloud. The shared mailbox has also had to be migrated.
A more self-service equivalent to the above is delegate access, usually configured by the person delegating mailbox access to someone else. This is configured in Outlook, and updates the local AD’s publicDelegates attribute along with updates to folder-level permissions. This allows someone else to send mail on behalf of the sharer and access specific folders in the mailbox rather than the entire mailbox itself.
This is challenging because the AD sync tools do not copy the publicDelegates attribute to (and from) Office 365, and permissions cannot be granted to the mail-user objects used to represent the objects in each corresponding side of the Hybrid deployment.
Shared Calendars are used across most organizations and often managed ad-hoc by individual users. There ares two core scenarios that people use – providing read-only access to another calendar and providing the ability for someone else to edit the calendar, for example when someone is managing a team’s schedule.
Editor rights to calendars in particular can be challenging when managing a Hybrid environment because it’s not currently possible to use Federated Sharing (the functionality in Exchange used to allow free/busy and calendar access) to provide editing rights to a calendar. Similar to Shared Mailboxes mailbox, moves must be planned accordingly to ensure that access for each group of users is retained during the migration.
Surprisingly, Public Folders have a good co-existence story for groups of users who access common resources. Public Folders hosted on Exchange 2007 through to 2016 can be accessed by users on-premises and in Office 365.
Whilst you coexist, Exchange Online is configured so it understands that Mailboxes will be hosted on-premises and to ensure clients understand where to find the Public Folders; you configure Exchange Online with the details of either the public Folder mailboxes (for Exchange 2013 or higher) or Public Folder “Proxy” mailboxes for Exchange 2010 or 2007.
In both circumstances, the Outlook client is provided with the SMTP address of the Public Folder/Proxy mailbox along with the standard Autodiscover response, and then will attempt to connect to the correct on-premises servers to access the existing Public Folder infrastructure.
Federated Sharing was introduced in Exchange 2010 for more than just Office 365 co-existence. Federated Sharing allows organizations with no formal AD trust or network connections to exchange availability information in real-time via an Organizational Relationship.
If you are currently making use of this functionality and plan on implementing a long-term Hybrid environment, then the ability for partner organizations to look up Free/Busy for your mailboxes that have been migrated to the cloud will be broken. Unfortunately, if the partner organization contacts your existing Exchange servers and requests availability for a cloud mailbox, Exchange will not proxy this request to Office 365 for a response. Only when you complete your migration and move services like Autodiscover to Office 365 will this functionality be available again.
The good news with all of the above is for short-term migrations that utilize Hybrid as the bridge to the cloud, none of these are permanent issues. Permissions on folders and mailboxes are synchronized to the cloud as you migrate, so if you do need to move people in such a way that sharing breaks temporarily, they will regain this access once the respective shared resources complete migration.
One area that is not automatically synchronized, though, is send-as permissions. So if people not only access shared mailboxes but also send as the mailbox, then this permission must be manually re-applied to the shared mailbox.
In Exchange 2013 Cumulative Update 10 and Exchange 2016, a new option for improving access to mailboxes cross-premises has been introduced. Right now it’s looking like it’s for testing only as very little documentation (apart from this article Overview of delegation in an Office 365 hybrid environment) has been released.
However, it does provide functionality enabling Outlook to open Shared Mailboxes on-prem for cloud-based mailbox and edit calendars cross-forest now and is fairly simple to configure.
In Exchange 2013 or 2016, a new parameter has been added to Set-OrganizationalConfig, named ACLableSyncedObjectEnabled. Set this to true to enable the ability to allow cloud-based mailboxes to be added to on-premises permissions lists:
After making this change, we’ll also need to (at present) update the msExchangeRecipientDisplayType for the user. You can do this using a script, or AD Users and Computers:
From a client perspective, this makes the sharing experience more fluid. You’ll find clients are now able to add mailboxes on-premises from a cloud mailbox – however, features like auto-mapping don’t take effect.
Client traffic in Outlook is routed to the correct Exchange Server, as shown below:
However – the caveat (as always) is at present this might not be ready for primetime.
Sharing between on-premises and cloud mailboxes is traditionally troublesome, and right now you need to plan migrations based on who shares with who. New developments look promising, though, and show that the experience for long-term Hybrid is set to improve.