Sysvol Replication change in Windows 2008

Group Policy replication change

Before I start the SYSVOL replication changes in windows server 2008, I would like to explain how the GPO has been replicated in windows server 2003 and earlier versions

Also Read:  force sysvol replication on Windows 2008 and windows server 2012

Understanding SYSVOL/GPO replication

Group policy template (GPT) and group policy container (GPC) are two types of Group policy settings, It’s stored in two different locations and uses different replication technology to replicate the changes, however, both should be available up-to-date on the domain controller to function properly

Group policy templates are stored in SYSVOL, it’s a folder structure in SYSVOL share on a domain controller, if you create a new Group Policy it will create a Group policy templates folder on SYSVOL share for the new policy that contains the group policy setting related to this policy, GPT folder name would be a Globally Unique Identifier (GUID) of the GPO that you created, you can view all the GPT folders from the below Path (it’s a default GPT path)

C:WindowsSysvolSysvolDomainNamePolicies

Also Read: Difference between FRS and DFSR

Group Policy template (GPT) is replicated by SYSVOL through FRS, FRS uses state-based replication. As soon as there is a change to any file under the Sysvol folder structure, replication is triggered an entire file gets replicated

Group policy containers are stored in Active Directory, mostly all the GPO setting is stored in GPT (Group policy templates), GPC only have the reference information of the corresponding GPO, like GPT path, GUID of the GPO, version information, WMI filter information, and a list of components that have settings in the GPO, you can view the GPC from Active Directory Users and Computers (ADUC)

system policies

Also Read: Sysvol Interview Questions and Answers

Group Policy container (GPC) is replicated through Active Directory replication

Note: By default, the Group Policy Management Editor console (GPME) uses the PDC Emulator so that all administrators can work on the same domain controller if you want a different Domain controller you can change through Group Policy Management Console (GPMC)

File Replication Services (FRS)

I will try to explain step by step, let say you modify the Policy A from Server001 and how this change get replicated to Server002 (Server002 is a downstream replication partner for server001)

• Once you modify the Policy A from server001, the corresponding GPT folder on SYSVOL gets updated on the server001 (also updates the Group policy containers in Active Directory on server001)

• NTFS will change the USN journal according to the file and folder change.

• FRS monitors the USN journal for changes on the SYSVOL folder

• FRS updates the inbound log on server001, FRS not only updates the local changes on an inbound log, but also updates the inbound log for the changes from entire upstream replication partner (all inbound partners)

• FRS creates a file in the staging folder on server001 by using APIs (backup application programming interfaces) based on the change.

• This change has been updated on outbound log on server001 by FRS. And also send change notification to entire downstream replication partner about the change (all outbound partners)

• Server002 get the change notification from Server001 and store the change order in the inbound log, Server002 copies the staging file from Server001 to the staging folder on Server002. Server002 then update outbound log so other outbound partners can pick up the change

• Using Restore APIs, Server002 reconstructs the file and folder in the preinstall folder, and then FRS renames the file or folder into the replica tree

In the FRS replication process the entire changed file and folder get replicate to the source to the destination server

Also Read: How SYSVOL Replication Works

What is NTFS USN journal?

Logs all the changes to an NTFS volume, including file creations, deletions, and changes, Separate log on each NTFS volume and it has a size limit (Windows server 2003 SP2 & Windows server 2008 is 128 MB) if required you can increase the size up to 2 TB, however, MS Recommends increasing by 128 MB for every 100,000 files/folders

What happens when the NTFS USN change journal fills up?

If the USN journal log fills up then NTFS will overwrite the old entry’s, that’s why in some scenarios before the change gets updated, NTFS delete the entries in USN journal log, it’s called journal_wrap

USN journal wrap Error

An error that occurs when large numbers of files change so quickly that the USN journal must remove the oldest changes (before FRS has a chance to detect the changes) to stay within the specified size limit, to resolve this issue you have to perform a non-authoritative restore also called D2

Also Read: SYSVOL Folder location and Structure: About each folder under the SYSVOL share in Domain Controller

Morphed folder

Replication conflict will occur if identically named directories are created in different servers, to resolve this conflict FRS create a folder and this folder called morphed folder

Let’s say two identical directories are created in different replication members, FRS identifies the conflict during replication, and the receiving member protects the original copy of the folder and renames (morphs) the later inbound copy of the folder. The morphed folder names have a suffix of “_NTFRS_xxxxxxxx,” where “xxxxxxxx” represents eight random hexadecimal digits.

Version vector join (vvjoin)

Till now we are discussing about the SYSVOL replication, how the SYSVOL replication works for the newly added replication partner, newly added replication member doesn’t have any updates, and it should build the folder structure from the beginning, this process is called vvjoin, in which a downstream partner joins with an upstream partner for the first time.

Vvjoin is a CPU-intensive operation that can affect the performance of the server and increase the replication traffic

Distributed File System (DFS)

Now we are coming to the point, how the SYSVOL replicating using DFS and how it’s been improved to provide better replication performance, to use this feature you should have Windows Server 2008 domain functional level that means all the domain controller has to be Windows Server 2008

SYSVOL replication using DFS is called DFS-Replicated SYSVOL (DFSR)

DFSR is a multi-master replication engine and changes that occur on one of the replication members are then replicated to all of the other servers in the replication group

DFSR also monitors the NTFS for the update sequence number (USN) journal to detects changes on the volume, and then DFSR replicate the changes only after the file closed

And before sending or receiving a file, DFSR uses a staging folder to stage the file

If any changes in SYSVOL share, FRS replicate the entire file unlike the DFSR, DFSR replicates only the changes blocks and not the entire file, sounds like an attribute level Active Directory replication, it compares the source and destination file using remote differential compression (RDC), it reduce the SYSVOL replication traffic

Other improvements are… (Difference between DFRS and FRS)

• DFSR and Journal Wraps, DFSR also monitors the NTFS change journal, but DFSR always heals itself hence no Journal Wrap error

• Morphed files and folders automatically took care of

• FRS silently fails if the volume SYSVOL resides on < 1GB of free space

• Copies the changes on files and folder, not entire files and folder

• Uses Version Vector tables to confirm the changes, also to resolve the conflicts

• Support read-only replication on particular members in which users cannot add or change files

• You can also make the changes to the SYSVOL folder of an RODC

• DFSR does not require the version vector join (vvjoin) operation

My previous article related to SYSVOL

Understand the sysvol folder structure

How to Force sysvol replication in AD