Tag Archives: Replication

Active Directory Replication Status Review Using PowerShell

Data Replication is crucial for healthy Active Directory Environment. There are different ways to check status of replication. In this article I am going to explain how you can check status of domain replication using PowerShell.

For a given domain controller we can find its inbound replication partners using, 

Get-ADReplicationPartnerMetadata -Target REBEL-SRV01.rebeladmin.com

Above command provide detail description for the given domain controller including last successful replication, replication partition, server etc. 

We can list down all the inbound replication partners for given domain using, 

Get-ADReplicationPartnerMetadata -Target "rebeladmin.com" -Scope Domain

In above command the scope is defined as the domain. this can change to forest and get list of inbound partners in the forest. The output is for default partition.  If needed the partition can change using – Partition to Configuration or Schema partition. It will list down the relevant inbound partners for given partition. 

Associated replication failures for a site, forest, domain, domain controller can find using Get-ADReplicationFailure cmdlet. 

Get-ADReplicationFailure -Target REBEL-SRV01.rebeladmin.com

Above command will list down the replication failures for the given domain controller. 

Replication failures for domain can find out using, 

Get-ADReplicationFailure -Target rebeladmin.com -Scope Domain

Replication failures for forest can find out using, 

Get-ADReplicationFailure -Target rebeladmin.com -Scope Forest

Replication failures for site can find out using, 

Get-ADReplicationFailure -Target LondonSite -Scope Site

In command, LondonSite can replace using relevant site name. 

Using both Get-ADReplicationPartnerMetadata and Get-ADReplicationFailure, following PowerShell script can provide report against specified domain controller. 

## Active Directory Domain Controller Replication Status##

$domaincontroller = Read-Host 'What is your Domain Controller?'

## Define Objects ##

$report = New-Object PSObject -Property @{

ReplicationPartners = $null

LastReplication = $null

FailureCount = $null

FailureType = $null

FirstFailure = $null


## Replication Partners ##

$report.ReplicationPartners = (Get-ADReplicationPartnerMetadata -Target $domaincontroller).Partner

$report.LastReplication = (Get-ADReplicationPartnerMetadata -Target $domaincontroller).LastReplicationSuccess

## Replication Failures ##

$report.FailureCount  = (Get-ADReplicationFailure -Target $domaincontroller).FailureCount

$report.FailureType = (Get-ADReplicationFailure -Target $domaincontroller).FailureType

$report.FirstFailure = (Get-ADReplicationFailure -Target $domaincontroller).FirstFailureTime

## Format Output ##

$report | select ReplicationPartners,LastReplication,FirstFailure,FailureCount,FailureType | Out-GridView

In this command, it will give option for engineer to specify the Domain Controller name. 

$domaincontroller = Read-Host 'What is your Domain Controller?'

Then its creates some object and map those to result of the PowerShell command outputs. Last but not least it provides a report to display a report including, 

Replication Partner (ReplicationPartners)

Last Successful Replication (LastReplication)

AD Replication Failure Count (FailureCount)

AD Replication Failure Type (FailureType)

AD Replication Failure First Recorded Time (FirstFailure)


Further to Active Directory replication topologies, there are two types of replications.

1) Intra-Site – Replications between domain controllers in same Active Directory Site

2) Inter-Site – Replication between domain controllers in different Active Directory Site

We can review AD replication site objects using Get-ADReplicationSite cmdlet. 

Get-ADReplicationSite -Filter *

Above command returns all the AD replication sites in the AD forest. 


We can review AD replication site links on the AD forest using, 

Get-ADReplicationSiteLink -Filter *

In site links, most important information is to know the site cost and replication schedule. It allows ro understand the replication topology and expected delays on replications. 

Get-ADReplicationSiteLink -Filter {SitesIncluded -eq "CanadaSite"} | Format-Table Name,Cost,ReplicationFrequencyInMinutes -A

Above command list all the replication sites link included CanadaSite AD site along with the site link name, link cost, replication frequency. 

A site link bridge can use to bundle two or more site links and enables transitivity between site links.

Site link bridge information can retrieve using, 

Get-ADReplicationSiteLinkBridge -Filter *

Active Directory sites may use multiple IP address segments for its operations. It is important to associate those with the AD site configuration so domain controllers know which computer related to which site. 

Get-ADReplicationSubnet -Filter * | Format-Table Name,Site -A

Above command will list down all the Subnets in the forest in a table with subnet name and AD site.


Bridgehead servers are operating as the primary communication point to handle replication data which comes in and go out from AD site. 

We can list down all the preferred bridgehead servers in a domain using, 

$BHservers = ([adsi]"LDAP://CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=rebeladmin,DC=com").bridgeheadServerListBL

$BHservers | Out-GridView

In above command the attribute value bridgeheadServerListBL retrieve via ADSI connection. 

We can list down all of these findings using on script. 

## Script to gather information about Replication Topology ##

## Define Objects ##

$replreport = New-Object PSObject -Property @{

Domain = $null


## Find Domain Information ##

$replreport.Domain = (Get-ADDomain).DNSroot

## List down the AD sites in the Domain ##

$a = (Get-ADReplicationSite -Filter *)

Write-Host "########" $replreport.Domain "Domain AD Sites" "########"

$a | Format-Table Description,Name -AutoSize

## List down Replication Site link Information ##

$b = (Get-ADReplicationSiteLink -Filter *)

Write-Host "########" $replreport.Domain "Domain AD Replication SiteLink Information" "########"

$b | Format-Table Name,Cost,ReplicationFrequencyInMinutes -AutoSize

## List down SiteLink Bridge Information ##

$c = (Get-ADReplicationSiteLinkBridge -Filter *)

Write-Host "########" $replreport.Domain "Domain AD SiteLink Bridge Information" "########"

$c | select Name,SiteLinksIncluded | Format-List

## List down Subnet Information ##

$d = (Get-ADReplicationSubnet -Filter * | select Name,Site)

Write-Host "########" $replreport.Domain "Domain Subnet Information" "########"

$d | Format-Table Name,Site -AutoSize

## List down Prefered BridgeHead Servers ##

$e = ([adsi]"LDAP://CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=rebeladmin,DC=com").bridgeheadServerListBL

Write-Host "########" $replreport.Domain "Domain Prefered BridgeHead Servers" "########"


## End of the Script ##

The only thing we need to change is the ADSI connection with relevant domain DN. 

$e = ([adsi]"LDAP://CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=rebeladmin,DC=com")

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

How Active Directory Replication Works?

Active Directory Infrastructure is depending on healthy replication. Every domain controller in the network should aware of every change which has made. When domain controller triggers a sync, it passes the data through the physical network to the destination.

In active directory environment, there are mainly two types of replications.

1) Intra-Site Replication 

2) Inter-Site Replication

Intra-Site Replication

As the name confirms, this covers the replication happens with in a site. By default, (according to Microsoft) any domain controller will aware of any directory update within 15 seconds. Within site despite the number of domain controllers, any directory update will be replicate in less than one minute. 


Within the site, the replication connections are performing in ring topology. Which mean an any give domain controller have two replication links (of cause if there is minimum of three domain controllers). this architecture will prevent domain controllers having endless replication loops. As example if there are 5 domain controllers and if all are connected to each other with one-to-one connection each domain controller will have 4 connection and when there is an update in one of the domain controller it will need to advertise it to 4 domain controllers. then the first one to receive update will advertise to its 4 connected domain controllers and its go on and on. It will be too much replication processes to advertise, listen and sort out the conflicts. But in ring topology, despite the number of domain controllers in the site, any given domain controller only need to advertise or listen to two domain controllers in any given time. This replication topology is no need to configure manually and active directory will automatically determine the connections it need to make. When number of domain controllers grow, the replication time can grow as well as its in ring topology. But to avoid the latency active directory will create additional connections. This is also determined automatically and we do not need to worry about these replication connections. 

Inter-Site Replication

If active directory infrastructure contains more than one site, a change happens in one site need to replicate over to other sites. This is called as inter-site replication and its topology is different from the intra-site replication. Replication with in site is always benefited from the high-speed links. But when it comes to between sites bandwidth, latency and reliability comes to considerations. In previous section, we discussed about site-links, site costs and replication schedules when we can use to control the inter-site replication. 


When it comes to inter-site, the replication will happen via site links. The replication with in each site still uses the ring topology. In above example let’s assume an object been added to REBEL-DC-02 in London Site. Now based on the topology it will be advertise to REBEL-DC-03 too. But apart from been domain controller, this particular domain controller is bridgehead server as well. So, it is this server’s responsibility to advertise the updates it received in to the bridge server in Canada Site which is REBEL-DC-04. Once it receives the update it will advertise to other domain controllers in the site. The replication between sites still need to obey the rules which is applied to control the replication. Active Directory domain services automatically selects the bridgehead server for a site. But if need we can decide what should act as bridgehead server for site. 

This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Step-by-Step Migration Guide to Active Directory 2016 (PowerShell Guide)

This is my first blog post in 2018. So, first of all Happy New year to my blog readers!

In many occasions, I have written articles about Active Directory Migrations. But still I get lots of emails from readers to clarify things about AD migrations. So, I thought to revisit it by covering most common questions I gets. Also in this blog post, I will show how to do the AD migration only using PowerShell.

Migration task itself is very straight forward. But there are other things you need to consider before you do an AD migration. In below I listed a checklist you can use in many occasions. 

Active Directory Migration Check List 

Evaluate business requirement for active directory migration 

Perform Audit on Existing Active Directory Infrastructure to verify its health status

Create Plan for implementation Process

Prepare Physical / Virtual resources for Domain Controller

Install Windows server 2016 Standard / Datacenter

Patch Servers with latest Windows Updates

Assign Dedicate IP address to Domain Controller

Install AD DS Role

Migrate Application and Server Roles from the Existing Domain Controllers

Migrate FSMO roles to new Domain Controllers

Add New Domain controller to the Existing DR Solution

Decommission old domain controllers 

Raise the Domain and Forest Functional level

On Going Maintenance 

Tips – During audit process you need to verify if your applications will support new AD schema. it is very rare but I have seen legacy applications which is not support newer schema versions. 
Also in some scenarios, it is hard to replace primary dc with a DC running with different IP address. AD is supported for IP changes even after FSMO role changes. There for if need you can swap IP addresses after you migrate FSMO roles. 
In my demo environment, I have an existing domain controller running with windows server 2012 R2. I am going to migrate it to a windows server 2016 server.
In the demonstration, REBEL-WIN-DC01 is the domain controller with windows server 2012 R2 and REBEL-SDC01 is the domain controller with windows server 2016. 
Tip – When you introduce new domain controllers to the existing infrastructure it is recommended to introduce to the forest root level first and then go to the domain tree levels.
Add Additional Domain Control 
As per plan I need to add a new domain controller with windows server 2016 to existing domain first.
1) Log in to the Server (Windows server 2016) as a member of local administrators group. 
2) Add server to the existing domain as member. 
3) Log in to domain controller as enterprise administrator.  
4) Verify the static IP address allocation using ipconfig /all.
5) Launch the PowerShell Console as an Administrator
6) Before the configuration process, we need to install the AD DS Role in the given server. In order to do that we can use Following command. 

Install-WindowsFeature –Name AD-Domain-Services -IncludeManagementTools
7) After successful role service Installation, next step is to configure the domain controller. It can be done using following PowerShell command. 
-DomainName "rebeladmin.com"
-SiteName "Default-First-Site-Name"
-ReplicationSourceDC "REBEL-WIN-DC01.rebeladmin.com"
-DatabasePath "C:\Windows\NTDS"
-LogPath "C:\Windows\NTDS"
-SysvolPath "C:\Windows\SYSVOL"




This cmdlet will install the domain controller in active directory infrastructure.


This Parameter can use to define the active directory site name.  the default value is Default-First-Site-Name


This parameter defines the FQDN for the active directory domain.


Using this parameter can define the active directory replication source. By default, it will use any available domain controller. But if need we can be specific.


Using this can specify whether DNS role need to install with active directory domain controller. For new forest, it is default requirement to set it to $true.


Log path can use to specify the location to save domain log files.


This is to define the SYSVOL folder path. Default location for it will be C:\Windows


This parameter will force command to execute by ignoring the warning. It is typical for the system to pass the warning about best practices and recommendations. 

Once execute the command it will ask for SafeModeAdministrator Password. Please use complex password to proceed. This will be used for DSRM.
After configuration completed, restart the system and log back in as administrator to check the AD DS status. 

Get-Service adws,kdc,netlogon,dns
Move FSMO Roles 
Now we have additional domain controller and next step is to migrate FSMO roles to the new server. 
We can migrate all five FSMO roles to the New domain controller using following powershell command,
Move-ADDirectoryServerOperationMasterRole -Identity REBEL-SDC01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
In above the REBEL-SDC01 is domain controller running with windows server 2016. Once its completed, we can verify the new FSMO role holder using 
Netdom query fsmo

Decommission Old Domain Controller 
Now we moved FSMO roles over and next step is to decommission old DC which is running with windows server 2012 R2. 
In order to do that, log in to old DC as enterprise administrator and run following powershell command,

Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartition
After execute the command it will ask to define password for the local administrator account.
Once its completed it will be a member server of the rebeladmin.com domain.
Raise Domain and Forest Functional level

After you remove your last domain controller running with windows server 2012 r2 (if its 2012 or 2008 r2 same thing apply) we can raise Domain and Forest Functional level to windows server 2016. You need it to have features comes with AD 2016. 
To upgrade domain functional level, you can use following powershell command
Set-ADDomainMode –identity rebeladmin.com -DomainMode Windows2016Domain
To upgrade forest function level, you can use following command

Set-ADForestMode -Identity rebeladmin.com -ForestMode Windows2016Forest
After the migration completes we still need to verify if its completes successfully.
Get-ADDomain | fl Name,DomainMode
This command will show the current Domain functional level of the domain after the migration. 
Get-ADForest | fl Name,ForestMode
Above command will show the current forest functional level of the domain. 
Also, you can use
Get-EventLog -LogName 'Directory Service' | where {$_.eventID -eq 2039 -or $_.eventID -eq 2040} | Format-List
To search event ID 2039 and 2040 in the “Directory Service” log which will show the forest and domain functional level updates.
Event ID 1458 will verify the transfer of the FSMO roles. 

Get-EventLog -LogName 'Directory Service' | where {$_.eventID -eq 1458} | Format-List
You can use following to verify the list of domain controllers and make sure the old domain controller is gone. 
Get-ADDomainController -Filter * | Format-Table Name, IPv4Address
Apart from these you also can go through Directory Service and DNS Logs to see if there’s any issues recorded.
This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

What is Content Freshness protection in DFSR?

Healthy Replication is a must for active directory environment. SYSVOL folder in domain controllers contain policies and log on scripts. It is replicated between domain controllers to maintain up to date config (consistency). Before windows server 2008, it used FRS (File Replication Service) to replicate sysvol content among domain controllers. With Windows server 2008 FRS was deprecated and introduced Distributed File System (DFS) for replication.

A healthy replication required healthy communication between domain controllers. sometime the communication can interrupt due to domain controller failure or link failure. Based on the impact it is still possible that the communication re-established after period of time. Then it will try to resume replication and catch up with SYSVOL changes. In such scenario, we may see event 4012 in event viewer. 

The DFS Replication service stopped replication on the replicated folder at local path c:\xxx. It has been disconnected from other partners for 70 days, which is longer than the MaxOfflineTimeInDays parameter. Because of this, DFS Replication considers this data to be stale, and will replace it with data from other members of the replication group during the next replication. DFS Replication will move the stale files to the local Conflict folder. No user action is required.

With windows server 2008, Microsoft introduced a setting called content freshness protection to protect DFS shares from stale data. DFS also use a multi-master database similar to active directory. It also has tombstone time limit similar to Active Directory. The default value for this is 60 days. If there were no replication more than that time and resume replication in later time, it can have stale data. It is similar to lingering objects in AD. To protect from this, we can define value for MaxOfflineTimeInDays. if the number of days from last successful DFS replication is larger than MaxOfflineTimeInDays it will prevent the replication. 

We can review this value by running,

For /f %m IN ('dsquery server -o rdn') do @echo %m && @wmic /node:"%m" /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays


There is two ways to recover from this. First method is to increase the value of MaxOfflineTimeInDays. it can be done using,

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=120


It is recommended to run this on all domain controllers to maintain same config. 

If you not willing to change this value, it still can recover using non-authoritative restore. It will remove all conflicting values and take an updated copy. 

I have already written an article about non-authoritative restore of SYSVOL and it can be find in http://www.rebeladmin.com/2017/08/non-authoritative-authoritative-sysvol-restore-dfs-replication/ 

This is not only for SYSVOL replication. It is valid for DFS replication in general. 

Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

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.


If you have any question regarding the post feel free to email me at rebeladm@live.com

Password Replication in RODC

In last 2 posts I have explain benifits of the RODC and how we can deploy a RODC. if you haven't read them yet you can read them with following links,

Why Read-only domain controllers (RODC) ?
Step-by-Step guide to install Read-Only Domain Controller (RODC)

In RODC environment one of the great feature is the password replication. in RODC environment we can determine which passwords need to be cache in RODC and which accounts still need to be authenticate via writable domain controller. As example domain administrator accounts do not need to be cached on RODC. its always safe if it can be authaticate via routable DC for security purposes. so if a domain administrator login from a RODC enviornment, we can set system to forward the authtication request or service ticket to the writable domain controller.

Microsoft made this easy by introducing password replication policy (PRP) to RODC environment. by default system create domain-wide password replication policy two domain local security groups.

Allowed RODC Password Replication Group : Members of this group will allow to cache passwords in RODC. by default this group do not have any members.

Denied RODC Password Replication Group: Members of this group are deny to cache passwords in RODC. Some of the groups which are security critical are member of this group by default such as Administrators, Server Operators, Backup Operators, Account  Operators.

One of the biggest mistakes administrator do is only allow/deny user accounts. But computers it self also uses authatication and service tickets requests. so make sure you add computer accounts also in to these lists.

How to configure RODC password replication policy(PRP) ?

1) Login to a writable domain controller with domain administrator account
2) Open "Active Directory Users and Computers" snap in by Server Manager > Tools > Active Directory Users and Computers
3) Go to "Domain Controllers" OU


4) Click to select the RODC you need to configure PRP. Then right click and click on properties.


5) In the properties window click on "Password Replication Policy" tab


6) In there we can see the 2 groups i mentioned above.


7) We can add users to these groups. to add users/computers to those double click on the group. in here i will use "Allowed RODC Password Replication Group"


8) To add users/computers to group click on members tab and click on add.


9) Once users/computers added click on "OK" to apply changes.

Policy Usage Reports and Pre-Populate Credential Caching

Microsoft provided a easy method of reporting where we can check the status of password replication. in order to use this facility need to follow following steps.

1) Login to a writable domain controller with domain administrator account
2) Open "Active Directory Users and Computers" snap in by Server Manager > Tools > Active Directory Users and Computers
3) Go to "Domain Controllers" OU
4) Click to select the RODC you need to configure PRP. Then right click and click on properties.
5) In the properties window click on "Password Replication Policy" tab
6) Click on "Advanced" button


7) In here drop-down list there is 2 options listed

Accounts Whose Passwords Are Stored On This Read-Only Domain Controller: This option will list all the user accounts/computer accounts which are currently cached password on RODC.

Accounts That Have Been Authenticated To This Read-Only Domain Controller: This option will list the user accounts/computer accounts which were forwarded to writable domain controller for authentication and service tickets process. This is good place to identify the user accounts/ computer accounts which will still need to add to allow list for password caching.


In PRP lets assume we allowed USER A to cache his credentials in RODC. But it will not cache it right away. it will cache credential once user made first authentication request to the RODC. but microsoft given opertunity where we can pre-populate the caching. so when user login first time his password is already been cached on RODC.

In order to use this feature click on "Pre-Populate Passwords…" button in same advance window.


It will open up window where you can select the accounts you need. once its selected it will pop-up following information window. click on yes to accept the changes.
before do this make sure you have already allow that user/computer account in Allow list of password caching.


if you have any questions please feel free to contact me on rebeladm@live.com