-
标题
"Common Error 0xe1000010. Attribute uSNChanged not found in object" appears in the Directory Synchronization Log (DSA.log) file, while performing a Directory Synchronization with Quest Migration Manager -
说明
"Common Error 0xe1000010. Attribute uSNChanged not found in object" appears in the Directory Synchronization Log (DSA.log) file, while performing a Directory Synchronization with Quest Migration Manager -
原因
This is an Alternative to KB36160
If the resolution in the above article does not resolve the issue or upon checking the user attributes for USNchanged for suspected users is actually populated, then there are several other steps to try.
-
解决办法
The DSA log will report the users it has enumerated in the log and show the values that we are requesting:
Attributes to be requested: whenChanged uSNChanged userWorkstations userPrincipalName userParameters UserAccountControl unicodePwd targetAddress supplementalCredentials sAMAccountName profilePath primaryGroupID parentGUID objectSid objectGUID objectClass nTSecurityDescriptor ntPwdHistory Name msExchUnmergedAttsPt msExchSafeSendersHash msExchPoliciesIncluded msExchOmaAdminWirelessEnable msExchMasterAccountSid msExchMailboxSecurityDescriptor msExchMailboxGuid msExchBlockedSendersHash mDBStorageQuota mDBOverQuotaLimit mDBOverHardQuotaLimit logonHours lmPwdHistory homeMDB homeDrive homeDirectory groupType extensionAttribute6 extensionAttribute3 extensionAttribute12 description deletedItemFlags dBCSPwd comment
These attributes are then written to the log showing what the attribute value is
object 0
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> object's AdsPath: LDAP://MCKDC3SRV.customerdomain.ie/CN=Barry\, Amanda,OU=Administration,OU=Domain Users,DC=customerdomain,DC=ie
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> objectClass = top#person#organizationalPerson#user
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> whenChanged = 20160324142652.0Z
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> uSNChanged = 151665930
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> extensionAttribute10 = N
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> objectGUID = 9284DBAC7B0CF24880F03631EDD26056
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> userAccountControl = 512
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> accountExpires = 9223372036854775807
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> sAMAccountName = ambarry
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> objectCategory = <GUID=db99462107e07a4f84912ec4625b241d>;CN=Person,CN=Schema,CN=Configuration,DC=customerdomain,DC=ie...
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> distinguishedName = CN=Barry\, Amanda,OU=Administration,OU=Domain Users,DC=customerdomain,DC=ie...
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> objectSid = 010500000000000515000000B8822F85E1194FE96C5AE45066050000
03/24/16 10:31:19 (GMT-05:00) Source JobID:0 -> ADsPath = LDAP://MCKDC3SRV.customerdomain.ie/CN=Barry\, Amanda,OU=Administration,OU=Domain Users,DC=customerdomain,DC=ie...If the DSA Agent finds a user that it thinks does not have one of these attributes it does not error but omits the entire attribute entry. When looking in the log to find a problem user that the "Attribute uSNChanged not found in object" is talking about, we have to search through the DSA log for someone that does not have the USNchanged attribute line populated.
In a customer environment this was the case and the only way to rectify the issue was to remove the problem user from scope. In their case we found one user without the USNchanged attribute line and removed them from sync, only to find that another user was picked up by the DSA after the correction. That user was also removed and the DSA recovered and started to process users after a full resync. In this particular case after inspection, the OU the users were in did not allow the service account to have Full access rights.