Windows Server 2025 domain controllers and DC migration

Start DC01 and DC02. Work on DC01 as SAATLAB\adm.rahul in PowerShell as administrator.

1Check health, levels and optional features

On DC01:

dcdiag /q
repadmin /replsummary | Select-String 'fails'
(Get-ADForest).ForestMode; (Get-ADDomain).DomainMode
Get-ADOptionalFeature -Filter * | Select-Object Name, @{n='Enabled';e={[bool]$_.EnabledScopes}}

You should see something like this:

Source DSA          largest delta    fails/total %%   error
Destination DSA     largest delta    fails/total %%   error
Windows2025Forest
Windows2025Domain

Name                                Enabled
----                                -------
Recycle Bin Feature                    True
Privileged Access Management Feature   False
Database 32k pages feature             False

dcdiag /q prints nothing when every test passes, which is what you want before any change to DCs. The forest is already at the 2025 level because you created it with Server 2025 in Lesson 11.

✅ Checkpoint: dcdiag /q is silent, replication has no failures, and both levels are Windows2025.

2Promote DC03, the “new” DC

On your laptop, create DC03 the way you created PDC1 in Lesson 33:

VBoxManage createvm --name DC03 --ostype Windows2025_64 --basefolder C:\Lab\VMs --register --default
VBoxManage modifyvm DC03 --memory 2048 --cpus 2 --nic1 natnetwork --nat-network1 LabNet
VBoxManage createmedium disk --filename C:\Lab\VMs\DC03\DC03.vdi --size 40960
VBoxManage storageattach DC03 --storagectl SATA --port 0 --device 0 --type hdd --medium C:\Lab\VMs\DC03\DC03.vdi
VBoxManage storageattach DC03 --storagectl SATA --port 1 --device 0 --type dvddrive --medium C:\Lab\ISO\server2025.iso
VBoxManage startvm DC03

Install Server 2025 Datacenter Evaluation without Desktop Experience, set the password, and choose 15 in sconfig.

On DC03:

New-NetIPAddress -InterfaceAlias Ethernet -IPAddress 10.0.0.12 -PrefixLength 24 -DefaultGateway 10.0.0.1 | Out-Null
Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses 10.0.0.10
Add-Computer -DomainName saatlab.internal -NewName DC03 -Credential SAATLAB\adm.rahul -Restart

After the restart, from DC01, check the new server and promote it:

Install-WindowsFeature AD-Domain-Services -ComputerName DC03 | Out-Null
$cred = Get-Credential SAATLAB\adm.rahul
$dsrm = Read-Host -AsSecureString 'DSRM password for DC03'
Invoke-Command -ComputerName DC03 -ScriptBlock {
    Test-ADDSDomainControllerInstallation -DomainName saatlab.internal -Credential $using:cred -SafeModeAdministratorPassword $using:dsrm -SiteName HQ | Select-Object Status, Message
    Install-ADDSDomainController -DomainName saatlab.internal -InstallDns -SiteName HQ -Credential $using:cred -SafeModeAdministratorPassword $using:dsrm -Force
}

You should see something like this before DC03 restarts:

Status  Message
------  -------
Success Operation completed successfully

Running Test-ADDSDomainControllerInstallation first is a habit worth keeping: it checks credentials, DNS, functional levels and naming without changing anything.

✅ Checkpoint: Get-ADDomainController -Filter * lists DC01, DC02 and DC03 after DC03 restarts.

3Transfer the FSMO roles to DC03, then back

On DC01:

Move-ADDirectoryServerOperationMasterRole -Identity DC03 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Confirm:$false
netdom query fsmo

You should see something like this:

Schema master               DC03.saatlab.internal
Domain naming master        DC03.saatlab.internal
PDC                         DC03.saatlab.internal
RID pool manager            DC03.saatlab.internal
Infrastructure master       DC03.saatlab.internal
The command completed successfully.

This is a transfer, not a seizure: DC01 handed the roles over cleanly because it was online. Remember the PDC Emulator is also the forest’s time source, so in a real migration you’d set the external time source on the new PDC (Lesson 21) right after moving it.

Move them back to DC01, as the rest of the course expects:

Move-ADDirectoryServerOperationMasterRole -Identity DC01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Confirm:$false
(netdom query fsmo | Select-String 'DC01').Count

You should see this:

5

✅ Checkpoint: All five roles went to DC03 and came back to DC01.

4Demote DC03 cleanly

From DC01, demote DC03 and remove the AD role:

Invoke-Command -ComputerName DC03 -ScriptBlock {
    Uninstall-ADDSDomainController -LocalAdministratorPassword (Read-Host -AsSecureString 'New local admin password') -Credential $using:cred -Force
}

DC03 removes its copy of AD, unregisters its DNS records, deletes its server object from Sites, and restarts as an ordinary member server. Wait for it to come back.

Then finish the clean-up from DC01:

Invoke-Command -ComputerName DC03 -ScriptBlock { Uninstall-WindowsFeature AD-Domain-Services | Select-Object Success }
Get-ADDomainController -Filter * | Select-Object -ExpandProperty Name
Get-DnsServerResourceRecord -ZoneName saatlab.internal -Name '@' -RRType A | Select-Object @{n='IP';e={$_.RecordData.IPv4Address}}

You should see something like this:

Success
-------
   True

DC01
DC02

IP
--
10.0.0.10
10.0.0.11

No DC03 in the DC list and no 10.0.0.12 in the domain’s A records: a clean demotion. You can now shut down DC03 and delete the VM.

✅ Checkpoint: DC03 is no longer a DC and its DNS records are gone.

5See a 2025 LDAP default in action

On DC01, compare a signed Kerberos bind with a plain simple bind:

$p = Read-Host 'priya.sharma password'
$secure = New-Object DirectoryServices.DirectoryEntry('LDAP://DC01.saatlab.internal/DC=saatlab,DC=internal', 'SAATLAB\priya.sharma', $p, [DirectoryServices.AuthenticationTypes]'Secure, Signing, Sealing')
$secure.RefreshCache(); 'Signed bind: ' + $secure.distinguishedName
$plain = New-Object DirectoryServices.DirectoryEntry('LDAP://DC01.saatlab.internal/DC=saatlab,DC=internal', 'priya.sharma@saatlab.internal', $p, [DirectoryServices.AuthenticationTypes]::None)
try { $plain.RefreshCache() } catch { 'Plain bind: ' + $_.Exception.InnerException.Message }

You should see something like this:

Signed bind: DC=saatlab,DC=internal
Plain bind: A more secure authentication method is required for this server.

A simple bind sends the password in clear text unless the connection uses TLS. A DC that enforces LDAP signing refuses it. New Server 2025 deployments require signing by default; if your plain bind succeeded, enable the Group Policy setting Domain controller: LDAP server signing requirements Enforcement on the Domain Controllers OU and test again.

Old printers, scanners and apps that “log in to LDAP” often use them, so test devices before you migrate, and move them to LDAPS (port 636) with a certificate from your CA.

✅ Checkpoint: The signed bind worked and the plain simple bind was refused.