Windows Server 2025 Next-Gen Active Directory: 32k Database Page Size Migration and Prerequisites

The 8k Architecture and Why It Hit an Enterprise Wall

When Windows 2000 Server introduced Active Directory Domain Services, it selected Microsoft’s Extensible Storage Engine (ESE)—internally codenamed JET Blue—as its transactional database engine. ESE writes directory partitions directly to disk inside NTDS.dit, organizing records into fixed-size database pages. In 1999, allocating 8,192 bytes (8 KB) per database page was an efficient compromise between physical memory consumption, spindle disk seek latency, and directory scale.

Think of the legacy 8k ESE database page like a standard courier delivery van with a rigid 8-foot cargo ceiling. In the early days of enterprise networking, parcels consisted of simple user accounts holding an employee name, a logon script path, and a telephone number. Everything packed neatly into a single van without spilling over. But over the last two decades, enterprise identity underwent a seismic transformation. Modern user accounts carry complex multi-valued security claims, multi-forest Kerberos service principal names, high-entropy cryptographic keys, and multiple 4,096-bit X.509 user certificates. When you attempt to load oversized modern cargo into that 8-foot van, the doors refuse to close.

To understand why this creates hard operational outages, systems architects must differentiate between linked and non-linked attributes in Active Directory:

• Linked Attributes: Attributes such as security group memberships (member and memberOf) or managerial reporting lines (manager and directReports) are maintained as paired forward and backward references. With the introduction of Linked Value Replication (LVR) in Windows Server 2003, Microsoft separated linked attributes into an independent database table (the link_table). Each group membership occupies its own distinct row, allowing groups to scale to millions of members without breaching record size limits.
• Non-Linked Attributes: Attributes stored directly within the main directory database table (the datatable) representing the object. Prominent examples include userCertificate, proxyAddresses, servicePrincipalName, otherHomePhone, and custom application attributes.

In the 8 KB ESE architecture, a single database record in the datatable has a maximum usable page size limit of approximately 8,110 bytes once page headers, transaction log metadata, and record structures are deducted. When non-linked multi-valued attributes exceed inline record limits, ESE spills data into auxiliary Long Value (LV) overflow trees referenced by 32-bit Long Value IDs (LIDs).

Because 32-bit LIDs on an 8k page impose rigid structural limits, a non-linked multi-valued attribute in Active Directory hits an unyielding wall at roughly 1,200 to 1,300 values. Once an object breaches this ceiling, the directory engine rejects further writes.

In enterprise environments running Microsoft Exchange, hybrid Entra ID Connect, or automated certificate autoenrollment, exceeding this limit results in immediate production replication failure. Domain controllers fail inbound directory updates with error 8304 (0x2070):

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Event ID:      1084
Task Category: Replication
Level:         Error
Description:
Internal event: Active Directory Domain Services could not update the following object with changes received from the following source directory service.
Object: CN=svc-app-sync,OU=Service Accounts,DC=corp,DC=example,DC=com
Object GUID: 3e8a71b2-9d41-4c12-8e2b-f41a87c95e10
Source directory service: 4a2d81c9-6b31-4e78-98e1-b85f31920ac3._msdcs.corp.example.com
Error value: 8304 The maximum size of an object has been exceeded.

The originating domain controller simultaneously logs companion Event ID 1093, indicating that directory replication for the entire partition partition naming context has ceased until an administrator manually purges values from the offending object. For massive enterprises, the 8k page format ceased to be an optimization and became an operational liability.

Inside the 32k Database Architecture

Windows Server 2025 modernizes the Active Directory storage core by introducing a native 32,768-byte (32 KB) database page format. By quadrupling the physical database page boundary, ESE dramatically expands directory density and structural throughput.

The transition to 32k pages is not merely a widening of byte arrays; it incorporates fundamental architectural enhancements within the JET database layer:

• 64-bit Long Value IDs (LIDs): Windows Server 2025 replaces legacy 32-bit Long Value IDs with 64-bit LIDs. This eliminates internal row-pointer exhaustion and allows multi-valued non-linked attributes to comfortably store roughly 3,200 values—representing an instantaneous 2.6x expansion in attribute capacity.
• Single-Record Page Residency: Complex user, group, and device objects that previously required extensive page overflow chaining now fit entirely within a single 32 KB database page. This eliminates multi-page disk seeks during LDAP search operations.
• NUMA-Aware Scaling: While legacy domain controllers were bound to a maximum of 64 logical processors due to non-uniform memory access (NUMA) node 0 thread affinity, the Windows Server 2025 directory engine spreads LDAP and ESE query execution across all physical NUMA groups on high-density silicon.

# Extensible Storage Engine (NTDS.dit) Database Page Layout Comparison
┌────────────────────────────────────────────────────────────────────────┐
│ Legacy 8 KB ESE Architecture (Windows 2000 through Server 2022)       │
│ ┌───────────────┬────────────────────────────────────────────────────┐ │
│ │ Page Hdr (84B)│ Record Table (Max Record Payload ~8,110 Bytes)      │ │
│ └───────────────┴────────────────────────────────────────────────────┘ │
│ Multi-Valued Non-Linked Limit: ~1,200 Values (32-bit Long Value IDs)   │
│ Single-Object Page Spillover: High fragmentation across LV B-trees     │
└────────────────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────────────────┐
│ Next-Gen 32 KB ESE Architecture (Windows Server 2025 Native)           │
│ ┌───────────────┬────────────────────────────────────────────────────┐ │
│ │ Page Hdr (84B)│ Record Table (Max Record Payload ~32,684 Bytes)     │ │
│ └───────────────┴────────────────────────────────────────────────────┘ │
│ Multi-Valued Non-Linked Limit: ~3,200 Values (64-bit Long Value IDs)   │
│ Single-Object Page Spillover: Vastly reduced; objects reside on-page   │
└────────────────────────────────────────────────────────────────────────┘

This expanded capacity directly benefits modern infrastructure workloads:

• Enterprise PKI and Smart Cards: Accounts holding multiple high-assurance smart card certificates, S/MIME encryption keys, and external partner certificates in userCertificate no longer risk triggering replication error 8304.
• Hybrid Exchange and Entra ID Connect: Service accounts and shared mailboxes accumulating tens of thousands of legacy alias strings and SIP routing identifiers inside proxyAddresses can scale safely.
• Windows Server 2025 Delegated Managed Service Accounts (dMSA): Server 2025 introduces dMSA, an evolution of gMSA that enables delegation of specific permissions to service identities without domain-wide administrator privileges. dMSA relies heavily on expanded security claims and cryptographic keys stored directly in non-linked attributes.

The In-Place Upgrade Trap: 8k Simulation Mode

The single most dangerous misconception surrounding Windows Server 2025 Active Directory is assuming that performing an in-place operating system upgrade on an existing domain controller automatically upgrades its database to 32k pages. It does not.

When you perform an in-place upgrade of a Windows Server 2019 or 2022 domain controller to Windows Server 2025, setup upgrades the operating system binaries, updates Windows services, and installs the modern management tools. However, the existing NTDS.dit database file on disk remains completely untouched. Upgrading an ESE database format from 8k to 32k requires rebuilding the physical B-tree tables from scratch—an intensive operation that cannot occur during an operating system upgrade.

Conversely, when you install a brand-new Windows Server 2025 instance and promote it as a replica domain controller using Install-ADDSDomainController, Active Directory creates a fresh NTDS.dit database file initialized with 32 KB page capabilities.

However, to allow this new domain controller to replicate inbound and outbound with legacy Windows Server 2019 and 2022 domain controllers across your enterprise, the Server 2025 directory engine operates in a special compatibility state: 8k Simulation Mode.

In 8k simulation mode, the domain controller formats its underlying database storage with 32k-capable tables, but strictly constrains record allocations and attribute limits to 8k boundaries over the wire. This ensures seamless replication convergence while preventing the new DC from originating records that older DCs cannot ingest.

To track database capabilities across all domain controllers, Windows Server 2025 introduces a dedicated operational attribute on the Directory System Agent (DSA) object: msDS-JetDBPageSize.

Located on each domain controller’s NTDS Settings object in the Configuration directory partition (CN=NTDS Settings,CN=<DCName>,CN=Servers,CN=<SiteName>,CN=Sites,CN=Configuration,DC=...), this attribute advertises database format readiness:

# The msDS-JetDBPageSize Schema Attribute Values
Value            Meaning                                Operational Status
───────────────  ─────────────────────────────────────  ──────────────────────────────────────────
32768            32 KB Database Page Capable            Clean promotion on Windows Server 2025.
8192             8 KB Legacy Page Bound                 In-place upgraded Windows Server 2025 DC.
<Not Present>    Legacy Operating System                Windows Server 2022, 2019, or 2016 DC.

If even a single domain controller in your forest advertises 8192 or lacks the attribute entirely, attempting to enable 32k pages forest-wide will fail immediately.

Required Ports, Protocols & Firewall Rules

Upgrading an Active Directory forest to Windows Server 2025 and coordinating forest-wide database feature transitions involves intense multi-master replication, Schema Master FSMO updates, and PowerShell administrative calls. Firewalls between management workstations, domain controllers, and cross-site boundaries must permit all necessary communication channels without packet inspection interference.

Always verify network reachability from your administrative management jump box to all domain controllers using the PowerShell Test-NetConnection cmdlet:

# Test Active Directory Web Services (ADWS) port connectivity on target DC
Test-NetConnection -ComputerName "DC01.corp.example.com" -Port 9389

# Test RPC Endpoint Mapper connectivity on target DC
Test-NetConnection -ComputerName "DC01.corp.example.com" -Port 135

Forest Prerequisites and Health Validation

Before you can even consider enabling the 32k database feature, your Active Directory forest must pass an exhaustive prerequisite chain. Skipping a single step will cause the optional feature activation cmdlet to abort with a fatal exception.

Prerequisite 1: Forest Schema Upgrade to Version 91
Windows Server 2025 introduces Active Directory Schema Version 91. This update adds core classes, new security attributes, and the msDS-JetDBPageSize attribute definition across three schema LDIF update files: sch89.ldf, sch90.ldf, and sch91.ldf.

To execute the schema extension, log on to the domain controller holding the Schema Master FSMO role using an account that is an explicit member of both the Schema Admins and Enterprise Admins universal security groups:

# Identify the current forest Schema Master FSMO role holder
(Get-ADForest).SchemaMaster

# Mount the Windows Server 2025 installation media and run forestprep from an elevated prompt
# Replace D:\ with your mounted ISO drive letter
D:\support\adprep\adprep.exe /forestprep

# Run domainprep on the Infrastructure Master FSMO holder of each domain
D:\support\adprep\adprep.exe /domainprep

Verify that the schema upgrade succeeded by checking the objectVersion attribute on the Schema Naming Context:

# Verify forest schema version reports 91
(Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion).objectVersion

Prerequisite 2: Deploy Fresh Windows Server 2025 DCs
Because in-place upgraded domain controllers remain permanently locked to 8k database pages, your migration plan must follow a clean side-by-side deployment model:

1. Deploy fresh, clean installations of Windows Server 2025 on enterprise server hardware or virtual machines.
2. Promote the new servers as domain controllers into your existing domains using Install-ADDSDomainController.
3. Transfer any FSMO roles hosted on older domain controllers to the new Server 2025 domain controllers using Move-ADDirectoryServerOperationMasterRole.
4. Gracefully demote all legacy domain controllers (Windows Server 2016, 2019, 2022) as well as any Server 2025 domain controllers that were produced via in-place operating system upgrades using Uninstall-ADDSDomainController.
5. Verify that stale metadata for demoted domain controllers is completely purged from Active Directory Sites and Services.

Prerequisite 3: Verify Replication Health Across All Sites
Never attempt a forest-wide functional upgrade when replication errors exist. Directory partition divergence during a functional level transition can cause partition inconsistencies that require forest recovery to rectify.

# 1. Execute a comprehensive replication summary check across all DCs
repadmin /replsummary

# 2. Check for any replication link failures across the forest
repadmin /showrepl * /csv | ConvertFrom-Csv | 
  Where-Object { [int]$_.'Number of Failures' -gt 0 } | 
  Select-Object 'Source DC', 'Naming Context', 'Destination DC', 'Number of Failures', 'Last Failure Status'

# 3. Perform a rigorous directory services diagnostic pass on all DCs
dcdiag /v /c /e /test:Replications

Step-by-Step: Enabling the Database 32k Pages Feature

Once all legacy domain controllers have been cleanly retired and replication health is pristine, proceed with the step-by-step activation sequence.

Step 1: Audit All Domain Controllers for 32k Page Capability
Execute the following PowerShell script to query every NTDS Settings object across all directory sites in the Configuration partition. Ensure that every single DC in the enterprise reports an msDS-JetDBPageSize of 32768:

# Query every Domain Controller in the forest for 32k database page readiness
$configNC = (Get-ADRootDSE).configurationNamingContext
$dcList = Get-ADObject -SearchBase $configNC `
  -Filter 'ObjectClass -eq "nTDSDSA"' `
  -Properties msDS-JetDBPageSize, whenCreated

$auditReport = foreach ($dc in $dcList) {
    # Extract the DC host name from the distinguished name hierarchy
    $dcName = ($dc.DistinguishedName -split ',')[1] -replace 'CN=', ''
    $siteName = ($dc.DistinguishedName -split ',')[3] -replace 'CN=', ''
    
    [PSCustomObject]@{
        DomainController = $dcName
        Site             = $siteName
        PageSizeBytes    = $dc.'msDS-JetDBPageSize'
        Status           = if ($dc.'msDS-JetDBPageSize' -eq 32768) { "32k Ready" } 
                           elseif ($dc.'msDS-JetDBPageSize' -eq 8192) { "BLOCKED (In-Place 8k)" } 
                           else { "BLOCKED (Legacy OS)" }
    }
}

# Display the validation report
$auditReport | Format-Table -AutoSize

Inspect the terminal output. If any server returns anything other than 32k Ready, stop immediately. You cannot proceed until that server is cleanly demoted and removed.

Step 2: Elevate Domain and Forest Functional Levels
Windows Server 2025 introduces the Windows2025Domain and Windows2025Forest functional levels. The 32k database feature requires the forest functional level to be at Windows Server 2025.

Elevate every domain in your forest first, followed by the forest root:

# Elevate Domain Functional Level across all domains in the forest
Set-ADDomainMode -Identity "corp.example.com" -DomainMode Windows2025Domain

# Elevate Forest Functional Level from the forest root domain
Set-ADForestMode -Identity "corp.example.com" -ForestMode Windows2025Forest

# Confirm the functional level upgrades succeeded
Get-ADDomain | Select-Object Name, DomainMode
Get-ADForest | Select-Object Name, ForestMode

Step 3: Inspect the Optional Feature Object
Active Directory models advanced optional capabilities (such as the Active Directory Recycle Bin and 32k Database Pages) as msDS-OptionalFeature directory objects stored within the Configuration naming context under CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,....

Inspect the feature object and verify its assigned GUID (52982ac6-1e73-754f-ae24-73ae2775aab8):

# Inspect the Database 32k pages optional feature definition
Get-ADOptionalFeature -Filter {Name -eq "Database 32k pages feature"} | 
  Select-Object Name, FeatureGUID, FeatureScope, IsSupported

If IsSupported returns True, your forest functional level and domain controller database layouts meet all architectural criteria.

Step 4: Enable the Forest-Wide Optional Feature
Execute the Enable-ADOptionalFeature cmdlet targeting your forest root domain. This call must be run by a member of the Enterprise Admins group:

# Enable the Database 32k pages feature forest-wide
$params = @{
    Identity = 'Database 32k pages feature'
    Scope    = 'ForestOrConfigurationSet'
    Target   = (Get-ADForest).RootDomain
}

Enable-ADOptionalFeature @params -Confirm:$true

PowerShell prompts for confirmation with an explicit warning stating that this operation is irreversible. Confirm the prompt to commit the change.

Step 5: Verify Feature Convergence and Event Logs
Once committed, the Schema Master writes the feature enablement to the Configuration partition and replicates the change to every domain controller in the enterprise.

As each Windows Server 2025 domain controller receives the update, its local directory engine transitions from 8k Simulation Mode into Native 32k Mode. Open Event Viewer on each domain controller and examine the Directory Service event log:

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Event ID:      2988
Task Category: Internal Processing
Level:         Information
Description:
Active Directory Domain Services has successfully transitioned the Extensible Storage Engine (NTDS.dit) database from 8k simulation mode to native 32k page mode. Database records and multi-valued attributes may now utilize full 32 KB allocations.

To confirm across all domain controllers using PowerShell:

# Verify the optional feature is listed under EnabledFeatures in the forest configuration
(Get-ADForest).EnabledFeatures | Where-Object { $_ -match "Database 32k pages feature" }

Operational Realities: Irreversibility, Backups & Memory

While enabling 32k database pages unlocks immense scalability, systems architects must account for three critical operational constraints before scheduling production deployment.

1. Absolute Irreversibility
There is no Disable-ADOptionalFeature cmdlet. Once the Database 32k pages feature is enabled, it is permanent. You cannot revert your forest to 8k simulation mode, and you can never again promote a Windows Server 2022, 2019, or 2016 server as a domain controller in that forest. If an unexpected application incompatibility arises with a legacy LDAP tool that cannot parse large attributes, you cannot simply roll back.

2. Complete Invalidation of Pre-Activation Backups
This is the most critical disaster recovery consideration: any System State or bare-metal backup taken prior to enabling the 32k database feature cannot be restored non-authoritatively into the forest.

Your operational procedure must mandate that immediately following feature activation, all existing pre-migration System State backups are archived into cold storage, and a fresh, authoritative System State backup is generated on every domain controller across the enterprise using wbadmin.exe or enterprise backup agents:

# Generate an immediate post-32k System State backup on each DC
wbadmin.exe start systemstatebackup -backupTarget:E: -quiet

3. ESE Buffer Cache and Memory Sizing
In the Extensible Storage Engine, database caching operates on page granularity. When a domain controller reads an object from disk into the ESE working set buffer pool in RAM, it reads an entire database page.

Moving from 8 KB pages to 32 KB pages quadruples the baseline page buffer size. In large enterprise environments with millions of directory objects, this can alter memory consumption characteristics. If your domain controllers were previously provisioned with barely enough physical RAM to cache the active working set, ESE buffer pool pressure may cause increased page churning to disk. Ensure that domain controllers hosting large databases are provisioned with sufficient physical RAM to accommodate the larger page buffer pool.

Active Directory Database Page Architecture Matrix

The following technical reference matrix summarizes the architectural, operational, and structural differences between legacy Active Directory and Windows Server 2025 Next-Gen Active Directory:

Troubleshooting 32k Migration Failures

If your feature validation or activation fails, consult this diagnostic matrix to isolate the root cause and execute the verified remediation procedure:

Final Thoughts

The introduction of 32 KB database pages in Windows Server 2025 represents the most significant architectural evolution of the Active Directory storage subsystem in more than two decades. By lifting the 8 KB barrier, Microsoft has eliminated the dreaded Error 8304 object size exhaustion trap and equipped enterprise directory environments to handle modern, high-density identity payloads.

However, the engineering discipline required to execute this transition safely cannot be overstated. Because enabling the 32k database feature is strictly irreversible, success depends entirely on executing the preliminary steps correctly: auditing every single domain controller against the in-place upgrade trap, verifying that all DSA objects advertise msDS-JetDBPageSize: 32768, elevating functional levels cleanly, and capturing fresh System State backups immediately post-activation.

To understand the foundational mechanics of directory storage and schema object definitions, explore our comprehensive guide on Active Directory Schema: Attributes, Classes, and Extending It Safely. For deeper insights into managing forest-wide single-master authorities during functional level upgrades, review our analysis on Active Directory FSMO Roles Part 1: Architecture and The 5 Roles Explained and Credential Guard and the Protected Users Group: Hardening Against Credential Theft.