Upgrade domain controllers to a newer

version of Windows Server

Network Time
https://www.timesynctool.com/NetTimeSetup-314.exe

How to check if domain controllers are in sync with each

other?
Step 1 - Check the replication health

Run the following command :

Repadmin /replsummary
https://www.server-world.info/en/note?os=Windows_Server_2019&p=ntp&f=1

Configure NTP Server to provide time synchronization service to Clients.

The “/replsummary” operation quickly summarizes replication state and relative health of a
forest.

Step 2 - Check the inbound replication requests that are queued.

Repadmin /Queue

This command lists elements that are remaining in the replication queue. It displays inbound
replication requests that the Domain Controller needs to issue in order to become consistent with
its source replication partners.

Step 3 - Check the replication status

Repadmin /Showrepl

This command displays the replication status when the specified domain controller last attempted
to implement an inbound replication of Active Directory partitions. It helps in figuring out the
replication topology and replication failure.
Step 4 - Synchronize replication between replication partners

Repadmin /syncall

It ensures synchronization between replication partners

Step 5 - Force the KCC to recalculate the topology

Repadmin /KCC

This command forces the KCC (Knowledge Consistency Checker) on targeted domain
controller(s) to immediately recalculate its inbound replication topology. It checks and creates
the connections between the Domain Controllers. By default KCC runs in the background every
15 minutes to check if a new connection has been established between DCs.
Step 6 - Force replication

Repadmin /replicate

This command forces the replication of the specified directory partition to the destination domain
controller from the source DC.

 REPADMIN /KCC

 REPADMIN /REHOST

 REPADMIN /REPLICATE

 REPADMIN /REPLSUM

 REPADMIN /SHOWREPL

 REPADMIN /SHOWREPS

 REPADMIN /SHOWUTDVEC

 REPADMIN /SYNCALL

https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/replication-error-
8453

Method 1: Netdom query fsmo command line tool

Netdom is a command line tool used to manage Active Directory domains and trusts. The
Netdom tool is built into Windows Server 2003 and up.
1. On any domain controller open the command prompt. On Windows 2012 server click the start
button and type cmd, windows will search and return the command prompt. Click on “Command
Prompt”.

2. From the command prompt type “netdom query fsmo” and hit “enter”.

The above command should return the five roles and which DC they are on.

That’s it for the Netdom query method, very simple and straightforward.

Method 2: Powershell Get FSMO Roles

Using Powershell will require two lines of code, one to return the forest roles and another to
return the domain roles.

1. Open windows Powershell. On 2012 server click start and type Powershell. Click Windows
Powershell from the search results

2. From the PowerShell command line type: Get-ADForest yourdomain | Format-Table

SchemaMaster,DomainNamingMaster

The above command returns the forest FSMO roles.

3. Type: Get-ADDomain yourdomain | format-table

PDCEmulator,RIDMaster,InfrastructureMaster

The above command will return the domain FSMO roles.

That’s it for method two.

I recommend becoming familiar with which DCs in your environment hold the FSMO roles. It’s
good to understand what these roles are and the DCs that hold them in case a disaster does occur
or you have a specific reason to move them.

Seize FSMO roles using the NTDSUtil tool

First, open the command prompt with administrative privileges.

Type ntdsutil and press Enter.

Type roles and press Enter.
Type connections and press Enter.
Type connect to server DC01 and press Enter, where DC01 type the server computer name to
transfer the FSMO roles to.
Type quit and press Enter.

Seize FSMO roles on a Domain Controller

January 21, 2018 Dimitris Tonias Windows Server 2016

The process of transferring one or more FSMO roles from one Domain Controller to another is a
fairly easy process. However, given that all DCs are online and are functioning properly.

What happens if a DC, which already has an FSMO role, crashes or shuts down for a long time?
FSMO role transfer cannot be completed as the server is no longer online.

For similar cases, we use a forced transfer of FSMO roles, a process that is referred as ‘seize’.
Seizing FSMO roles from a non-functional DC is the last solution to the problem and means that
the DC will not come back into operation without reinstalling it.

Even if you can restore it (eg after a crash), if you have seized its roles, then it should not come
back to the network because it will cause even more problems in the existing infrastructure.

The FSMO roles can be seized by either PowerShell or NTDSUtil as you will see below.
To seize the RID Master, PDC Emulator, and Infrastructure Master roles, you will need to log in
to DC with Domain Administrator privileges. For Schema Master and Domain Naming Master
roles, you must have Schema Admin and Enterprise Admin permissions respectively.

Seize FSMO roles using PowerShell

The command we use is the same we use for the simple transfer, except that we need to add the -
Force switch.

So, for example, to seize the Naming Master role, use the following command.

Move-ADDirectoryServerOperationMasterRole -Identity <TargetDC> -

OperationMasterRole domainnamingmaster -Force

Where in the -OperationMasterRole switch you can declare one or more FSMO roles separated
by a comma (,). For example:

-OperationMasterRole schemamaster, domainnamingmaster, pdcemulator,

ridmaster, infrastructuremaster

Seize FSMO roles using the NTDSUtil tool

First, open the command prompt with administrative privileges.

Type ntdsutil and press Enter.

Type roles and press Enter.
Type connections and press Enter.
Type connect to server DC01 and press Enter, where DC01 type the server computer name to
transfer the FSMO roles to.
Type quit and press Enter.

Then, we will seize the FSMO roles one by one with the corresponding command, as the case
may be. After each Enter appears a confirmation window. Just click Yes to continue.

Also, to mention that, during the seize process, NTDSUtil tries to make a simple transfer first
(which obviously fails) and then proceeds to the forcible transfer.
For the Schema Master role, type seize schema master and press Enter.
For the Domain Naming Master role, type seize naming master and press Enter.
For the RID Master role, type seize rid master and press Enter.
For the PDC Emulator role, type seize pdc and press Enter.
For the Infrastructure Master role, type seize infrastructure master and press Enter.

Finally, type quit to exit the NTDSUtil environment.

Step 1: List Current FSMO Role Holders

Before moving the FSMO roles it is a good idea to check which domain controllers hold which
roles.

You can list which domain controllers hold FSMO roles with these two PowerShell commands:

Get domain level FSMO roles

get-addomain | select InfrastructureMaster, PDCEmulator, RIDMaster

Get forest level FSMO roles

Get-ADForest | select DomainNamingMaster, SchemaMaster

Below is a screenshot of the results in my domain.

List of installed roles in my domain:

 InfrastructureMaster is on DC1
 PDCEmulator is on DC2
 RIDMaster is on DC2
 DomainNamingMaster is on DC1
 Schemamaster is on DC1

I want to move all the roles from DC2 to DC1, I’ll demonstrate this below.

Step 2: Transfer FSMO Roles

I’ll first demonstrate transferring roles with PowerShell, it is by far the easier option of the two
(in my opinion).

You want to log into the server that you will be transferring the roles to, in my case it is DC1.

To move a role with PowerShell you will use the Move-

ADDirectoryServerOperationMasterRole cmdlet, then the hostname of the server to transfer
to.

Transfer PDCEmulator
Move-ADDirectoryServerOperationMasterRole -Identity "dc1" PDCEmulator
Transfer RIDMaster
Move-ADDirectoryServerOperationMasterRole -Identity "dc1" RIDMaster

Transfer InfrastrctureMaster
Move-ADDirectoryServerOperationMasterRole -Identity "dc1" Infrastructuremaster

Transfer DomainNamingMaster
Move-ADDirectoryServerOperationMasterRole -Identity "dc1" DomainNamingmaster

Transfer SchemaMaster
Move-ADDirectoryServerOperationMasterRole -Identity "dc1" SchemaMaster

Here is a screenshot of when I moved PDCEmulator and RIDMaster to DC1.

Now if I re-run the commands to list the FSMO roles I should see them all on DC1.
Yes, I have confirmed all the roles are now on DC1. As you can see moving FSMO roles with
PowerShell is very easy to do.

dcgpofix /ignoreschema /target:dc

dcgpofix /ignoreschema /target:domain

dcdiag /test:replications

repadmin /syncall /AdeP

repadmin /showreps

Domain functional level settings

The msDS-Behavior-Version attribute is on the naming context (NC) head for the domain, that
is, DC=corp, DC=contoso, DC=com.

You can set the following values for this attribute:

 Value of 0 or not set=mixed level domain

 Value of 1=Windows Server 2003 domain level
 Value of 2=Windows Server 2003 domain level
 Value of 3=Windows Server 2008 domain level
 Value of 4=Windows Server 2008 R2 domain level
Domain functional level settings

The msDS-Behavior-Version attribute is on the naming context (NC) head for the domain, that
is, DC=corp, DC=contoso, DC=com.

You can set the following values for this attribute:

 Value of 0 or not set=mixed level domain

 Value of 1=Windows Server 2003 domain level
 Value of 2=Windows Server 2003 domain level
 Value of 3=Windows Server 2008 domain level
 Value of 4=Windows Server 2008 R2 domain level

Mixed mode and native mode settings

The ntMixedDomain attribute is on the naming context (NC) head for the domain, that is,
DC=corp, DC=contoso, DC=com.

You can set the following values for this attribute:

 Value of 0=Native level domain

 Value of 1=Mixed level domain

Forest level setting

The msDS-Behavior-Version attribute is on the CN=Partitions object in the Configuration

naming context (NC), that is, CN=Partitions, CN=Configuration, DC= ForestRootDomain.

You can set the following values for this attribute:

 Value of 0 or not set=mixed level forest

 Value of 1=Windows Server 2003 interim forest level
 Value of 2=Windows Server 2003 forest level

Note

When you increase the msDS-Behavior-Version attribute from the 0 value to the 1 value
by using Adsiedit.msc, you receive the following error message:
Illegal modify operation. Some aspect of the modification is not permitted.

 Value of 3=Windows Server 2008 domain level

 Value of 4=Windows Server 2008 R2 domain level

https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/raise-active-
directory-domain-forest-functional-levels?source=recommendations
Note

Beginning with Windows Server 2012 R2, File Replication Service (FRS) is deprecated. A new
domain that is created on a domain controller that runs at least Windows Server 2012 R2 must be
set to the Windows Server 2008 domain functional level or higher.

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-
levels

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/upgrade-domain-
controllers

Step-by-Step Guide for upgrading SYSVOL replication to

DFSR (Distributed File System Replication)
SYSVOL is a folder shared by domain controller to hold its logon scripts, group policies and
other items related to AD. All the domain controllers in network will replicate the content of
SYSVOL folder. The default path for SYSVOL folder is %SystemRoot%\SYSVOL. This
folder path can define when you install the active directory.

Windows Server 2003 and 2003 R2 uses File Replication Service (FRS) to replicate SYSVOL
folder content to other domain controllers. But Windows server 2008 and later uses Distributed
File System (DFS) for the replication. DFS is more efficient than FRS. Since windows server
2003 is going out of support, most people already done or still looking for migrate in to latest
versions. However migrating FSMO roles WILL NOT migrate SYSVOL replication from FRS
to DFS. Most of the engineers forget about this step when they migrate from windows 2003 to
new versions.

For FRS to DFS migration we uses the Dfsrmig.exe utility. More info about it available on
https://technet.microsoft.com/en-au/library/dd641227(v=ws.10).aspx

For the demo I am using windows server 2012 R2 server and I migrated FSMO roles already
from a windows server 2003 R2 server.

In order to proceed with the migration forest function level must set to windows server 2008 or
later. So if your organization not done this yet first step is to get the forest and domain function
level updated.

You can verify if the system uses the FRS using dfsrmig /getglobalstate , To do this
1) Log in to domain controller as Domain admin or Enterprise Admin
2) Launch powershell console and type dfsrmig /getglobalstate. Output explains it’s not
initiated DFRS migration yet.

Before move in to the configurations we need to look into stages of the migration.

There are four stable states going along with the four migration phases.

1) State 0 – Start
2) State 1 – Prepared
3) State 2 – Redirected
4) State 3 – Eliminated

State 0 – Start

With initiating this state, FRS will replicate SYSVOL folder among the domain controllers. It is
important to have up to date copy of SYSVOL before begins the migration process to avoid any
conflicts.

State 1 – Prepared

In this state while FRS continues replicating SYSVOL folder, DFSR will replicate a copy of
SYSVOL folder. It will be located in %SystemRoot%\SYSVOL_DFRS by default. But this
SYSVOL will not response for any other domain controller service requests.

State 2 – Redirected

In this state the DFSR copy of SYSVOL starts to response for SYSVOL service requests. FRS
will continue the replication of its own SYSVOL copy but will not involve with production
SYSVOL replication.

State 3 – Eliminated

In this state, DFS Replication will continue its replication and servicing SYSVOL requests.
Windows will delete original SYSVOL folder users by FRS replication and stop the FRS
replication.
In order to migrate from FRS to DFSR its must to go from State 1 to State 3.

Let’s look in to the migration steps.

Prepared State

1. Log in to domain controller as Domain admin or Enterprise Admin

2. Launch powershell console
3. Type dfsrmig /setglobalstate 1 and press enter

4. Type dfsrmig /getmigrationstate to confirm all domain controllers have reached prepared
state

Redirected State

1. Log in to domain controller as Domain admin or Enterprise Admin

2. Launch powershell console
3. Type dfsrmig /setglobalstate 2 and press enter
4. Type dfsrmig /getmigrationstate to confirm all domain controllers have reached redirected
state

Eliminated State

1. Log in to domain controller as Domain admin or Enterprise Admin

2. Launch powershell console
3. Type dfsrmig /setglobalstate 3 and press enter

4. Type dfsrmig /getmigrationstate to confirm all domain controllers have reached eliminated
state
This completes the migration process and to confirm the SYSVOL share, type net share
command and enter.

Also make sure in each domain controller FRS service is stopped and disabled.
https://www.checkyourlogs.net/how-to-fix-missing-sysvol-and-netlogon-share-and-replication-
issues-on-new-domain-controller-at-azure/

hmmm about HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\SysvolReady

registry entry: FRSDiag Log explicitly say: ..... Checking NtFrs related Registry Keys for
possible problems... SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SysvolReady =
0 :: ERROR: SysvolReady is not set to 1 :: SYSVOL is likely not Sharing! This key should NOT
be changed manually but this should be addressed! See article KB.327781 (How to Troubleshoot
Missing SYSVOL and NETLOGON Shares on Windows Server) for further information! failed
with 1 error(s) and 0 warning(s)
Restore FRS replicas
The global BurFlags registry key contains REG_DWORD values, and is located in the following
location in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/
Restore\Process at Startup

The most common values for the BurFlags registry key are:

 D2, also known as a nonauthoritative mode restore.

 D4, also known as an authoritative mode restore.

You can also perform BurFlags restores at the same time as you restore data from backup or
from any other known good source, and then restart the service.

To perform a nonauthoritative restore, stop the FRS service, configure the BurFlags registry
key, and then restart the FRS service. Follow these steps:

1. Select Start, and then select Run.

2. In the Open box, type cmd and then press ENTER.
3. In the Command box, type net stop ntfrs.
 4. Select Start, and then select Run.
5. In the Open box, type regedit and then press ENTER.
6. Locate the following subkey in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\
Backup/Restore\Process at Startup
7. In the right pane, double-click BurFlags.
8. In the Edit DWORD Value dialog box, type D2 and then select OK.
9. Quit Registry Editor, and then switch to the Command box.
10. In the Command box, type net start ntfrs.
11. Quit the Command box.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/use-burflags-to-
reinitialize-frs