Tag Archives: Replication

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

cf1

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

cf2

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.

dfrs1

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

dfrs2

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

dfrs3

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

dfrs4

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

dfrs5

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

dfrs6

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

dfrs7

This completes the migration process and to confirm the SYSVOL share, type net share command and enter.

dfrs8

Also make sure in each domain controller FRS service is stopped and disabled.

dfrs9

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

prp1

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

prp2

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

prp3

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

prp4

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"

prp5

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

prp6

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

prp7

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.

prp8

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.

prp9

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.

prp10

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