none
Active Directory synchronization trouble with one user account

    Question

  • I have a domain with 7 sites (we'll call them A,B,C,D,E,F,G). I opened the properties for one of the users (we'll call her Jane) in site "A." I added her to a group. A few days later I was working with the DC in site "B" and noticed "Jane" was not a member of the group. I checked back on the DC in site "A" and "Jane" was still a member-- obviously the changes hadn't replicated. I checked the other DCs on the domain (Site "C" through "G") and none of them had "Jane" listed as a member of the group.

    .

    My topology is hub and spoke with "G" being the hub, and "A" through "F" all connecting to it. I checked all my domain replication health using DCDIAG and other methods and there were no errors. I then tested replication by adding a group to my own user account on the DC in site "G."  A few minutes later, the changes were on every DC at every site. Next, I tried adding a group to my account on the DC at site "A" where I first noticed the issue with "Jane." The changes replicated across the domain to all DCs.  However, the original changes made to "Jane" still had not replicated to any of the other DCs. Thinking this must be a problem with the individual AD user account, I applied some changes to her account at site "A". After a good deal of time, these changes have not replicated anywhere either.

    .

    In summary: any changes made to one specific user account on any DC will not replicate to any other DCs. All other changes made to user accounts and AD work fine. Meanwhile she can log in and all access and systems work fine for her account. Is it possible for a single object to have problems replicating like this? Where would I find errors about problems like this? I would really like to see if this is happening with other accounts that I don't know about yet (we have over 1000 users.)

    .

    Thanks!

    Monday, June 11, 2012 2:41 PM

Answers

  • I guess the account is corrupt & i had this issue in the past while using this account to promote one of the server as DC. We deleted that account & created new one. I really didn't go for the reason of the corruption that time since, it happened with the single account & never saw this issue again.Verify the semantic analysis & offline defrag of the AD database to see if it fixes the issue.


    Awinish Vishwakarma - MVP - Directory Services

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Monday, June 11, 2012 5:14 PM
  • Hi,

    I would like to confirm what is the current situation? Have you resolved the problem?

    If there is anything that we can do for you, please do not hesitate to let us know, and we will be happy to help.

    After read above postings, I also think issue is like USN rollback, other DC not aware USN change of that single account, since no replication error or event log can be find.

    But this is just guess and I can’t find related issue or KB in MS website.

    And as “Awinish” mentioned, maybe this account is corrupt, you can delete it and create a new one.

    Hope this helps!

    TechNet Subscriber Support

    If you areTechNet Subscription user and have any feedback on our support quality, please send your feedback here


    Lawrence

    TechNet Community Support

    Wednesday, June 13, 2012 3:10 AM

All replies

  • Hi,

    Try single object replication

    http://www.windowstricks.in/2009/10/single-object-replication.html

    also check the AD replication health

    http://www.windowstricks.in/2010/03/health-check-active-directory.html

    Regards,

    Ganesh

    www.windowstricks.in


    Regards www.windowstricks.in

    Monday, June 11, 2012 3:41 PM
  • Hello,

    that just a single object doesn't replicate i have not seen until now.

    Is the account only member of domain users? Which is the users PRIMARY GROUP under the Member of tab?


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Monday, June 11, 2012 3:57 PM
  • Did you try to modify the same object on the other DC & verified is it replicating or not. If its showing same behavior in all the DC then i doubt it can be account corruption. You might try to perform offline AD database defrag or semantic analysis.

    Try to force the replication using repadmin /syncall /APed, but be aware during biz hours running this cmd might show increase in network traffic.


    Awinish Vishwakarma - MVP - Directory Services

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Monday, June 11, 2012 4:01 PM
  • "Domain Users" is the primary group for the user, and it is listed that way on all DCs.

    The user account is a member of 10 groups total on one DC, but on the other 6 DCs it only shows 6 groups and the other 4 are missing. So It appears other groups she has been added to in the past haven't replicated either.

    Monday, June 11, 2012 4:25 PM
  • Thanks for the reply.

    .

    AD replication health is fine; I have already tested it many ways. I tried the command you outlined in the second link and it displayed 0% errors for all connections.

    .

    I did not try single object replication command you outlined in the first link. Even if it works, I would like to know what is causing this particular problem, and do not want to have to worry about running special commands every time I update a specific user account.

    Monday, June 11, 2012 4:33 PM
  • Possibly the uSNChanged attribute of the user was not updated by the system when the change was made on the DC.


    Richard Mueller - MVP Directory Services

    Monday, June 11, 2012 4:35 PM
  • Could this continually happen as more and more changes are made to her account? Nothing replicates for her account regardless of where I updated it. I can make a different change to her account on every DC in the domain and none of the changes from any of the DCs will replicate anywhere else.
    Monday, June 11, 2012 5:03 PM
  • Yes, I modified her account from all other DCs and none of the changes I make to the account ever leave the DC that I made them on.  Yet all other changes made to other accounts replicate fine.
    Monday, June 11, 2012 5:04 PM
  • I guess the account is corrupt & i had this issue in the past while using this account to promote one of the server as DC. We deleted that account & created new one. I really didn't go for the reason of the corruption that time since, it happened with the single account & never saw this issue again.Verify the semantic analysis & offline defrag of the AD database to see if it fixes the issue.


    Awinish Vishwakarma - MVP - Directory Services

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Monday, June 11, 2012 5:14 PM
  • I have never seen or heard of this problem, so my theory is strictly conjecture. However, the following VBScript program might give a clue. It outputs the highestCommittedUSN on a specified DC, the the value of the uSNChanged attribute for a specified user (on the same DC, as this attribute is not replicated). Then the script updates the user on the DC. Finally, the script retrieves the new highestCommittedUSN on the same DC, which should be greater than before by 1, and the new uSNChanged attribute of the user (on the same DC), which now should match the new highestCommittedUSN. If the user uSNChanged attribute does not change, then that might explain why no changes replicate. This VBScript program should be modified to specify a DC and a user in your domain:

    Option Explicit

    Dim objHiUSNBefore, objUserBefore, objUSNBefore
    Dim objHiUSNAfter, objUserAfter, objUSNAfter

    Set objHiUSNBefore = GetObject("LDAP://MyServer/RootDSE")
    Wscript.Echo "Higest USN on DC: " & objHiUSNBefore.Get("highestCommittedUSN")

    Set objUserBefore = GetObject("LDAP://MyServer/cn=Jim Smith,ou=West,dc=MyDomain,dc=com")
    Wscript.Echo "User: " & objUserBefore.sAMAccountName

    Set objUSNBefore = objUserBefore.uSNChanged
    Wscript.Echo "User uSNChanged on DC: " & CStr((objUSNBefore.HighPart * (2^32)) + objUSNBefore.LowPart)

    ' Make a change to this object on this DC:
    objUserBefore.description = "Test"
    objUserBefore.SetInfo

    Wscript.Echo "Modified the user on the DC"

    Set objHiUSNAfter = GetObject("LDAP://MyServer/RootDSE")
    Wscript.Echo "Higest USN on DC: " & objHiUSNAfter.Get("highestCommittedUSN")

    Set objUserAfter = GetObject("LDAP://MyServer/cn=Jim Smith,ou=West,dc=MyDomain,dc=com")
    Wscript.Echo "User: " & objUserAfter.sAMAccountName

    Set objUSNAfter = objUserAfter.uSNChanged
    Wscript.Echo "User uSNChanged on DC: " & CStr((objUSNAfter.HighPart * (2^32)) + objUSNAfter.LowPart)

    -----



    Richard Mueller - MVP Directory Services

    Monday, June 11, 2012 5:39 PM
  • Some notes on the script above, in case anyone else tries to use it in the future:

    LINE 9:

    My user names are written "Last, First" and this does not work (generates a dn syntax error). I had to rename the user to "Last First" removing the comma. Also, all CN and OU names need to be case sensitive.

    .

    Now here's the amusing part: I renamed the user (to remove the comma as mentioned above) on the DC in site "A" and ran the script. I collected the information. I modified the script to use the name of the DC in site "G" to see if it behaved similarly. The script ran and I collected the results. But the thing is, it *shouldn't* have been able to run, because I never renamed the user on the DC in site "G". I logged into that DC and sure enough, the name change had replicated... but the group membership hasn't! The script also modified the description of the user to read "TEST". This change has also replicated to all DCs across the domain.

    .

    My next step was to modify another field in the user's properties. I connected to the DC in site "A", opened the user's properties, clicked the "Telephones" tab, and entered "SITE A" into the NOTES field. I waited for a little while and those changes replicated as well. So it appears the ONLY information that isn't replicating is group membership.  Can anyone think of a reason for that?

    Monday, June 11, 2012 7:32 PM
  • If the common name of the user contains a comma, it needs to be escaped using the backslash escape character. For example:

    cn=Smith\, James,ou=West,dc=MyDomain,dc=com

    -----

    In fact, any of the following characters would need to be escaped (in VBScript):

    , \ # + < > ; " = /

    -----

    Also, the distinguished names of objects in AD are not case sensitive.


    Richard Mueller - MVP Directory Services

    Monday, June 11, 2012 8:00 PM
  • Thanks, sorry--- I probably made a typo and fixed it when I thought there was a case sensitive error. My mistake!

    Monday, June 11, 2012 8:17 PM
  • The best explanation for the memberOf attribute of the user not replicating is that the groups have a Restricted Groups policy applied to them. See this link:

    http://technet.microsoft.com/en-us/library/cc785631(v=WS.10).aspx

    This policy applies to the member (and memberOf) attributes of group objects, not users. But if you attempt to add the user to a group that has such a policy, the system will remove them. I forget how often the process runs to enforce this.


    Richard Mueller - MVP Directory Services

    Monday, June 11, 2012 10:01 PM
  • Hi,

    I would like to confirm what is the current situation? Have you resolved the problem?

    If there is anything that we can do for you, please do not hesitate to let us know, and we will be happy to help.

    After read above postings, I also think issue is like USN rollback, other DC not aware USN change of that single account, since no replication error or event log can be find.

    But this is just guess and I can’t find related issue or KB in MS website.

    And as “Awinish” mentioned, maybe this account is corrupt, you can delete it and create a new one.

    Hope this helps!

    TechNet Subscriber Support

    If you areTechNet Subscription user and have any feedback on our support quality, please send your feedback here


    Lawrence

    TechNet Community Support

    Wednesday, June 13, 2012 3:10 AM
  • Hi,

    I would like to confirm what is the current situation? Have you resolved the problem?

    If there is anything that we can do for you, please do not hesitate to let us know, and we will be happy to help.


    Lawrence

    TechNet Community Support

    Monday, June 18, 2012 8:08 AM
  • Hi,

    As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark
    it as ‘Answered’ as the previous steps should be helpful for many similar scenarios.

    If the issue still persists and you want to return to this question, please reply this post directly so we will be
    notified to follow it up. You can also choose to unmark the answer as you wish.

    In addition, we'd love to hear your feedback about the solution. By sharing your experience you can help other
    community members facing similar problems.

    Thanks!


    Lawrence

    TechNet Community Support

    Wednesday, June 20, 2012 3:23 AM
  • No, sorry, no resolution yet. 

    .

    The script posed by Richard was very helpful. However, the USN did increase by 1 as expected, and the user's description was changed to "Test."  The user description propagated to all DCs in the domain, though the group membership still remains a mystery. So this issue is not solved.

    .

    I have not recreated the user account, though I suspect this will probably fix the issue since all other users who have the same group membership in the same site replicate their membership fine. I'd like to find an actual cause rather than just deleting and recreating the user account, but I suppose in the event of corruption, there is no real solution to be had.

    .

    I agree to the post marked as "answer" but will follow-up here with anything else of note.

    Wednesday, June 20, 2012 10:50 AM