Exchange Server management: patching, monitoring, and the path forward

Exchange Server sits in a different position today than it did a year ago. Microsoft ended support for Exchange Server 2016 and 2019 on October 14, 2025, and the six-month Extended Security Update bridge that followed expired in April 2026. Organizations still running either version without moving to Exchange Server Subscription Edition (SE) are now operating on unsupported infrastructure, with no security updates available and no path to general support.

For MSPs and IT teams managing Exchange environments, that changes the operational picture significantly. The question is no longer how to keep patching Exchange 2016 or 2019 indefinitely. It is how to manage Exchange SE correctly while it is in production, and how to plan the transition to Microsoft 365 Exchange Online for the environments where on-premises Exchange no longer makes sense. Datto, part of the Kaseya family, has been helping MSPs protect Microsoft environments, on-premises and in the cloud, for over 15 years, and this guide draws on that operational depth to cover what each stage actually requires.

The Exchange Server landscape in 2026: what changed

Exchange Server 2016 and 2019 reached end of support on October 14, 2025. Microsoft offered a one-time six-month ESU program covering critical and important security patches only, with no general support, which ran through April 2026.

As of May 2026, any organization still running Exchange Server 2016 or 2019 without ESU enrollment is running unsupported, unpatched messaging infrastructure. Microsoft has also signaled that SMTP throttling for outdated on-premises Exchange configurations connecting to Exchange Online may be introduced, a step already applied to Exchange 2013 and earlier. The pressure to move is real and increasing.

Exchange Server Subscription Edition (SE) is Microsoft’s current supported on-premises Exchange product, with support confirmed through at least December 31, 2035. It requires active Software Assurance for updates and introduces a subscription model with more frequent update cycles than earlier versions. For organizations with genuine on-premises requirements, SE is the correct destination. For those without, Microsoft 365 Exchange Online is the strategic path.

Exchange Server SE: the new servicing model

Exchange Server SE changes how updates are delivered and applied. The quarterly Cumulative Update cadence remains, but SE introduces tighter integration with Windows Server and Entra ID authentication, along with Kerberos for server-to-server authentication replacing older auth mechanisms. CU1 for Exchange Server SE is planned for the first half of 2026.

The update sequencing rules that governed Exchange 2016 and 2019 still apply: Cumulative Updates must be in place before Security Updates, and some Security Updates require a specific CU level as a prerequisite. This is not a set-and-forget patching environment. Each update cycle requires checking compatibility, staging in a test environment before production deployment, and scheduling maintenance windows, because most Exchange Server updates require a service restart that interrupts mail flow.

For hybrid Exchange environments, where on-premises Exchange coexists with Exchange Online during migration or for permanent hybrid identity use, staying on the current CU is not optional. Microsoft has historically restricted or blocked hybrid connectivity from outdated Exchange builds, and SE environments in hybrid mode need to be current to maintain the integration.

Patch management for Exchange Server SE

Effective Exchange Server SE patch management runs in two parallel tracks.

The first track covers the underlying Windows Server platform: OS patches, security updates, and the maintenance tasks that apply to any Windows Server role. Datto RMM handles this layer through automated policy-based patch deployment, with compliance reporting that shows patch status across the environment and scheduled maintenance windows that keep deployments from landing during business hours. Off-network devices, including Exchange servers accessed through VPN or at remote sites, are covered through the Datto RMM agent without requiring network changes.

The second track is Exchange-specific and requires additional discipline. Exchange Cumulative Updates and Security Updates need:

1. Compatibility verification against the current Exchange SE build before deployment

2. A staging environment that mirrors production, with a test run before any production change

3. A documented maintenance window with the service restart scheduled at a low-impact time

4. Database consistency verification after major updates, checking that mailbox databases mounted cleanly and mail flow resumed correctly

5. Rollback procedure documented and tested before the forward change is attempted

IT Glue, Kaseya’s documentation platform, is where the standard operating procedure for Exchange patching lives. When documented there, the process is followed consistently regardless of which technician runs it. That consistency is what prevents the “we followed the same steps but got a different outcome” failure mode that happens when Exchange patching relies on institutional memory rather than a documented procedure.

A real-world scenario that illustrates the risk: an MSP managing 15 clients, three of whom run Exchange Server SE. Patch Tuesday arrives. The technician applies the security update on client one, following the usual Windows Server process, without checking the Exchange CU prerequisite. The update installs but introduces a transport service issue because the Exchange CU level was two versions behind. Diagnosing that takes four hours. With a documented and tested procedure that includes a CU-level check as step one, the issue never occurs.

Exchange Server monitoring: the critical checks

Exchange Server monitoring covers several distinct layers, and missing any one of them typically leads to an incident that could have been caught earlier.

Server health baselines. CPU, memory, and disk utilization on the Exchange server itself. Exchange is resource-intensive, and disk growth from transaction logs is a common source of issues that show up gradually rather than suddenly. Alert thresholds should be set to notify before utilization becomes critical, not when it already is.

Database availability and health. Mailbox databases should be mounted and replicating correctly in Database Availability Group (DAG) configurations. Database size growth trends matter here: a database growing unusually fast compared to its baseline often indicates a data retention policy issue or a runaway mailbox.

Mail queue depth. A sustained or growing mail queue is one of the clearest early indicators of a delivery problem. Short spikes are normal. A queue that grows over hours without resolution points to a transport service issue, a connectivity problem with the smart host, or a certificate failure causing TLS negotiation errors downstream.

Certificate expiry. This is the most common avoidable cause of Exchange disruption. Expired certificates break Outlook connectivity, OWA access, and mail flow that relies on TLS. Exchange uses multiple certificates, the default self-signed certificate, the assigned transport certificate, and any external SSL certificates for client connectivity, and each has its own expiry timeline. Automated certificate expiry monitoring in Datto RMM, with alerts at 60, 30, and 14 days before expiry, prevents this failure mode entirely. The fix is inexpensive and takes minutes. The incident, when it happens unmonitored, typically takes hours to diagnose because the symptom (clients can’t connect) doesn’t obviously point to a certificate as the cause.

Service status. The core Exchange services, Transport, Mailbox, and Client Access, should be monitored for unexpected stops. Automated restart procedures for known-safe service failures reduce the window between detection and resolution, but service failures that recur after restart need human investigation.

Event log patterns. Windows Event logs on Exchange servers carry early warning signals for database issues, authentication failures, and replication problems in DAG environments. Monitoring for specific Exchange event IDs, rather than trying to monitor all events, keeps alert noise manageable while catching the signals that matter.

Migration to Microsoft 365: planning the transition

For most organizations running Exchange Server on-premises, migration to Exchange Online is the strategic direction. Microsoft 365’s capabilities have reached parity with on-premises Exchange for the majority of use cases, and the operational overhead of running and patching Exchange Server on-premises rarely produces proportionate business value compared to a managed cloud service.

The migration planning components that typically drive timeline and complexity:

Directory synchronization. Azure Active Directory Connect (now Microsoft Entra Connect) handles identity sync between on-premises Active Directory and Entra ID. In hybrid deployments, this is usually already in place. For organizations starting from scratch, Entra Connect configuration is the first step that everything else depends on.

Mail coexistence. During migration, some mailboxes will be on-premises and some will be in Exchange Online simultaneously. Mail routing between the two needs to work cleanly, which requires the hybrid configuration and connectors to be set up correctly before mailboxes start moving.

Public folders. Organizations with legacy public folder structures face the most complex part of most Exchange migrations. Modern public folders, introduced in Exchange 2013, migrate more cleanly than legacy public folders, but either way this component needs its own inventory, planning, and testing cycle.

Decommissioning the on-premises footprint. Exchange Server cannot simply be uninstalled when migration is complete. The on-premises Exchange infrastructure needs to be properly decommissioned through a documented sequence that removes Exchange roles in the correct order, cleans up Active Directory attributes, and confirms that no remaining services or applications depend on the on-premises Exchange endpoints before they are taken down.

Licensing and compliance considerations. Organizations in regulated industries, particularly healthcare and financial services, may have data residency or retention requirements that affect Microsoft 365 configuration and add time to migration planning. These should be scoped before migration begins, not discovered during it.

Protecting Exchange Online after migration

A common assumption when migrating to Microsoft 365 is that Microsoft’s responsibility for the platform means the data is protected. It isn’t, not in the way organizations typically mean when they talk about backup.

Microsoft maintains service availability and infrastructure resilience, but it does not provide long-term backup of mailbox data with granular point-in-time recovery. If data is deleted, whether accidentally, maliciously, or through a ransomware event that targets cloud environments, the native Microsoft retention tools may not be sufficient to recover it, depending on retention policy configuration and the timing of the deletion.

Datto SaaS Protection covers Exchange Online alongside SharePoint, OneDrive, Teams, and the rest of the Microsoft 365 application suite. It provides three daily backups with point-in-time recovery, giving MSPs and IT teams the ability to restore individual emails, calendar items, or full mailboxes to any backed-up point, independently of Microsoft’s native retention controls.

The new unified recovery workflow, announced at Kaseya Connect 2026, extends this further by combining Microsoft 365 Exchange restoration and Entra ID object recovery into a single operational workflow, reducing the time to restore in identity-related incidents.

Explore Datto SaaS Protection for Microsoft 365.

The operational role of documentation and automation

Exchange Server management at scale, whether across multiple client environments for an MSP or across a complex internal IT estate, breaks down when it depends on individual technician knowledge rather than documented and automated processes.

Three areas where documentation directly prevents incidents:

The patch sequencing procedure. Documented in IT Glue with the CU prerequisite check as step one, the staging test as a required gate, and the maintenance window schedule as a confirmed field before deployment begins. When this procedure exists and is followed, the class of Exchange patching incident caused by skipping a prerequisite disappears.

The certificate inventory. Every Exchange certificate across every managed environment, with expiry dates, renewal sources, and the assigned service for each one, documented in IT Glue. Combined with automated expiry monitoring in Datto RMM, this eliminates certificate-related outages from the list of things that happen unexpectedly.

The migration decommissioning checklist. A step-by-step procedure for properly removing the on-premises Exchange footprint, documented and tested. Migration projects that are delivered cleanly and then followed by a proper decommission prevent the “we migrated but we still have an Exchange server running in the corner” situation that creates ongoing patching and monitoring obligations with no business justification.

Kaseya Intelligence, trained on more than 1 billion help desk tickets, 3 exabytes of backup data, and 17 million managed endpoints, adds an autonomous layer to these processes, moving from surfacing patch recommendations to executing and validating outcomes without manual intervention. For Exchange Server environments, that means unpatched vulnerabilities and missed backup verifications get caught and resolved before they become incidents. Explore Kaseya Intelligence.