Two organizations each have Microsoft 365 tenants and they want to work together on several projects – some of which run for a limited time and some of which are ongoing. How can these organizations enable their people and teams to collaborate more effectively and productively across their different tenants? Add on top of this, how can this be done in a secure and compliant manner? This article describes several key collaboration options that administrators at each organization can consider as shared goals.
M365 - Exchange Online Center
ENow Software's Microsoft Exchange Online blog built by Microsoft MVPs for IT/Sys Admins.
The Confusing Case of Cross-Forest Delegation
If you've even participated in an Exchange Online migration at almost any level, it's likely you've run into the issue of cross-forest delegation. You know that Exchange allows you to delegate rights from one mailbox to another, allowing users to access other mailboxes. When you do an Exchange hybrid migration, there are some special considerations you have to take to keep these delegated rights working. Depending on who you ask, you'll get all kinds of different answers about what works when. In this blog post I will explain the confusing case of cross-forest delegation, and what you can expect to work or not work.
There is no cross-forest delegation
Much of the success of Office 365 is built on the Exchange hybrid migration. Since the initial release of Office 365 it has been possible to connect your on-premises Exchange organization to Exchange Online and have the two organization work almost like a single Exchange deployment. In the early days getting hybrid to work was a long and complicated process, but it was possible. The introduction of the hybrid configuration wizard has made the process of configuring hybrid Exchange much better.
The third and final part of the Tenant to Tenant Migration series is about post-migration processing. In case you missed the first two parts, here is an overview of the content:
Almost every enterprise today is going through some type of transformation from historic compute solutions (i.e., “running IT in our data center”) to hybrid environments where workloads are distributed to specific locations, platforms, or providers based on business requirements. Even organizations seeking to be “cloud only” or “completely hyperconverged” will still have many environment types within their landscape. “IT everywhere” includes all the places we’d like to shift away from, like traditional corporate data centers, but won’t be able to due to technical debt and legacy systems.
In Part 1 of this blog series, we went through the topics of how to discover identities, workloads, data, and security for your tenant to tenant migration project. Part 2 of this series covers the migration itself, like which workloads can be moved, what needs to be done to prepare for the migration, what data can be migrated, if there are any gotchas to expect, and public available PowerShell scripts that make your life a little bit easier.
What (Common) Workloads Can Be Moved
The most commonly used workloads might be Exchange Online, Teams, SharePoint Online, and OneDrive for Business. As in the Microsoft cosmos, the Exchange Mailbox should always be the first workload for migration because several other features rely on the mailbox itself. Also, email was the first workload that could have been migrated to Microsoft 365 and it is still the biggest one. Teams’ one-to-one chats are stored in the mailbox itself; documents and files will be stored in SharePoint Online. OneDrive for Business is a storage within the personal SharePoint Online site, so all of them work closely together.
Microsoft 365 is not new. It’s been around for well over a decade, both in its current form as well as in its previous/current incarnation as Office 365, and before that we knew it as BPOS / Microsoft Online Services.
I expect we all know there are limits to what you can and cannot do with your Exchange Online mailbox. We all know there is a limit to how many emails you can send and receive, how much storage you can use, how much data you can move into or out of Exchange Online, and how big each individual email can be. However, I find that few Exchange Online administrators know exactly what those limits are, how they work, why they are there, or what you can do about them.
Welcome to part two of Addressing the Office 365 Monitoring Gaps. In part 1, Michael Van Horenbeeck discussed the differences in monitoring cloud-based systems vs traditional on-premises deployments.