Tag Archives: sysvol

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.

Non-Authoritative and Authoritative SYSVOL Restore (DFS Replication)

Healthy SYSVOL replication is key for every active directory infrastructure. when there is SYSVOL replication issues you may notice,

1. Users and systems are not applying their group policy settings properly. 

2. New group policies not applying to certain users and systems. 

3. Group policy object counts is different between domain controllers (inside SYSVOL folders)

4. Log on scripts are not processing correctly

Also, same time if you look in to event viewer you may able to find events such as,

Event Id

Event Description

2213

The DFS Replication service stopped replication on volume C:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication.

Recovery Steps

1. Back up the files in all replicated folders on the volume. Failure to do so may result in data loss due to unexpected conflict resolution during the recovery of the replicated folders.

2. To resume the replication for this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig class. For example, from an elevated command prompt, type the following command:

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid=”xxxxxxxx″ call ResumeReplication

5002

The DFS Replication service encountered an error communicating with partner <FQDN> for replication group Domain System Volume.

5008

The DFS Replication service failed to communicate with partner <FQDN> for replication group Home-Replication. This error can occur if the host is unreachable, or if the DFS Replication service is not running on the server.

5014

The DFS Replication service is stopping communication with partner <FQDN> for replication group Domain System Volume due to an error. The service will retry the connection periodically.

Some of these errors can be fixed with simple server reboot or running commands describe in the error ( ex – event 2213 description) but if its keep continuing we need to do Non-Authoritative or Authoritative SYSVOL restore.

Non-Authoritative Restore 

If it’s only one or few domain controller (less than 50%) which have replication issues in a given time, we can issue a non-authoritative replication. In that scenario, system will replicate the SYSVOL from the PDC. 

Authoritative Restore

If more than 50% of domain controllers have SYSVOL replication issues, it possible that entire SYSVOL got corrupted. In such scenario, we need to go for Authoritative Restore. In this process, first we need to restore SYSVOL from backup to PDC and then replicate over or force all the domain controllers to update their SYSVOL copy from the copy in PDC. 

SYSVOL can replicate using FRS too. This is deprecated after windows server 2008, but if you migrated from older Active Directory environment you may still have FRS for SYSVOL replication. It also supports for Non-Authoritative and Authoritative restore but in this demo, I am going to talk only about SYSVOL with DFS replication. 

Non-Authoritative DFS Replication 

In order to perform a non-authoritative replication,

1) Backup the existing SYSVOL – This can be done by copying the SYSVOL folder from the domain controller which have DFS replication issues in to a secure location. 

2) Log in to Domain Controller as Domain Admin/Enterprise Admin

3) Launch ADSIEDIT.MSC tool and connect to Default Naming Context

sys1

4) Brows to DC=domain,DC=local > OU=Domain Controllers > CN=(DC NAME) > CN=DFSR-LocalSettings > Domain System Volume > SYSVOL Subscription

5) Change value of attribute msDFSR-Enabled = FALSE

sys2

6) Force the AD replication using,

repadmin /syncall /AdP

7) Run following to install the DFS management tools using (unless this is already installed), 

Add-WindowsFeature RSAT-DFS-Mgmt-Con

8) Run following command to update the DFRS global state,

dfsrdiag PollAD

9) Search for the event 4114 to confirm SYSVOL replication is disabled. 

Get-EventLog -Log "DFS Replication" | where {$_.eventID -eq 4114} | fl

10) Change the attribute value back to msDFSR-Enabled=TRUE (step 5)

11) Force the AD replication as in step 6

12) Update DFRS global state running command in step 8

13) Search for events 4614 and 4604 to confirm successful non-authoritative synchronization. 

sys3

All these commands should run from domain controllers set as non-authoritative. 

Authoritative DFS Replication 

In order to perform to initiate authoritative DFS Replication,

1) Log in to PDC FSMO role holder as Domain Administrator or Enterprise Administrator

2) Stop DFS Replication Service (This is recommended to do in all the Domain Controllers)

3) Launch ADSIEDIT.MSC tool and connect to Default Naming Context

4) Brows to DC=domain,DC=local > OU=Domain Controllers > CN=(DC NAME) > CN=DFSR-LocalSettings > Domain System Volume > SYSVOL Subscription

5) Update the given attributes values as following, 

msDFSR-Enabled=FALSE

msDFSR-options=1

sys4

6) Modify following attribute on ALL other domain controller.

msDFSR-Enabled=FALSE

7) Force the AD replication using,

repadmin /syncall /AdP

8) Start DFS replication service in PDC

9) Search for the event 4114 to verify SYSVOL replication is disabled.

10) Change following value which were set on the step 5,

msDFSR-Enabled=TRUE

11) Force the AD replication using,

repadmin /syncall /AdP

12) Run following command to update the DFRS global state,

dfsrdiag PollAD

13) Search for the event 4602 and verify the successful SYSVOL replication. 

14) Start DFS service on all other Domain Controllers

15) Search for the event 4114 to verify SYSVOL replication is disabled.

16) Change following value which were set on the step6. This need to be done on ALL domain controllers. 

msDFSR-Enabled=TRUE

17) Run following command to update the DFRS global state,

dfsrdiag PollAD

18) Search for events 4614 and 4604 to confirm successful authoritative synchronization. 

Please note you do not need to run Authoritative DFS Replication for every DFS replication issue. It should be the last option.

Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com 

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