Exchange Summit 2026: Cloud-First: Sigi's Session on "Moving Away from On-Premises – On the Way to the (Native) Cloud"

The Exchange Summit 2026 took place in Würzburg from February 24th to 25th, 2026. This is the conference for Microsoft Exchange in the DACH region (Germany, Austria, and Switzerland). The venue was the Maritim Hotel in Würzburg, and the two-day event was primarily aimed at Exchange administrators who wanted to learn about current developments in Exchange Server and Exchange Online. The more than 150 participants discussed not only technical aspects such as migrations (e.g., from older versions to Exchange Server Subscription Edition or to the cloud) but also organizational topics such as data retention, information protection, and compliance. The relevance of this conference was high, especially since Microsoft released the Exchange Server Subscription Edition (SE) in July 2025 and ended support (including security updates) for Exchange Server 2016/2019 in October 2025, which is forcing many organizations to move towards Exchange Online.

One of the most interesting sessions on the first day of the conference was the presentation “The ‘Last Exchange Server’ Problem: A Path from On-Premises to the (Native) Cloud,” given by our CEO and Microsoft MVP Siegfried Jagott. This technical presentation addressed a key concern for many companies: How do you get rid of the last on-premises Exchange server when all mailboxes are already in the cloud? Below, we summarize the most important content and insights from this session, from the challenges of hybrid Exchange environments to the latest solutions with Microsoft Entra ID (formerly Azure AD), the
Last Exchange Server feature (cloud-managed remote mailboxes), and the Source of Authority concept, which is based on transferring the source of authority to the cloud.

Challenges in hybrid Exchange environments (The "Last Exchange Server" problem)

Many organizations have already migrated their Exchange mailboxes to Exchange Online but still operate at least one on-premises Exchange server to handle remaining administrative tasks. In a classic hybrid environment, users, groups, and contacts continue to be managed from the on-premises Exchange server (or Active Directory) because the local directory (AD) serves as the source of authority. Services like the Exchange Admin Center (EAC) or Exchange PowerShell on the on-premises server are required to modify recipient objects, and SMTP relay functions often still run on the old server. These dependencies lead to the infamous "Last Exchange Server" problem: Even though the mailboxes are long gone in the cloud, a final on-premises Exchange server must remain operational solely for administrative purposes, which entails additional effort, costs, and technical risks.
Previous solutions and their pitfalls: Without additional innovations, administrators were previously left with only unsatisfactory options to solve this dilemma:

- All-or-nothing disabling of directory synchronization: Microsoft offered the option to initiate the transfer to cloud-only objects via Azure AD/Entra ID Connect Sync (e.g., formerly with Set-MsolDirSyncEnabled -EnableDirSync $false, now via Graph). However, this radical change simultaneously converted all objects in the organization to cloud objects and required setting new passwords for all users immediately. This is a disruptive and risky step that was practically impossible to implement, as it allowed neither a phased migration nor a selective approach.

- Manual Individual Migration per Object: Alternatively, some organizations have attempted to manually migrate individual objects from Active Directory (AD) to the cloud. In practice, this often meant backing up object attributes and permissions, deleting the user in the local AD, and then recreating them as a cloud user in Entra ID. The same applied to distribution groups or contacts (deleting and recreating them in the cloud). However, this method inevitably led to disruptions and data loss. For example, permissions were lost or emails were not delivered while a distribution group was being recreated. Furthermore, it involved a significant amount of manual effort, such as resetting passwords and restoring group memberships.

- Exchange Management Tools (2019): With Exchange Server 2019 CU12, Microsoft introduced the Exchange Management Tools, a minimal installation without mailbox functionality. Under certain strict conditions, this was intended to allow recipient management without a full-fledged Exchange server. One requirement was that all mailboxes were already in Exchange Online and that only PowerShell was used for management (EAC and RBAC were omitted). In practice, however, this approach proved impractical (question in the session: "Who actually used this?"). The conditions and limitations were too complex (no GUI, no audit logging, etc.), meaning many administrators still had to operate a dedicated Exchange server.

The consequence: Until around 2025, there was no elegant, low-risk way to phase out the last on-premises Exchange server without losing control over hybrid Exchange objects. This is precisely where two new features presented in the session come in: Cloud-Managed Remote Mailboxes, often referred to as the "Last Exchange Server (LES) Feature," and the Source of Authority (SOA) Switchover concept for cloud-first identity management. These approaches, which are tightly integrated with Entra ID (Azure AD), now enable a gradual transition to the native cloud without the previous obstacles.

Cloud-Managed Remote Mailboxes (Last Exchange Server Feature)

The session began by highlighting the Cloud-Managed Remote Mailbox feature, also known in community jargon as the "Last Exchange Server" feature. This feature allows synchronized mailboxes (i.e., user mailboxes synchronized from Active Directory to the cloud via Entra ID Connect) to be configured so that their Exchange-specific attributes can be edited in the cloud. Specifically, the IsExchangeCloudManaged switch is set to True for each mailbox. When this mode is active, Entra ID (Azure AD) Connect stops the synchronization of Exchange-relevant attributes from on-premises to Microsoft 365 for that mailbox. From then on, email addresses, aliases, mailbox settings, and other Exchange attributes can be changed directly in Exchange Online, for example, via the Exchange Admin Center in Microsoft 365 or via Exchange Online PowerShell.

Important: The mailbox object itself remains in the local Active Directory (identity management in Active Directory); only its Exchange properties are now managed in the cloud. In this way, Microsoft shifts some administrative responsibility to the cloud without requiring the entire identity to be immediately transferred to the cloud directory. For administrators, this means that many daily recipient management tasks can now be performed without a local Exchange Server. The notorious last Exchange Server becomes virtually obsolete once all mailboxes have been migrated.

Prerequisite: To use LES, you only need to have the latest version of Entra ID Connect installed, as older sync clients do not yet recognize the new IsExchangeCloudManaged flag. Otherwise, the usual hybrid prerequisites apply: a hybrid Exchange scenario with mailboxes fully migrated to Exchange Online (no more on-premises mailboxes) and a functioning directory sync (AD <-> Entra ID). The advantage of the LES approach is that no global administrator rights are required in the cloud. Any Exchange organization administrator can enable cloud management for the mailboxes in their environment.

Practical example: Switching a new employee to a cloud-managed mailbox could look like this:
First, a user is created in the local Active Directory (AD) as usual, synchronized via Entra ID Connect, and assigned an Exchange Online license (this creates the remote mailbox in the cloud). Then, the Exchange administrator sets to `$True for this mailbox in the Exchange Online PowerShell. After a short time, the mailbox's Exchange attributes become writable in the cloud, and the administrator can, for example, configure additional SMTP addresses or settings directly online. If a mailbox needs to be reverted to purely hybrid mode, the switch can be reset to $False at any time. However, any changes made in the cloud during this period should be documented beforehand. Deleting a mailbox works unchanged: Deleting the user account in AD also removes the associated cloud mailbox via synchronization.

Limitations of LES: Last Exchange Server Mode is currently only available for mailbox objects. Groups or contacts cannot (yet) be "opened" to cloud management in a similar way. Furthermore, LES only affects typical Exchange mailbox properties: Not all user attributes become editable in the cloud. Important core identity fields such as Display Name, Alias (mailNickname), and UserPrincipalName remain controlled by Active Directory.
If you change such attributes on-premises while LES is active, these changes will be ignored or overwritten by Exchange Online, since the cloud is considered the authoritative source for Exchange data in cloud-managed mailboxes. It is therefore recommended to ensure that such attributes are consistent before enabling LES, or to adjust the corresponding change processes. It is also important to understand that while LES makes the Exchange server obsolete, it does not eliminate Active Directory: The mailbox identity (user account) remains in the local AD, meaning a certain degree of hybrid infrastructure (domain controller, synchronization) persists.

Cloud-first strategy with Source of Authority (SOA)

The second focus of the session was the Source of Authority (SOA) feature, with which Microsoft takes a further step towards cloud-first identity management. SOA defines which directory is the leading instance for an object – in a hybrid context, this means the question: Is the source of authority for users, groups, and contacts in the local Active Directory or in EntraID (Azure AD)? Previously, in almost all hybrid environments, the on-premises AD was authoritative for all objects. Changes to users (e.g., passwords, names, or group memberships) therefore always had to be made on-premises and were copied to the cloud via synchronization. The cloud primarily served as a copy; direct editing in EntraID was disabled for synchronized objects (fields were grayed out, see the image in the presentation).

With the SOA feature, Microsoft reverses this principle when needed: Administrators can selectively move the SOA of individual objects to the cloud. This means that a user, group, or contact previously synchronized from Active Directory can be converted into a cloud-managed object. From that moment on, Entra ID becomes the primary directory for this object. Changes are made directly in the cloud, and synchronization from Active Directory is suspended for this object (or specific attributes of the object). Effectively, for example, a formerly hybrid user becomes a purely cloud-based user without requiring the re-creation of their existing account or mailbox. Entra ID now accepts edits (e.g., in the Microsoft 365 Admin Center or via the Graph API) to the object that were previously blocked.

The session made it clear: This will make Entra ID the primary source of identity. This is a major step towards a cloud-first approach, as local directories will become less important.

Advantages of SOA (Cloud-first): Moving object management to the cloud directory offers several advantages: Firstly, it simplifies administration, as all identities can be managed centrally in Entra ID, instead of having to manage two separate administration silos (AD and Entra ID). Secondly, it significantly reduces dependence on the local Active Directory. Companies already pursuing a cloud-first strategy can thus gradually adapt processes and reduce their on-premises infrastructure. Furthermore, new features and security mechanisms of Entra ID (such as conditional access, identity protection features, etc.) can be used immediately and directly, without having to wait for a sync from AD to provide this information. In short, the innovation cycles of the cloud can be fully exploited. Last but not least, opportunities arise to modernize processes – from onboarding and offboarding to access management and automation – since there is no longer a need to adhere to outdated AD workflows. In summary, SOA helps companies make Entra ID the “leading source of identity” and implement their cloud-first strategy.

Introduction and Prerequisites: The session explained that the SOA feature can be implemented object by object and incrementally. It's not a "big red button" that immediately switches all objects. Rather, administrators can selectively migrate individual groups or users to the cloud to gain experience, conduct pilot phases, and observe the impact.

Microsoft provides the necessary APIs and tools for this. Currently, the transition is technically accomplished via the Microsoft Graph API. For example, the ````onPremisesSyncBehavior``` attribute of a group can be set to CloudManaged via a Graph call. Similarly, there are Graph endpoints for users and contacts. This functionality requires prior, one-time administrator consent at the tenant level for specific rights (e.g., Group.OnPremisesSyncBehavior.ReadWrite.All), which typically must be granted by a global administrator. Subsequently, roles such as Hybrid Identity Administrator or Groups Administrator can configure group SOA; for user SOA, the corresponding role is User Administrator, and so on. Important: All Exchange mailboxes must already be in Exchange Online before switching user or group synchronization to the cloud. A classic Exchange hybrid configuration with active on-premises mailboxes is not supported. In practical terms, this means that SOA is particularly interesting after a mailbox migration is complete, in order to then transfer the remaining objects (user accounts without mailboxes, distribution lists, email contacts, etc.) into cloud management. Furthermore, SOA requires the latest versions of the Entra ID Connect or Entra Cloud Sync tools, as older versions do not support the new CloudMastered* attributes.

Limitations and Points to Consider: As promising as SOA is, it doesn't work without planning. Not all scenarios are currently supported. For example, users with federated logon domains (ADFS) cannot yet be migrated to cloud SOA. Complex hybrid setups with identity management systems like Microsoft Identity Manager (MIM) or special provisioning tools also need to be adapted beforehand – the existing processes for creating users and groups in AD no longer apply after an SOA migration and could cause errors. Furthermore, it should be noted that while a rollback to the old system is possible, it involves effort: You can restore the SOA of an object back to the local AD (e.g., via a graph patch isCloudManaged: false for the group), but then you have to wait for the next synchronization run and carefully check whether all attributes have been copied back correctly.
Microsoft therefore recommends performing SOA rollbacks only in emergencies, not as a regular part of back-and-forth strategies. Another key principle is: there is no "dual-write." Once an object is cloud-mastered, changes are made exclusively in the cloud. Adjustments made to this object in the local Active Directory have no effect in EntraID. This means, for example, that group memberships or user attributes should only be maintained in EntraID after an SOA migration.

Finally, it's crucial to understand that shutting down the last remnants of the hybrid Exchange environment (the infamous uninstallation of the last Exchange server) requires careful coordination. Especially if other systems (HR software, provisioning processes, device management, etc.) are still linked to the local Active Directory, comprehensive planning is essential. The session emphasized that existing customers must adapt their processes, such as MIM synchronization, HR provisioning, and any Exchange-specific automations, before migrating to the cloud.

Comparison: LES vs. SOA

The following table summarizes the differences and respective key aspects in a clear and concise manner:

Cloud‑Managed Remote Mailboxes (LES)	Source of Authority (SOA)
Focus: Exchange attributes of individual mailboxes are managed in the cloud; the identity remains in the local Active Directory, enabling a gradual decoupling from the local Exchange.	Focus: Management responsibility for objects is completely shifted to Entra ID; Entra ID is the sole authority for users, groups, and contacts as the target of a cloud-based identity architecture.
Prerequisites: Operation in a hybrid scenario with Exchange Online; all relevant mailboxes are migrated, local mailboxes no longer exist, and a current version of Entra ID Connect is required.	Prerequisites: Cloud-first environment with Exchange Online; the necessary administrator roles for setup and migration are in place, and current versions of Entra Connect or Cloud Sync are in use.
Supported Objects: User mailboxes, as well as shared and room mailboxes, are supported; groups and contacts are excluded from cloud management.	Supported Objects: Users, groups, and contacts are supported; synchronized identity objects can be fully cloud-managed.
Advantages: No local Exchange Server is required for mailbox management; recipient management is handled via the M365 cloud, and mailboxes can be migrated gradually with minimal risk.	Advantages: Centralized identity management directly in Entra ID; local AD dependencies are eliminated for migrated objects, and cloud features for security and compliance are immediately available.
Limitations: This approach is limited to Exchange attributes; identity data remains in Active Directory, groups and contacts remain hybrid managed, and an on-premises Active Directory is still required.	Limitations: The initial effort for rights and processes is higher; not all objects are suitable, and no on-premises Exchange mailboxes may exist after the migration.

The new “Last Exchange Server” solutions finally provide companies with practical ways to consistently migrate their Exchange and identity ecosystem to the cloud, gradually and in a controlled manner, without the known pitfalls.

The Cloud-Managed Remote Mailbox (LES) feature directly addresses the problem it's named after: It eliminates the need for the last on-premises Exchange server for mailbox management by allowing Exchange-related settings for hybrid-synchronized mailboxes to be changed in Exchange Online. Entra ID plays a central role in this, as it takes over, controlled via Entra ID Connect, some of the management logic that was previously reserved for on-premises Exchange.

With its Source of Authority (SOA) switch concept, Microsoft takes things a step further: Here, Entra ID itself becomes the leading authority for a company's users, groups, and contacts. The session made it clear that this cloud-first strategy makes it possible to completely eliminate the dependency on the local Active Directory and Exchange Server once all objects have been migrated.

Of course, processes and rights must be carefully adapted for this, but the benefit is considerable: simplified, unified management and use of state-of-the-art cloud functions, without legacy baggage.
The presented features are constantly being developed. For example, it is planned that, in the future, all synchronized mailboxes will be cloud-managed (LES) by default. This indicates that Microsoft has its sights firmly set on the end of the last Exchange server. Companies that adopt these innovations early on can future-proof their Exchange infrastructure and successfully manage the transition from on-premises to the native cloud.
The lively discussion at the Exchange Summit 2026 certainly showed how great the interest in these topics is and that for many, Hybrid Exchange now only represents a transitional solution on the way to a fully cloud-based email and identity platform.