Very slow DFSR update to audit permissions on files

DFSR is set up between two 2008R2 file servers.
It has been working properly and replications occur instantly during most types of file edits (edit, delete, create, etc.)

I recently set up auditing on one of the file servers and as a part of that have added an entry under the Advanced Security Auditing tab for the replicated folder.

I see the backlog shoot up as a result, which makes sense since these security changes need to be replicated to the other server.
However, it is taking a very long time to replicate.
For reference, in the last 10 minutes the backlog changed from 225,179 to 225,178.
It was actually higher than 225,179 for a moment as new entries were entered into the backlog from users working on files.


The size of the folder where these changes were made is:

475GB
175,000 files, 16,000 folders

Is it normal for a permissions change to take this long or is there something I should check with the DFSR.
These are what I already checked:

Increased staging area size, I am not receiving high watermark errors
No permission errors in the logs
Schedule is set to 24x7
Bandwidth is set to full
RDC is enabled
SeeDkAsked:
Who is Participating?
 
MaheshConnect With a Mentor ArchitectCommented:
You must enable auditing on all DFSR replication member servers through secpol.msc before you enable auditing entries on folders
OR
you may put all DFSR member servers in one OU and apply auditing GPO so that it will be applied on all servers
That is mandatory thing to do per server and didn't replicate

Auditing entries on folder should be done on anyone server only so that he would be the only source for replicating changes and other servers would act as a target

When you made any changes on one server, changes in every file and folder permissions get written in dfsr database in the form of hash values, then it will get replicated to target, this is where its operation getting slow if changes in structure / permissions are major.
Sometimes if there are NTFS permissions conflicts, access denied due to wrong ownership, at that time also DFSR replication take much longer than required / usual and correcting permissions would resolve the issue
0
 
MaheshArchitectCommented:
have you enabled auditing on both servers or on a single server?

how your normal file folder replication is happening?

If its happening correctly, you should wait for backlogs to get reduced over the period of time

It need amount of time to replicate changes
0
 
SeeDkAuthor Commented:
1. Auditing was enabled on only one server. This is the one replicating the changes to the other server.

2. It is happening with no issues. The backlog has always been around 0 during normal operations. I have manually tested by adding a file on one server and seeing instantly replicate on the other before making the auditing change.

Is this a normal amount of time for the changes to take? I made the auditing change on Monday afternoon. It is still working through those changes on the second server, backlog is at 178,717 now.
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
MaheshArchitectCommented:
I am talking about audit security policy which you must need to be enabled on both servers

Are you saying that audit security policy is enabled through group policy on both servers?
If not, you have to enable it on both servers manually through secpol.msc

Wrt enabling auditing on folders, that can be done on single server and eventually it will get replicated to other server
0
 
SeeDkAuthor Commented:
No, the secpol.msc was only configured on one server. Will enabling on both make the replication faster?
0
 
MaheshArchitectCommented:
That should have been enabled before you set auditing entries on folders,

Currently, it might searching for basic audit setting on other server and unable to find it.

At this point of time, your backlog is getting decreased, it means its working but taking more time than normal, Now enable auditing on other server and check if it works for you, you need to wait, because your file count is big and DFSR has to change NTFS security descriptor on each file which take considerable amount of time
0
 
SeeDkAuthor Commented:
Thank you, I have changed secpol settings on the other server to match the changes made on the first server.
Will check in a few hours to see if the DFSR speed has improved.

I actually still have to make some more auditing change but have been holding back because of the backlog.
Going forward, do you think it would be better to make the same wrt enable audit changes on both servers at the same time? Or would this just cause a backlog on both ends?
0
 
SeeDkAuthor Commented:
Ok, thanks Mahesh. The backlog is now at 67,775 so it seems to have sped up a bit. Will still take long but my main concern was whether this is expected behavior or there was some wrong configuration.

I will let the backlog clear and then make the remaining audit changes on only one server per your recommendation.
0
All Courses

From novice to tech pro — start learning today.