Exchange Server Subscription Edition (SE) vs Exchange 2019: In-Place Upgrade Runbook

With the conclusion of standard servicing for legacy Exchange versions, Microsoft's on-premises messaging roadmap converges on Exchange Server Subscription Edition (Exchange SE).

For organizations running on-premises workloads or maintaining hybrid coexistence servers for recipient management, transitioning to Exchange SE is essential.

The standout feature of Exchange SE is support for direct in-place upgrades from Exchange Server 2019—a capability that avoids the traditional, resource-intensive "swing migration" to new hardware.

In this runbook, we break down key architectural differences between Exchange 2019 and Exchange SE, outline prerequisite requirements, and walk through an end-to-end upgrade workflow with production PowerShell scripts.

---

Architectural Comparison: Exchange 2019 vs. Exchange SE

Feature / Capability	Exchange Server 2019	Exchange Server Subscription Edition (SE)
Servicing Model	Fixed Lifecycle (CUs + Security Updates)	Subscription / Continuous Servicing Model
Licensing	Perpetual Server + CALs	Subscription Licenses (or Active Software Assurance)
Upgrade Pathway	Swing migration (new servers & move mailboxes)	Direct In-Place Upgrade (from Exchange 2019 CU14/CU15)
Underlying Codebase	Exchange 2019 CU14 / CU15 Baseline	Identical code baseline to Exchange 2019 CU15 (RTM)
Supported OS	Windows Server 2019 / 2022	Windows Server 2022 / 2025
Coexistence	Supports Exchange 2013, 2016, 2019	Supports Exchange 2016 (under ESU) and Exchange 2019

---

The Upgrade Pathways Explained

Your upgrade path to Exchange SE depends entirely on your existing version:

POWERSHELL

[Exchange 2016] ──> Requires Swing Migration (New Servers) ──> [Exchange SE]
                                   ▲
                                   │
[Exchange 2019 CU14/CU15] ──> In-Place Upgrade (Fastest) ───────┘

1. From Exchange 2019 (CU14 or CU15): You can perform a fast in-place upgrade. Because the RTM release of Exchange SE is code-equivalent to Exchange 2019 CU15, the installer functions like applying a standard Cumulative Update. Mailbox databases do not need to be evacuated to temporary hardware. 2. From Exchange 2016: Exchange 2016 cannot be upgraded in place. You must introduce Exchange 2019 or Exchange SE servers into the organization, establish coexistence, move mailboxes and cut over client access endpoints, and then decommission 2016.

---

Step 1: Pre-Upgrade Verification (PowerShell)

Before mounting the Exchange SE media, verify your existing build numbers, DAG health, and Active Directory readiness.

Run this audit script from the Exchange Management Shell:

POWERSHELL

# =======================================================
# Exchange SE Readiness & Prerequisite Verification
# Author: Sunil Chauhan (LAB 365 - https://www.lab365.in)
# =======================================================

Write-Host "--- Checking Exchange Server Builds in Organization ---" -ForegroundColor Cyan
$servers = Get-ExchangeServer | Sort-Object Name

$servers | Select-Object Name, AdminDisplayVersion, ServerRole, Edition | Format-Table -AutoSize

# Check minimum build requirement for in-place upgrade
$unsupportedServers = $servers | Where-Object {
    $_.AdminDisplayVersion.Major -eq 15 -and $_.AdminDisplayVersion.Minor -eq 2 -and $_.AdminDisplayVersion.Build -lt 1544
}

if ($unsupportedServers) {
    Write-Warning "The following servers are below Exchange 2019 CU14 and cannot undergo in-place upgrade directly:"
    $unsupportedServers | ForEach-Object { Write-Warning " - $($_.Name) ($($_.AdminDisplayVersion))" }
} else {
    Write-Host "[PASS] All Exchange 2019 servers meet minimum CU requirements." -ForegroundColor Green
}

# Verify Active Directory Functional Level
Write-Host "`n--- Checking Active Directory Functional Level ---" -ForegroundColor Cyan
$forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
$domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()

[PSCustomObject]@{
    ForestName         = $forest.Name
    ForestMode         = $forest.ForestMode
    DomainMode         = $domain.DomainMode
    SchemaMaster       = $forest.SchemaRoleOwner.Name
} | Format-List

Requirement: Active Directory Forest Functional Level must be at least Windows Server 2012 R2 or higher.

---

Step 2: Preparing Active Directory Schema & Domain

Because Exchange SE introduces updated schema definitions for hybrid modern auth and security baselines, execute AD preparation prior to touching production mailbox servers.

Run on a domain-joined machine in the same Active Directory site as the Schema Master:

POWERSHELL

# Mount the Exchange SE ISO image
$isoPath = "C:\ISO\ExchangeServerSE.iso"
$mount = Mount-DiskImage -ImagePath $isoPath -PassThru
$driveLetter = ($mount | Get-Volume).DriveLetter + ":"

Write-Host "Mounted Exchange SE on $driveLetter" -ForegroundColor Cyan

# 1. Prepare Schema
& "$driveLetter\Setup.exe" /PrepareSchema /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

# 2. Prepare Active Directory Organization
& "$driveLetter\Setup.exe" /PrepareAD /OrganizationName:"YourOrgName" /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

# 3. Prepare All Domains
& "$driveLetter\Setup.exe" /PrepareAllDomains /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

Dismount-DiskImage -ImagePath $isoPath

Verify replication across all domain controllers:

POWERSHELL

Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    $val = Get-ADObject -Identity "CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=yourdomain,DC=com" `
                        -Server $dc -Properties rangeUpper
    [PSCustomObject]@{ DomainController = $dc; RangeUpper = $val.rangeUpper }
} | Format-Table -AutoSize

---

Step 3: Server Maintenance Mode (DAG Environments)

If your target server belongs to a Database Availability Group (DAG), drain all active mailbox database copies and transport queues before running setup.

Run in the Exchange Management Shell:

POWERSHELL

$targetServer = $env:COMPUTERNAME

Write-Host "Placing $targetServer into Maintenance Mode..." -ForegroundColor Cyan

# 1. Drain HubTransport queues
Set-ServerComponentState -Identity $targetServer -Component HubTransport -State Draining -Requester Maintenance
Restart-Service MSExchangeTransport

# 2. Redirect active messages to another DAG member
Redirect-Message -Server $targetServer -Target "EX02.yourdomain.com" -Confirm:$false

# 3. Suspend DAG node cluster
Suspend-ClusterNode -Name $targetServer

# 4. Prevent database copies from activating on this node
Set-MailboxServer -Identity $targetServer -DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer -Identity $targetServer -DatabaseCopyAutoActivationPolicy Blocked

# 5. Place ServerWideOffline
Set-ServerComponentState -Identity $targetServer -Component ServerWideOffline -State Inactive -Requester Maintenance

Write-Host "[DONE] $targetServer is safely isolated in Maintenance Mode." -ForegroundColor Green

---

Step 4: Executing the In-Place Upgrade to Exchange SE

Once isolated, invoke the unattended setup from an elevated administrator prompt.

POWERSHELL

$isoPath = "C:\ISO\ExchangeServerSE.iso"
$mount = Mount-DiskImage -ImagePath $isoPath -PassThru
$driveLetter = ($mount | Get-Volume).DriveLetter + ":"

# Trigger the In-Place Upgrade
& "$driveLetter\Setup.exe" /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

Dismount-DiskImage -ImagePath $isoPath

Once installation finishes, restart the server to ensure all services and drivers initialize properly.

---

Step 5: Post-Upgrade Verification and Resuming Production

After the reboot, confirm that all Exchange services are healthy and release the node back into cluster production:

POWERSHELL

$targetServer = $env:COMPUTERNAME

Write-Host "Resuming $targetServer from Maintenance Mode..." -ForegroundColor Cyan

# 1. Set ServerWideOffline active
Set-ServerComponentState -Identity $targetServer -Component ServerWideOffline -State Active -Requester Maintenance

# 2. Resume Cluster Node
Resume-ClusterNode -Name $targetServer

# 3. Unblock Mailbox Database activations
Set-MailboxServer -Identity $targetServer -DatabaseCopyAutoActivationPolicy Unrestricted
Set-MailboxServer -Identity $targetServer -DatabaseCopyActivationDisabledAndMoveNow $false

# 4. Activate HubTransport
Set-ServerComponentState -Identity $targetServer -Component HubTransport -State Active -Requester Maintenance
Restart-Service MSExchangeTransport

# 5. Test replication and component states
Test-ServiceHealth -Server $targetServer
Get-ServerComponentState -Identity $targetServer | Format-Table Component, State -AutoSize

To rebalance database copies across your DAG nodes:

POWERSHELL

cd $exscripts
.\RedistributeActiveDatabases.ps1 -BalanceDGsByActivationPreference -ShowFinalDatabaseDistribution

---

Summary Runbook Checklist

1. [ ] Verify all servers run Exchange 2019 CU14 or CU15. 2. [ ] Audit Forest Functional Level (Windows Server 2012 R2+). 3. [ ] Run /PrepareSchema and /PrepareAD from the Schema Master site. 4. [ ] Put DAG node into Maintenance Mode and drain transport queues. 5. [ ] Execute Setup.exe /Mode:Upgrade from mounted Exchange SE media. 6. [ ] Reboot server and verify build version with Get-ExchangeServer. 7. [ ] Restore server component states and rebalance database copies with RedistributeActiveDatabases.ps1.

With this in-place upgrade approach, you eliminate the hardware procurement costs and data replication overhead of legacy migrations, moving your messaging infrastructure cleanly onto Microsoft's continuous servicing model.