Microsoft Support Request – Exchange Server Database Size Limit, DAG Replication Failure, and Exchange SE Upgrade Guidance

Open a Microsoft Exchange Server support case before changing licensing or reseeding, while treating Enterprise Edition on every DAG member expected to mount the oversized databases as the documented remediation for restoring full DAG failover functionality.

Supported conclusion for the current environment

• Exchange 2019 Standard Edition has a default 1,024-GB database limit. The Store can dismount a database at that limit, and DAG failover can fail.
• Database Size Limit in GB=4000 is only a workaround for mounting the database. It does not enable automatic DAG failover, and mounting may require Mount-Database -Force. Microsoft’s documented resolution for full DAG functionality is an Enterprise Edition license.^1^
• Therefore, upgrading Standard 2019 to Standard SE should not be treated as a confirmed repair for ExceededDatabaseMaxSize. The available SE edition documentation states that Standard permits five mounted databases and Enterprise permits 100, but it does not explicitly confirm that SE Standard supports automatic activation of databases larger than 1,024 GB.^2^
• Obtain binding confirmation from Microsoft Support and the licensing provider about the required SE Enterprise entitlement and product-key requirements. Public documentation cannot provide an environment-specific RCA or licensing determination.

Enterprise should be applied to both DAG members if either server must automatically mount or activate Management-Users or Normal-Users. Applying Enterprise removes the documented edition constraint, but it does not automatically repair a copy already in FailedAndSuspended.

Capture evidence before changing anything

Run this in Exchange Management Shell and attach the output to the support case:

Get-ExchangeServer |
  Format-List Name,Edition,AdminDisplayVersion

Get-MailboxDatabase -Status |
  Format-List Name,Mounted,DatabaseSize,EdbFilePath,LogFolderPath

Get-MailboxDatabaseCopyStatus "Management-Users\*" |
  Format-List Name,Status,ErrorMessage,ExtendedErrorInfo,
    CopyQueueLength,ReplayQueueLength,ContentIndexState

Test-ReplicationHealth -Identity IHC-EXCH-01
Test-ReplicationHealth -Identity IHC-EXCH-2

Also export the relevant events from:

• Applications and Services Logs → Microsoft → Exchange → HighAvailability
• MailboxDatabaseFailureItems
• The Application log around the first ExceededDatabaseMaxSize event

Include the per-database registry paths and values, free capacity on database/log volumes, recent CU/SU history, backup status, and whether IHC-EXCH-01 is the passive target. FailedAndSuspended means Exchange detected a failure requiring administrator intervention; the detailed status and events are needed before calling this a completed RCA.^3^

Safest recovery sequence

1. Back up the active database and registry, obtain an approved change window, and apply the confirmed Enterprise license to every server expected to activate these databases. Use Microsoft’s current Enter your Exchange Server product key procedure; Standard-to-Enterprise conversion is supported.^2^
   The exact current product-key command and restart requirement are not included in the available documentation excerpt, so confirm them in the support case rather than improvising in production.
2. Verify that the intended source is actually the mounted active copy:

Get-MailboxDatabaseCopyStatus "Management-Users\*" |
  Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,
    ContentIndexState -Auto

3. After licensing is validated, try the least disruptive repair first:

Resume-MailboxDatabaseCopy `
  -Identity "Management-Users\IHC-EXCH-01"

Get-MailboxDatabaseCopyStatus `
  -Identity "Management-Users\IHC-EXCH-01" |
  Format-List Status,ErrorMessage,ExtendedErrorInfo,
    CopyQueueLength,ReplayQueueLength,ContentIndexState

If the copy progresses to Healthy, monitor it and run Test-ReplicationHealth. If it returns to FailedAndSuspended, resuming again will not correct the underlying condition.^4^

4. Reseed only if status/events show missing logs, unrecoverable divergence or corruption, or Microsoft Support confirms it is required. Before reseeding:
   • Confirm the active source remains Mounted.
   • Confirm Remote Registry is running on the passive server.
   • Confirm the target database and log paths and sufficient capacity.
   • Allow for the database, logs, content index, seed activity, and growth—not merely the current 3.002-TB EDB.

Suspend-MailboxDatabaseCopy `
  -Identity "Management-Users\IHC-EXCH-01"

Update-MailboxDatabaseCopy `
  -Identity "Management-Users\IHC-EXCH-01" `
  -SourceServer "<verified-active-server>"

Get-MailboxDatabaseCopyStatus `
  -Identity "Management-Users\IHC-EXCH-01"

Seeding is the supported repair when a passive copy is unrecoverably diverged or has an unreplayable corrupted log. Large databases can take considerable time to seed; do not close the shell while it runs.^5^

Database design recommendation

Exchange supports approximately 16-TB databases, but for high availability Microsoft’s best practice is 2 TB or less, with storage provisioned for 120% of calculated maximum database size.^6^

Accordingly:

• Split Management-Users into smaller databases.
• Plan to reduce Normal-Users below 2 TB.
• Balance users and active copies across both DAG members.
• Treat 120% as planning guidance only; transaction logs, content indexes, reseeding, backups, and operational free space require additional capacity.
• Smaller databases reduce reseed duration and the period during which redundancy is degraded.^7^

Upgrade to Exchange SE

Exchange 2019 CU14 on Windows Server 2022 supports an in-place upgrade to Exchange SE.^8^ Do not use the upgrade itself as the repair for the failed copy.

Recommended order:

1. Resolve or formally accept the current redundancy risk.
2. Confirm SE edition entitlement with Microsoft/licensing.
3. Take tested Exchange and Active Directory backups.
4. Validate current SE prerequisites and readiness checks.
5. Upgrade one DAG member at a time using StartDagServerMaintenance.ps1.
6. Reboot, validate services, mail flow, copy health, and replication.
7. Run StopDagServerMaintenance.ps1, then repeat on the second member.
8. Keep DAG members on different versions only for the rolling-upgrade window.^9^

An in-place upgrade normally operates over the existing installation, but explicit preservation of these oversized databases is not established by the cited upgrade page. Treat retention as subject to successful backups, Setup readiness checks, storage validation, and Microsoft Support approval.

References

1. Exchange Server 2013, 2016 and 2019 Standard Edition can't mount databases that are larger than 1024 GB
2. Exchange Server editions and versions
3. Monitoring database availability groups
4. Resume-MailboxDatabaseCopy-Description
5. Update a mailbox database copy in Exchange Server
6. Exchange Server storage configuration options
7. Changes to high availability and site resilience over previous versions of Exchange Server
8. Upgrading to Exchange Server Subscription Edition (SE)
9. Manage database availability groups in Exchange Server