sync

Force synchronization for DFSR-replicated SYSVOL

Posted on April 22, 2020 by Active Directory Windows

One of my clients had a problem with processing GPO on client computers. Different computers applied different settings from the same GPO but from different domain controllers. All tests related to replication was successful, all GPOs are applied, but replication between domain controllers was a problem, and because of that most clients had a different GPO configuration.

I had a similar problem with a newly promoted domain controller which I previously blogged about here.

Scenarios where this problem typically occurs:

  • Replication was moved  from FRS to DFSR
  • Demoting an old domain controller in the environment
  • When there is a problem with the DFS replication of the SYSVOL folder

To solve this problem, I had to manually perform an authoritative synchronization between the domain controllers.

I am including steps for authoritative and non-authoritative synchronization, but before we get started we need to see the state of the replication.

Steps:

  1. Find the state of the replication state. Typically the problem DCs will be at 0 or 2. The goal is to get to state 4.
  2. Get to State 2
  3. Get to State 4

Find the state of the replication of all DCs

The states should translate as below

0 = Uninitialized
1 = Initialized
2 = Initial Sync
3 = Auto Recovery
4 = Normal
5 = In Error

Non-authoritative synchronization of DFSR-replicated SYSVOL

  • Stop the DFS Replication service ( net stop dfsr).
  • In the ADSIEDIT.MSC tool modify the following distinguished name (DN) value and attribute on each of the domain controllers that you want to make non-authoritative:
    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
    msDFSR-Enabled=FALSE
  • Force Active Directory replication throughout the domain  ( repadmin /syncall primary_dc_name /APed )
  • Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:
    DFSRDIAG POLLAD 
  • You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated (Open up event viewer and navigate to Applications and Services Logs -> DFS Replication).
  • On the same DN from Step 1, set:
    msDFSR-Enabled=TRUE
  • Force Active Directory replication throughout the domain ( repadmin /syncall primary_dc_name /APed).
  • Start the DFS Replication service ( net start dfsr).
  • Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:
  • You will see Event ID 4614 and 4604 in the DFSR event log indicating SYSVOL has been initialized. That domain controller has now done non-authoritative sync of SYSVOL.
  • Run Wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,stat and make sure the state is at 4. If it is at 2, it may take some time to reach state 4. Wait a few minutes and try again until all DCs are at state 4.

Authoritative synchronization of DFSR-replicated SYSVOL

  1. Find the PDC Emulator (Elevated Command Prompt: netdom query fsmo ) – which is usually the most up to date for SYSVOL contents. Or the server holding all the policies and scripts. Consider this the primary server.
  2. Stop the DFS Replication service ( net stop dfsr) on the primary server.
  3. On the primary server, In the ADSIEDIT.MSC tool, modify the following DN and two attributes to make authoritative:
    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
    msDFSR-Enabled=FALSE
    msDFSR-options=1
  4. Modify the following DN and single attribute on all other domain controllers in that domain:
    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>
    msDFSR-Enabled=FALSE
  5. Force Active Directory replication throughout the domain and validate its success on all DCs ( repadmin /syncall primary_dc_name /APed). Probably need to run the same command 3-4 times.
  6. Start the DFSR service set as authoritative ( net start dfsr) on the primary DC.
  7. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated (Open up event viewer and navigate to Applications and Services Logs -> DFS Replication).
  8. On the same DN from Step 1, set:
    msDFSR-Enabled=TRUE
  9. Force Active Directory replication throughout the domain and validate its success on all DCs ( repadmin /syncall primary_dc_name /APed ). Probably need to run the same command 3-4 times.
  10. Run the following command from an elevated command prompt on the same server that you set as authoritative (primary server):
    DFSRDIAG POLLAD 
  11. Wait a few minutes you will see Event ID 4602 in the DFSR event log (Open up event viewer and navigate to Applications and Services Logs -> DFS Replication) indicating SYSVOL has been initialized. That domain controller has now done an authoritative sync of SYSVOL.
  12. Start the DFSR service on the other non-authoritative DCs ( net start dfsr). You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated on each of them.
  13. Modify the following DN and single attribute on all other domain controllers in that domain:
    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>
    msDFSR-Enabled=TRUE
  14. Run the following command from an elevated command prompt on all non-authoritative DCs (i.e. all but the formerly authoritative one):
  15. Verify you see Event ID 2002 and 4602 on all other domain controllers.
  16. Run Wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,stat and make sure the state is at 4. If it is at 2, it may take some time to reach state 4. Wait a few minutes and try again until all DCs are at state 4.
If setting the authoritative flag on one DC, you must non-authoritatively synchronize all other DCs in the domain. Otherwise, you will see conflicts on DCs, originating from any DCs where you did not set auth/non-auth and restarted the DFSR service. For example, if all logon scripts were accidentally deleted and a manual copy of them was placed back on the PDC Emulator role holder, making that server authoritative and all other servers non-authoritative would guarantee success and prevent conflicts. If making any DC authoritative, the PDC Emulator as authoritative is preferable, since its SYSVOL contents are usually most up to date. The use of the authoritative flag is only necessary if you need to force synchronization of all DCs. If only repairing one DC, simply make it non-authoritative and do not touch other servers. This article is designed with a 2-DC environment in mind, for simplicity of description. If you had more than one affected DC, expand the steps to includeALL of those as well. It also assumes you have the ability to restore data that was deleted, overwritten, damaged, etc. previously if this is a disaster recovery scenario on all DCs in the domain.

After these actions, all problems with GPO processing and SYSVOL replication disappeared. 🙂

Going back to the basics….moving out of Amazon Drive!

Posted on December 27, 2017 by Linux Mac Windows

As of June 8, 2017, it was announced that when when users try to sign up for Amazon Drive they will not be able to select an unlimited cloud storage option. Instead they can choose either 100 GB for $11.99 per year, or 1 TB for $59.99, with up to 30 TB available for an additional $59.99 per TB. (The prior pricing was unlimited everything for $59.99.) My data came up to about 5TB, which according to their new pricing structure would cost me $300+ (Data is always growing!!).

That is quite costly for just 5TB of storage when I can buy two 8TB drives and have it locally in a RAID configuration or a mirrored set. I shopped around with other popular cloud providers but each and every one of them have some sort of limitations. I decided to purchase two 8TB drives and maintain it locally. 

I found very little help on Google when searching for ways to move out of Amazon Drive with ease. I found a lot of cool little utilities but none were able to do a clean and consistent sync copy/move. It most cases the application would either hang, or incomplete the job.

I tried a lot of tools to get a synced local copy but the process seemed harder and harder. I tried a lot of freeware and shareware utilities as well as those offered by Amazon. I am just listing my personal experiences here so that I can save time for those whole have a similar situation.

Tools I tried:

Amazon Drive Desktop Sync

  •  Horrible transfer speeds +
  • Buggy Software
  • Startup & Resuming files would delay download significantly.

SymLink (MacOS/ Linux)

  • Somewhat works but metadata is lost.

NetDrive

  • Mounts the Amazon Cloud Drive and a Network Drive
  • Constant disconnects + too many app updates
  • Application hangs with large files
  • Service needed to be restarted multiple times to connect with Amazon

Cloudberry Explorer

  • Quirks around Admin Mode.
  • Ghostfiles (0kb) leftover.
  • Acts like an FTP Client but missing a lot features

rClone (Banned)

AllwaySync

  • The Oneway transfer feature is nice but it was taking a long time between files
  • This might have worked if my filebase was a whole lot smaller but failed for larger jobs.

Expandrive

  • Similar to NetDrive but a whole lot stable, but would fail on larger files.

Odrive

  • Horrible interface. Didn’t work most of time.

& a few more applications…. that didn’t work out!

Syncovery

Syncovery was the  winner in my case. This tools was the best in speed and got me an exact copy out from Amazon Cloud drive. It supports resuming! It is available on all platforms. It has a nice layout and can run as a scheduled job!

It took Syncovery literally 2 days to get all of my data downloaded. I was simply amazed at how efficient this tool was working. It maintained a consistent speed. Didn’t lose any metadeta. I ran a file check and all of them checked out 100%.

The trial version worked in my case and I am considering getting the Pro version. It excelled where all other failed. It wasn’t a resource hog and did the job in the first go! Thank you Syncovery!

 

Couple of lessons learned in getting success with all my data downloaded.

  1. Metadata is important especially when dealing with older files. Try not of lose it, as once it is lost there is no going back.
  2. Don’t copy to the same path as the original. Use an external drive and copy it there.
  3. If dealing with a lot of smaller files break them into chunks or batches to avoid application hang
  4. Apart from Syncovery, there were some utilities that might delete the files from Amazon and put them in Trash. Make sure you look there if you notice files missing file. It is most certainly there. I personally didn’t have this issue but some people have reported this with other utilities.
  5. Share your experiences to help out others.

Conclusion

I am in no way promoting a product from Syncovery, but based on my personal experience I found it to be the easiest to move the amount of data I had from Amazon down to my local server.  I am going to sway away from the public cloud space for a while at-least for my personal stuff. Based on the pricing, limitation of file size and types, and amount of data I have, I am still searching for good cloud store. I am evaluating ownCloud for now. If I ever goto a public cloud storage solution again, I am going to try my exit exercise/ strategy prior to bulk upload.

Another strategy people are recommending is hosting all the files in a VM on AWS/ Google/ Azure. My issue there is access cost. If my access is within the VM I am good, but any data I am pulling or accessing out of the VM – I am paying for it!

Mo Wasay
My name is Mo Wasay. I work with a variety of technologies and engage with the community and customers around the world. I am located in Dallas, Texas, U.S.A. I like to share my knowledge and experiences and help others who come across similar situations. My current focus is Microsoft Azure, Azure Stack and Windows Server.
View Mo Wasay, MSCS, MCITP, MCSE, VCP, ISM, CIS's profile on LinkedIn