Solved

Very slow DFSR update to audit permissions on files

Posted on 2016-10-25
8
64 Views
Last Modified: 2016-10-27
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
0
Comment
Question by:SeeDk
  • 4
  • 4
8 Comments
 
LVL 36

Expert Comment

by:Mahesh
ID: 41859826
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
 

Author Comment

by:SeeDk
ID: 41860181
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
 
LVL 36

Expert Comment

by:Mahesh
ID: 41860280
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
Does Powershell have you tied up in knots?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 

Author Comment

by:SeeDk
ID: 41860292
No, the secpol.msc was only configured on one server. Will enabling on both make the replication faster?
0
 
LVL 36

Expert Comment

by:Mahesh
ID: 41860309
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
 

Author Comment

by:SeeDk
ID: 41860339
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
 
LVL 36

Accepted Solution

by:
Mahesh earned 500 total points
ID: 41860834
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
 

Author Comment

by:SeeDk
ID: 41862259
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

Featured Post

Are your AD admin tools letting you down?

Managing Active Directory can get complicated.  Often, the native tools for managing AD are just not up to the task.  The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Is your phone running out of space to hold pictures?  This article will show you quick tips on how to solve this problem.
Many businesses neglect disaster recovery and treat it as an after-thought. I can tell you first hand that data will be lost, hard drives die, servers will be hacked, and careless (or malicious) employees can ruin your data.
This tutorial will walk an individual through the steps necessary to configure their installation of BackupExec 2012 to use network shared disk space. Verify that the path to the shared storage is valid and that data can be written to that location:…
This tutorial will give a short introduction and overview of Backup Exec 2012 and how to navigate and perform basic functions. Click on the Backup Exec button in the upper left corner. From here, are global settings for the application such as conne…

821 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question