Category: GPO

replication changes in sysvol 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
Understanding SYSVOL/GPO replication

Group policy template (GPT) and group policy container (GPC) are two types of Group policy settings, Its stored in two different locations and uses different replication technology to replicate the changes, however both should be available up-to-date on 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 contain the group policy setting related to this policy, GPT folder name would be 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)


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 and entire file get replicated

Group policy containers are stored in Active Directory, mostly all the GPO setting are 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)


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 inbound log, also updates the inbound log for the changes from entire upstream replication partner (all inbound partners)
  • FRS creates a file in 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 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 FRS replication process the entire changed file and folder get replicate to source to destination server

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 require 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 be overwrite the old entry’s, that’s why in some scenarios before the change get 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

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 multimaster replication engine and changes that occur on one of the replication member 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 a attribute level Active Directory replication, it compare 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 taken 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 a 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


Loopback processing in GPO

What is loopback processing? 

Group Policy loopback is a computer configuration setting that enables different Group Policy user settings to apply based upon the computer from which logon occurs. 

Breaking this down a little more:

  1. It is a computer configuration setting. (Remember this for later)
  2. When enabled, user settings from GPOs applied to the computer apply to the logged on user.
  3. Loopback processing changes the list of applicable GPOs and the order in which they apply to a user. 

 Why would I use loopback processing?

Administrators use loopback processing in kiosk, lab, and Terminal Server environments to provide a consistent user experience across all computers regardless of the GPOs linked to user’s OU. 

Our recommendation for loopback is similar to our recommendations for WMI filters, Block Inheritance and policy Enforcement; use them sparingly.  All of these configuration options modify the default processing of policy and thus make your environment more complex to troubleshoot and maintain, whenever possible, keep your designs as simple as possible.

 How to configure loopback processing

The loopback setting is located under Computer Configuration/Administrative Templates/System/Group Policy in the Group Policy Management Editor (GPME). 

 Use the policy setting Configure user Group Policy loopback processing mode to configure loopback in Windows 8 and Windows Server 2012Earlier versions of Windows have the same policy setting under the name User Group Policy loopback processing mode. 


 When you enable loopback processing, you also have to select the desired mode.  There are two modes for loopback processing:  Merge or Replace.


 Loopback Merge vs. Replace

Prior to the start of user policy processing, the Group Policy engine checks to see if loopback is enabled and, if so, in which mode.

Loopback Merge

During loopback processing in merge mode, user GPOs process first (exactly as they do during normal policy processing), but with an additional step.  Following normal user policy processing the Group Policy engine applies user settings from GPOs linked to the computer’s OU.  The result– the user receives all user settings from GPOs applied to the user and all user settings from GPOs applied to the computer. The user settings from the computer’s GPOs win any conflicts since they apply last.

 To illustrate loopback merge processing and conflict resolution, let’s use a simple chart.  The chart shows us the “winning” configuration in each of three scenarios:

  1. The same user policy setting is configured in GPOs linked to the user and the computer
  2. The user policy setting is only configured in a GPO linked to the user’s OU
  3. The user policy setting is only configured in a GPO linked to the computer’s OU


 Now, going back to our original example, loopback processing in Merge mode applies user settings from GPOs linked to the user’s OU followed by user settings from GPOs linked to the computer’s OU.


 GPOs for the user in OU ”E” apply in the following order (the first part is identical to normal user policy processing from our original example):

Local Group Policy

  1. Group Policy objects linked to the Site
  2. Group Policy objects linked to the Domain
  3. Group Policy objects linked to OU “A”
  4. Group Policy objects linked to OU “B”
  5. Group Policy objects linked to OU “E”
  6. Group Policy objects linked to the Site
  7. Group Policy objects linked to the Domain
  8. Group Policy objects linked to OU “A”
  9. Group Policy objects linked to OU “C”
  10. Group Policy objects linked to OU “G”

 Loopback Replace

 Loopback replace is much easier. During loopback processing in replace mode, the user settings applied to the computer “replace” those applied to the user.  In actuality, the Group Policy service skips the GPOs linked to the user’s OU. Group Policy effectively processes as if user object was in the OU of the computer rather than its current OU. 

 The chart for loopback processing in replace mode shows that settings “1” and “2” do not apply since all user settings linked to the user’s OU are skipped when loopback is configured in replace mode.


 Returning to our example of the user in the “E” OU, loopback processing in replace mode skips normal user policy processing and only applies user settings from GPOs linked to the computer.


 The resulting processing order is: 

  1. Local Group Policy
  2. Group Policy objects linked to the Site
  3. Group Policy objects linked to the Domain
  4. Group Policy objects linked to OU “A”
  5. Group Policy objects linked to OU “C”
  6. Group Policy objects linked to OU “G”


  1. User Group Policy loopback processing is a computer configuration setting.
    • Loopback processing is not specific to the GPO in which it is configured. If we think back to what an Administrative Template policy is, we know it is just configuring a registry value.  In the case of the loopback policy processing setting, once this registry setting is configured, the order and scope of user group policy processing for all users logging on to the computer is modified per the mode chosen: Merge or Replace.
  2. Merge mode applies GPOs linked to the user object first, followed by GPOs with user settings linked to the computer object. 
    • The order of processing determines the precedence. GPOs with users settings linked to the computer object apply last and therefore have a higher precedence than those linked to the user object.
    • Use merge mode in scenarios where you need users to receive the settings they normally receive, but you want to customize or make changes to those settings when they logon to specific computers.
  3. Replace mode completely skips Group Policy objects linked in the path of the user and only applies user settings in GPOs linked in the path of the computer.  Use replace mode when you need to disregard all GPOs that are linked in the path of the user object.

Those are the basics of user group policy loopback processing. For more updates and troubleshooting series , please refer