Finalizing the Active Directory Migration – Raising Functional Levels to 2025

In this concluding part of our zero-downtime Active Directory migration series, we will raise the Domain and Forest Functional Levels to Windows Server 2025. After migrating from Windows Server 2016 domain controllers (DCs) to new 2025 DCs in previous steps, this final phase unlocks the latest Active Directory features. We’ll cover why functional levels matter, what’s new in 2025, prerequisites, the step-by-step process (via GUI and PowerShell), post-upgrade tasks (like enabling the 32KB database page feature), best practices for validation and monitoring, and some real-world insights on reliability and long-term support.

Why Raise Active Directory Functional Levels?

Active Directory Functional Levels determine the advanced features available in your domain or forest. When all your DCs run a newer Windows Server version, you can raise the functional level to enable those new capabilities. Moving to Windows Server 2025 functional levels will allow us to take advantage of improvements that aren’t accessible at the 2016 level. In summary, raising the domain and forest functional levels will:

• Unlock New Features: Some Active Directory features (especially those introduced in 2025) only light up when the functional level is elevated. This ensures all DCs can support the feature.
• Improve Security and Performance: Higher functional levels enforce modern protocols and optimizations. They phase out legacy compatibility, which can reduce potential security risks.
• Finalize the Migration: This is the capstone to decommissioning older DCs. Once raised, you confirm that your AD environment is fully running on the new version and that you do not intend to add older servers.

Remember that raising functional levels is one-way and irreversible (short of a complete AD restore). It’s a planned milestone that solidifies your upgrade, so we only do it when we’re confident all prerequisites are met.

New Active Directory Features in Windows Server 2025

Windows Server 2025 introduces several Active Directory Domain Services enhancements. We ensure our environment can use these new features by raising the functional levels. Some highlights include:

• 32KB Active Directory Database Pages: Traditionally, the AD database uses 8KB pages, which limits specific object sizes and attributes. Windows Server 2025 supports an optional 32KB page database format. With 32KB pages, AD can store much larger single objects and far more values in multi-valued attributes (up to ~3,200 versus ~1,200 in 8KB mode). This improves scalability for organizations with huge groups or complex user attributes. (We’ll discuss enabling this feature after raising the functional level since it requires the forest to be at the 2025 level.)
• Replication Improvements: Active Directory replication can be fine-tuned in 2025. A new replication priority feature allows administrators to prioritize specific replication traffic between DCs. You can ensure critical directory changes propagate faster in large or distributed environments by boosting their priority. This feature becomes manageable once all DCs are on 2025 and the functional level is raised.
• Security Enhancements: With all domain controllers in 2025, you will benefit from stronger default security in authentication protocols. For example, Windows Server 2025 DCs support newer encryption standards (like AES-256 for certain Kerberos operations and improved LDAP channel binding and signing by default). Some of these improvements are intrinsic to the DCs themselves, but having the whole forest at the newest level means you can confidently enforce modern security settings without worrying about down-level DC compatibility.
• Performance and Scalability: Windows Server 2025 removed some previous limits. Active Directory can utilize multiple CPU groups (improved NUMA support), beyond the old limit of 64 CPU cores per DC. This change doesn’t require a functional level toggle, but it means a 2025 DC on powerful hardware will handle loads better. By completing the migration and raising levels, you certify that your AD can fully leverage such enhancements.
• Schema Updates and Object Management: The AD schema was extended for 2025 (new schema object versions and files were introduced when we added the first 2025 DC). Additionally, 2025 introduced an object repair function where Enterprise Admins can fix particular corrupted AD objects (e.g. restore missing SamAccountType on an object or reset a user’s LastLogonTimestamp). These capabilities come with the new AD version; raising the functional level ensures all domain controllers can consistently perform them if needed.

Moving to the Windows Server 2025 functional level positions your Active Directory for the latest functionality, better performance, and the highest security baseline available in on-prem AD DS. Next, we’ll verify that we meet the requirements to raise the levels safely.

Prerequisites Before Raising Functional Levels

Before we proceed, double-check that the following prerequisites are satisfied. Skipping these could prevent a successful raise or even cause AD issues:

• All Domain Controllers on Windows Server 2025: Every DC in the domain (and forest) must be running Windows Server 2025. You cannot raise the functional level if any DC is on an older OS. We have already introduced new 2025 DCs in our migration and demoted or decommissioned all 2016 DCs. Now is a good time to verify that there are no stragglers:
  • Using Active Directory Users and Computers: Go to the Domain Controllers OU and ensure all entries correspond to the new servers (and their Operating System attribute shows 2025).
  • Using PowerShell: Run a quick command to list all DCs and their OS version:

Get-ADDomainController -Filter * |

Select-Object Name, OperatingSystem, IPv4Address

#The output should show only Windows Server 2025 as the operating system. If an older OS appears, that DC must be upgraded or removed before proceeding.

• Current Functional Level is High Enough: The existing forest/domain functional level should already be at Windows Server 2016 (since our source DCs were 2016). Windows Server 2025 domain controllers require the domain to be at least 2016-level before they can be introduced. If your functional level is still lower (e.g., you had 2016 DCs but never raised the level from 2012R2), you must raise it to 2016 first. Use the AD Domains and Trusts console or PowerShell (Get-ADForest and Get-ADDomain) to confirm the current levels:
  • In Active Directory Domains and Trusts, Right-click the domain and choose Properties. The dialog will display the “Domain functional level” and “Forest functional level.” They should currently say Windows Server 2016 (or possibly 2019/2022, which internally still means 2016-level features).
  • Alternatively, use PowerShell:

Get-ADForest | Select-Object ForestMode, Domains

Get-ADDomain | Select-Object DomainMode

#This will list the forest functional and domain modes for your domain. Verify that they show Windows2016Forest / Windows2016Domain. If not, adjust accordingly before attempting 2025.

• Healthy AD DS Replication: The Active Directory should be healthy (no lingering replication errors or schema mismatches). Raising functional levels updates critical configuration data across the entire forest, so we want replication working flawlessly. Ensure that:
  • All DCs can replicate with their partners (use repadmin /replsummary or PowerShell AD replication cmdlets to check for errors or backlog).
  • There are no recent errors in the Directory Service event logs on the DCs (specifically, look for NTDS Replication errors).
  • If you have multiple domains, ensure each domain’s DCs are healthy and replicating.
• Recent Backups of AD: Although raising functional levels is generally safe, having a current backup is the best practice. Ideally, at least one system state backup from a 2025 DC should be taken before this change. This would allow a forest recovery if something very unforeseen happened. Also, verify that your backup solution is aware of the new AD schema (especially if you plan to enable the 32K page feature; confirm your backup software supports it by testing in a lab or reviewing documentation).
• Enterprise Admin Credentials: To raise the forest functional level, you must be a member of the Enterprise Admins group. To raise a domain functional level, you need Domain Admin (Enterprise Admin also suffices if in the root domain). Ensure you’re logged in with an account with these rights or have the credentials ready.
• FSMO Roles on 2025 DCs: By now, all FSMO roles (Flexible Single Master Operations) should have been transferred to the new DCs (we covered this in an earlier part). Just double-check that the Schema Master, Domain Naming Master, PDC Emulator, RID Master, and Infrastructure Master roles all reside on Windows 2025 servers. You can verify with:

Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster

Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

If any role still shows an old server name, transfer it to a 2025 DC before raising functional levels. (The functional level raise operation will implicitly target the Schema Master and other FSMOs, so they must be on compatible servers.)

• No Pending AD DS Changes: Ensure that no other AD DS changes (like adding another DC or performing an AD schema upgrade) are in progress. It’s wise to execute functional level changes during a maintenance window where you can focus on this single change and when the AD is quiet (to observe any anomalies easily).

Finally, inform any stakeholders of this planned change. Although end-users typically will not notice a functional level raise, it is a significant configuration change. If any legacy applications or systems interact with AD in unusual ways (especially older LDAP clients or domain trusts with old domains), let teams know and plan to verify those systems after the update.

Step-by-Step: Raising Domain and Forest Functional Levels to 2025

With the prerequisites met, let’s walk through raising the functional levels. We’ll first describe the graphical method using Active Directory Domains and Trusts, followed by the PowerShell method. You can use whichever you prefer – the result is the same. (If you have multiple domains in your forest, you would raise each domain’s level, then the forest level. In a single-domain forest, raising the forest will also automatically lift the domain to that level.)

Using the Active Directory Domains and Trusts Console (GUI)

1. Open Active Directory Domains and Trusts: Log on to a server or workstation with the installed AD administrative tools (RSAT). Launch the Active Directory Domains and Trusts console (you can find it via the Start menu search or in Administrative Tools).
2. Check Current Levels (Optional): In the left tree, right-click your domain name and choose Properties. As noted earlier, verify the current functional levels. Click OK to close the Properties dialog.
3. Raise the Domain Functional Level: Right-click the domain name in the left tree again, and select Raise Domain Functional Level…. A dialog will appear with a drop-down to select the new functional level. Choose Windows Server 2025 from the list.
   • Click Raise. You will be asked to confirm (and warned that this action is irreversible). Confirm to proceed. If all DCs are indeed on 2025, the operation should complete quickly with a success message.
4. Raise the Forest Functional Level: Now, in the Active Directory Domains and Trusts console, right-click the top-level Active Directory Domains and Trusts node (the root of the console tree) and select Raise Forest Functional Level…. Similar to before, select Windows Server 2025 and then click Raise. Confirm the action when prompted.
   • If your forest had multiple domains, ensure each domain was already at 2025 (the tool might have enforced that). In a single-domain forest, raising the forest will implicitly update the domain as well if it hasn’t been done already.
5. Refresh and Verify: After both actions, you can refresh the console (or close and reopen the Properties) to ensure the domain and forest functional levels show Windows Server 2025. Congratulations – your AD now operates at the highest functional level!

Note: If any option is grayed out or missing (for example, you don’t see Windows Server 2025 as an available level), recheck that all your DCs are indeed running 2025 and that your account has the proper permissions. The GUI will only offer levels that are supported given the current state.

Using PowerShell to Raise Functional Levels

PowerShell provides a quick, scriptable way to raise the functional levels. This is especially useful if you prefer not to use the GUI or have many domains to update. Ensure you run on a machine with the Active Directory Module for PowerShell (like a DC or a management server with RSAT).

1. Open PowerShell: Launch an elevated PowerShell (Run as Administrator) with a user that has Enterprise Admin privileges.
2. Verify Current Levels (Optional): You can retrieve the current functional levels with:

Get-ADDomain <your domain> | Select-Object Name, DomainMode

Get-ADForest | Select-Object ForestMode

#For example, Get-ADDomain contoso.com | Select DomainMode might return Windows2016Domain. This step just confirms what we expect.

1. Raise the Domain Functional Level: Use the Set-ADDomainMode cmdlet to raise the domain level. For example:

Set-ADDomainMode -Identity "yourdomain.com" -DomainMode Windows2025Domain

#Replace "yourdomain.com" with your domain’s DNS name. The -DomainMode parameter accepts the target level; in this case, Windows2025Domain is the value for Windows Server 2025. PowerShell will #prompt for confirmation. Type <strong>Y</strong> (Yes) to proceed.
#The cmdlet will contact the domain naming master and perform the update. If successful, it will return without error. (If you get an error, read it closely: it might tell you a DC of an older #version was detected or that your credentials are insufficient.)

1. Raise the Forest Functional Level: Next, raise the forest level using Set-ADForestMode. For example:

Set-ADForestMode -Identity "yourdomain.com" -ForestMode Windows2025Forest

#Use your forest root domain name in -Identity (for a single-domain forest, it’s the same as the domain). Use Windows2025Forest as the new ForestMode value. Confirm with <strong>Y</strong> #when prompted. This updates the forest configuration. In a multi-domain forest, this will only succeed if all domains are already at the 2025 level (or at least have no lower OS DCs). If not, #it will warn you.

1. Verify the Change: After running these, double-check the new functional levels:

Get-ADDomain "yourdomain.com" | Select-Object Name, DomainMode

Get-ADForest "yourdomain.com" | Select-Object ForestMode

#The DomainMode and ForestMode should now report Windows2025Domain and Windows2025Forest, respectively. You can also verify via GUI or by running netdom query /domain:yourdomain FSMO to ensure #nothing looks awry (netdom doesn’t show functional level, but it’s a quick sanity check to see if DCs are still responding).

#The PowerShell method is efficient, especially if you integrate it into a script for consistency across environments. Just be sure to handle the confirmation prompts (you can add -#Confirm:$false to bypass the prompt if running in an automated script, but only do that when you’re sure).

Immediate Post-Change Checks

Raising the functional levels typically does not cause any disruption. However, it’s wise to perform a few checks right after:

• AD Replication: Ensure the functional level change is replicated to all DCs. The domain/forest level values should update on each domain controller. You can quickly check by running Get-ADDomain on multiple DCs (using the -Server parameter to target specific DCs) to see that they agree on the new mode. Or use repadmin /showrepl * /coord to confirm no replication error. If one DC was offline during the change, bring it online and verify it picks up the new levels (if a DC remains offline too long and misses the functional level update, it could be problematic when it comes back – so ideally, all DCs are online during the raise).
• Event Logs: Check the Event Viewer Directory Service log on the FSMO role holders (especially the one where you ran the command or the Schema Master). There should be informational events noting the functional level change. Look for any errors or warnings (though rare) that might indicate an issue. A successful raise might commonly log an event about the functional level change completion.
• Essential AD Functions: Test core functionalities to ensure nothing unintended is broken. For example, create a test user or reset a password (to ensure the DC allows it), or have a user log onto a workstation to ensure authentication usually works. These aren’t expected to fail because of a functional level change, but testing gives peace of mind.

At this point, your domain and forest are officially running at the functional level of Windows Server 2025. You have unlocked the new AD DS feature set. Now that the upgrade is complete, we’ll discuss some optional configurations and best practices.

Enabling the 32KB AD Database Page Feature (Optional)

One of the most significant new features requiring the 2025 functional level is the 32KB page size for the Active Directory database. By default, even on Windows Server 2025 DCs, your AD database (NTDS.dit) still operates in an 8KB-page compatibility mode (since we upgraded from earlier versions). Now that all DCs are running 2025 and the functional level is raised, you can enable the 32K pages feature to gain the scalability benefits.

Important: Enabling 32K pages is a one-way operation. Once the forest is converted to 32KB pages, you cannot revert to 8KB pages without a complete AD forest recovery from backup. All DCs must support it (which ours do since they are 2025). Also, any backups taken before enabling 32K pages will be unusable after the switch (you would need to take fresh backups). Therefore, consider this carefully and ensure a solid backup is taken just before this step.

If you decide to proceed (perhaps after hours), here’s how to enable the 32K page feature via PowerShell:

1. Pick a 2025 DC to initiate the change (ideally one of the FSMO role holders, like the Schema Master). Ensure it’s online and healthy.
2. Use the Enable-ADOptionalFeature cmdlet to turn on the “Database 32k pages feature”. For example:

Enable-ADOptionalFeature -Identity "Database 32k pages feature" `

-Scope ForestOrConfigurationSet `

-Target "yourforestname" `

-Server "YourDC.yourdomain.com"

#In this command:
#Identity "Database 32k pages feature" specifies the exact name of the optional feature to enable.
#Scope ForestOrConfigurationSet indicates this is a forest-wide feature.
#Target "yourforestname" should be your forest root domain (e.g., "contoso.com").
#Server "YourDC.yourdomain.com" is a domain controller to target for performing the change (you can use the one you’re on).

1. Confirm the action when prompted (it will ask if you’re sure since it’s irreversible). After confirmation, AD will enable the new page format. The command will first validate that all DCs in the forest are capable (it would abort if any DC wasn’t on 2025 or had an older JET database format).
2. Post-Enable: The change will trigger replication throughout the forest to update this setting. Monitor replication closely during this time. It might also cause each DC to perform maintenance on its database to start using the more prominent pages (this is usually quick and transparent, though on huge directories, you might see some increased disk I/O for a short period).
3. Check event logs for any messages regarding the 32k feature. Typically, an event might note that the forest optional feature was enabled.

For most environments, enabling 32K pages is beneficial if you hit certain AD limits (like huge groups or users with many group memberships). If your AD is relatively standard in size, you may enable it to be future-proof. Just remember the backup considerations.

If you don’t need it immediately, you can choose to hold off. Leaving the functional level at 2025 without 32K pages enabled is perfectly fine and still supported. You can always enable it later, as long as all DCs remain on 2025+.

Other Post-Migration Considerations

With the functional level raised and optional features considered, here are a few additional tasks and best practices to wrap up the migration project:

• Update Documentation: Document the new domain and forest functional levels, including the change date and the person who performed it. Update any network diagrams or inventory to reflect that all DCs are now Windows Server 2025. This will help future administrators (or audits) understand the current state. Also note any optional features enabled (e.g., “AD Recycle Bin enabled”, “32K pages enabled”) in your documentation.
• Enable Active Directory Recycle Bin (if not already done): Now is an ideal time if you haven’t enabled the AD Recycle Bin yet. The Recycle Bin allows easy restoration of accidentally deleted AD objects (users, groups, OUs) without needing an authoritative restore from backup. It requires at least a Windows Server 2008 R2 functional level, which we long surpassed. Enabling it is also done via Enable-ADOptionalFeature (the feature name is “Recycle Bin Feature”). For example:

Enable-ADOptionalFeature -Identity "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target "yourforestname"

This is a one-time forest-wide setting. Like 32K pages, it’s irreversible (you can’t disable the Recycle Bin once it’s on), but there’s almost no downside—only upside in recovering deleted objects. If your organization hasn’t turned it on, consider doing so now for the added safety net.

• Group Policy and Security Baselines: With new DCs and a higher functional level, review your Group Policy settings related to domain controllers. Windows Server 2025 comes with updated security baselines. Ensure settings like LDAP signing requirements, NTLM auditing, and Kerberos protocol settings follow best practices. You might find that you can increase security (for example, requiring LDAP signing on all connections) now that no old DCs or clients need to connect insecurely. The functional level doesn’t directly set GPO, but it guarantees DC capability for newer settings.
• Verify DFS Replication (SYSVOL): By now, your SYSVOL should be using DFSR (since FRS has not been supported since 2016). Still, confirm that SYSVOL is healthy. You can create a dummy file in the SYSVOL\domain\scripts folder on one DC and see it appear on the others. If not, investigate DFSR health (use dfsrdiag ReplicationState or check event logs under DFSR).
• Monitor for Any Issues: In the days following the raise, keep an eye on:
  • Event Logs: Especially on DCs, monitor for errors or warnings.
  • Replication Monitoring: Use tools or scripts to ensure replication remains error-free. Windows Admin Center or third-party monitoring tools can alert on AD replication problems.
  • User/Service Feedback: Listen for any unusual authentication issues or application errors that might indicate something related to the AD upgrade. For example, if an old application is using an outdated LDAP bind and you tightened security, you might get reports that it’s failing—then you can address that by updating that app’s configuration. Generally, these are edge cases, but they are worth being vigilant about.
• Long-Term Support and Patching: Now that you’re on Windows Server 2025, remember it’s a Long-Term Servicing Channel (LTSC) release. This means you’ll have standard support for ~5 years and extended support for ~10 years from its release. Plan your patching strategy to update these DCs with the latest cumulative and security patches. A fully patched AD environment is crucial for security (many attacks target unpatched domain controllers). Schedule regular maintenance windows for your DCs to install Windows Updates. The good news is that Windows Server 2025 supports features like Hotpatch (if connected to Azure Arc), which can even apply specific patches without reboot – something to look into for reducing downtime.
• Disaster Recovery Plan Update: Update your disaster recovery procedures. If you previously took backups on 2016 DCs, you should now do full, fresh backups on the 2025 DCs. If you enabled new features like 32K pages or Recycle Bin, ensure your recovery documentation covers those (for instance, restoring a 32K page AD database backup will require the target environment to be on 2025 as well).
• Plan Next Steps: With AD itself now modernized, you might shift focus to other areas:
  • Member Servers and Apps: Are there still Windows Server 2016 member servers or outdated domain-joined systems in your environment? If so, you might schedule upgrades for those as well to keep the ecosystem up-to-date.
  • Cloud Integration: If you haven’t already, consider integrating with Azure Active Directory (via Azure AD Connect) to take advantage of hybrid identity features. A fresh, supported on-prem AD is a good foundation for syncing identities to cloud services.
  • Enhanced Security Initiatives: Now might be a good time to implement additional AD security measures like the Tierred Administration model, Privileged Access Workstations for admins, or even Microsoft’s PAM (Privileged Access Management) if you have the Microsoft Identity Manager set up for it (PAM was introduced at the 2016 functional level, so your environment is capable).
  • AD Monitoring Tools: Evaluate whether you want to deploy AD monitoring solutions, such as Microsoft’s Azure AD DS Analyzer or third-party AD health and security scanners. These can help proactively catch misconfigurations or vulnerabilities.

Real-World Insights and Conclusion

It is a significant achievement to perform a zero-downtime Active Directory migration from Windows Server 2016 to Windows Server 2025 and raise functional levels. In real-world terms, we upgraded critical infrastructure without interrupting business operations—end-users likely never realized anything changed (exactly what we want: authentication and directory lookups continued seamlessly).

Reliability: By introducing new 2025 DCs in parallel, transferring roles gracefully, and slowly phasing out the old 2016 DCs, we minimized risk at each step. Each part of this series addressed a chunk of the process, allowing verification and confidence before moving on. This staged approach is much more reliable than an in-place upgrade or a big-bang migration. Now, with functional levels at 2025, the environment is running in a fully updated mode. This should translate to fewer issues in the long term, as we’ve eliminated legacy components and potential points of failure (for example, older replication services or outdated cryptography support).

Long-Term Support: Windows Server 2025 being an LTSC release means it will receive updates and support for years. Your Active Directory is “future-proofed” for the near future, and you have the latest features. Microsoft typically introduces a new AD functional level only when there are meaningful improvements (the last one was 2016, so it’s been a while). Being at 2025 means you’re on the cutting edge of on-premises AD capabilities. It also means you won’t need to do another AD upgrade project for a long time – likely until the next major Windows Server LTSC (and even then, you can introduce newer DCs alongside again).

Next Steps: After such a migration, the focus usually shifts to operational maintenance and leveraging new features:

• Use the new AD features to solve any old pain points (for example, if you had trouble with too many members in groups, the 32K DB pages feature might help now).
• Keep refining your AD design – maybe revisit your site topology, replication schedule, or group policy design, knowing you have a fresh start in some areas.
• Continuously train the IT staff on the new tools and features (like using the new ADAC (Active Directory Administrative Center) for specific tasks or exploring the updated AD PowerShell module capabilities in 2025).
• Consider doing a similar migration for any other directory services (e.g., if you have an AD LDS instance or a test forest, apply the lessons learned).

Finally, take a moment to celebrate! Migrating the Active Directory is no small feat. Following best practices and performing each step methodically (as we did through parts 1–10) ensures that your organization’s directory infrastructure is on a solid, modern foundation. This sets the stage for many years of stable identity management and the ability to integrate with the latest technologies.

Remember that a healthy AD environment requires ongoing care – regular backups, monitoring, and periodic updates – but now you can manage that confidently. We hope this series helped accomplish the migration and provided insight into Active Directory’s inner workings and how to approach changes with minimal risk.

Thank you for following along on this migration journey. With your Active Directory on Windows Server 2025 and functional levels raised, you’ve updated your core infrastructure. Great job on reaching the finish line!

PowerShell Command Summary for the Migration Series

Below is a summary of key PowerShell commands used throughout this 10-part Active Directory migration series. These commands cover various stages from preparation and installation of new DCs, through role transfers and checks, up to the final functional level raise and optional features. Use this table as a quick reference for similar projects:

The table above references all commands shown through the 10 part series.

PS.  A little known fact about Dave and myself is that we spend much of our career working as Microsoft contractors inside the Global Technology Readiness and SMSGR teams.   This time, we worked with various teams, and we have been working with customers migrating to Active Directory for the past 25 years.   We have seen every iteration of Active Directory, and it is encouraging to see Microsoft making all of the new investments in the on-prem tooling that 99% of customers still use.   WTG Microsoft, we look forward to the next 10 years to see what comes of AD 2035.

Cristal Kawula, Checkyourlogs.net