Slow DFSR replication in one direction


  • Hi

    I am having this replication issue with DFSR. I have two windows server 2008 r2 with DFSR setup. Replication on one direction is instant but takes almost 10mins the other way round. When I create a new file in Server A, it gets replicated instantly to Server B but when I create a new file in server B it takes a while for the file to replicate to Server A.

    I came across the dfsr log file in Server A, at first I didn't understand the sequence of events logged in the log file but after closely looking at the time I created the file on Server B, I saw the following log:

    20120203 01:07:54.860 10696 IINC   281 IInConnectionCreditManager::GetCredits [CREDIT] No connection credits available, queuing request. totalConnectionCreditsGranted:122 totalGlobalCreditsGranted:122 csId:{54C032RB-EA96-4867-90ED-168C39D72998} csName:england connId:{GB30B865-89DE-4B2A-8C0D-1BBBB35D77DD} sessionTaskPtr:0000000002D63770

    Also when I ran the command 'dfsrdiag replicationstate' on Server A and got the following report:

    Total number of inbound updates scheduled: 114
    Active inbound connections: 1
    Updates received: 114
    Active outbound connections: 0
    Updates sent out: 0

    Operation Succeeded

    - Is there limitation to the number of Credit handed out for each requested update?

    - Is there a way I can clear the files not yet replicated hence freeing the credits for other replication?

    - Is this issue related to something else?


    Thursday, February 02, 2012 7:13 PM


  • Hello Isaac2k2,


    The best information I found about the ConnectionCredits was:


    During initial DFSR replication of a lot of data, I often see debug log messages like:

    20111028 17:06:30.308 9092 CRED 105 CreditManager::GetCredits [CREDIT] No update credits available. Suspending Task:00000000010D3850 listSize:1 this:00000000010D3898




    20111028 17:06:30.308 9092 IINC 281 IInConnectionCreditManager::GetCredits [CREDIT] No connection credits available, queuing request.totalConnectionCreditsGranted:98 totalGlobalCreditsGranted:98 csId:{6A576AEE-561E-8F93-8C99-048D2348D524} csName:GooconnId:{B34747C-4142-478F-96AF-D2121E732B16} sessionTaskPtr:000000000B4D5040


    And just what are DFSR “Credits?” Does this amount just control how many files can be replicated to a partner before another request has to be made? Is it a set amount for a specific amount of time per server?


    Not how many files, per se - how many updates. A credit maps to a "change" - create, modify, delete. All the Credit Manager code does is allow an upstream server to ration out how many updates each downstream server can request in a batch. Once that pool is used up, the downstream can ask again. It ensures that one server doesn't get to replicate all the time and other servers never replicate - except in Win2003/2008, this still happened. Because we suck. In Win2008 R2, the credit manager now correctly puts you to the back of the queue if you just showed up asking for more credits, and gives other servers a chance. As an update replicates, a credit is "given back" until your list is exhausted. It has nothing to do with time, just work.

    "No update credits available" is normal and expected if you are replicating a bung-load of updates. And in initial sync, you are.


    My 2 cents:

    Which is the primary server (holding most of access)? Can be that the primary server is loaded with many replication updates and you need to wait a while. I have already seen this behavior, some changes take more time to replicate mostly when there are many `small` changes, like access rights or a folder with thousands of files. 


    Thank you,

    F. Schubert
    System Administrator

    MCP | Microsoft Certified Professional
    MCTS 70-640 | Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration
    MCTS 70-642 | Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration
    • Marked as answer by Bruce-Liu Tuesday, February 28, 2012 10:02 AM
    Monday, February 06, 2012 6:15 PM