Profile import from AD fails. You are able to successfully create Synchronization Connection, but when trying to run Full or Incremental Profile Synchronization, you are greeted with errors in Application Event Log such as this:
Log Name: Application
Source: FIMSynchronizationService
Date: 17.2.2010 9:23:03
Event ID: 6050
Task Category: Management Agent Run Profile
Level: Error
Keywords: Classic
User: N/A
Computer: wv002578.eu.tieto.com
Description:
The management agent "MOSSAD-[SYNCHRONIZATION CONNECTION NAME]
Additional Information
Discovery Errors : "0"
Synchronization Errors : "0"
Metaverse Retry Errors : "0"
Export Errors : "0"
Warnings : "0"
User Action
View the management agent run history for details.
SharePoint log contains row:
UserProfile Synchronization: Encountered unexpected step result: stopped-connectivity.
Synchronization progress log contains:
[SYNCHRONIZATION CONNECTION NAME]
Additions 0
Updates 0
Unchanged 0
.............................Successes 0
Failures 1
Start Time 2/18/2010 11:06:01 AM
-----------------------------------------------------------------
Thoughts:
Explanation for the error found in the SharePoint logs is found on this blog post. It is in fact the cause of the error, but the true solution to this problem is not that trivial.
What really happens when you create a Synchronization Connection in Central Admin? Behind the scenes SP2010 uses Forefront Identity Manager 2010, amongst other things, to do the actual profile importing from AD. You can find management console for this opening FIM Synchronization Service Manager (SSM) from C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe.
In SSM you can view the status of currently running synchronization jobs, as well as history of previously ran jobs. In the picture below you see the actual error (on yellow), and it is indeed caused because of missing permissions on the AD.
But, why is there wrong DC and Partition there (circled with red)? That is not the AD that was defined in Synchronization Connection, where the defined AD was set to be eu.tieto.com.
Looking at the respective Management Agent properties in SSM (picture below), one can see that eu.tieto.com domain has been replaced by tieto.com (on yellow), which is in this case completely different AD. eu in the Domain field is related to the user name used to do the actual synchronization, and is not related to this issue.
Furthermore, looking at the Directory Partitions definition for this Management Agent, there is some strange partition, CN=Configuration,DC=tieto,DC=com, which is again not at all related to the AD that was defined in SP2010 and where the profiles should be synchronized from.
Solution:
Grant Replicate Directory Changes permission on the cn=configuration container as described here: http://technet.microsoft.com/en-us/library/hh296982.aspx#RDCcn.
---OLD SOLUTION BELOW---
- Start FIM SSM (C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe)
- Go to Management Agents screen, right click on MOSSAD-[SYNCHRONIZATION CONNECTION NAME] and select Properties
- Go to Configure Directory Partitions and uncheck the directory partition that you didn't define in SP2010
- Click OK to close Properties window
- Again, right click on MOSSAD-[SYNCHRONIZATION CONNECTION NAME] and select Configure Run Properties...
- On DS_FULLSYNC, DS_DELTASYNC, DS_FULLIMPORT, DS_DELTAIMPORT, delete step for the directory partition you removed on bullet 3. NOTE! You must only remove the step for the directory partition you removed earlier on bullet 3. I.e., if the removed directory partition was 3rd on the list, you should delete 3rd Step.
- Click OK
- Re-run profile synchronization from Central Admin
You're steps helped me out today. Thanks for the post. Not sure how to do a trackback, so here's my post referencing your post: http://www.johndandison.com/blog/post/2010/02/25/SharePoint-2010-RC-User-Profile-Struggles.aspx
ReplyDeleteOh my, my - so late, my grammar has fallen apart. YOUR post helped me out today. Thanks again!
ReplyDeleteCurrently i have the same error and i followed your steps , i found that my configuration is correct and nothing has been added as per your document , i am running the RTM version .
ReplyDeletethe error :
The management agent "MOSSAD-BiladBankADSync" failed on run profile "DS_FULLIMPORT" because of connectivity issues.
Additional Information
Discovery Errors : "0"
Synchronization Errors : "0"
Metaverse Retry Errors : "0"
Export Errors : "0"
Warnings : "0"
User Action
View the management agent run history for details.
Hi! Just came across the same issue. Ivan I.
ReplyDeleteJussi- I am having similar issues. The user account you blacked out, was it the farm account. Becaue in my case it shows the Farm account. Shouldnt it be the AD Import account??
ReplyDelete@Salman: I wish I remembered which one it was. I do believe, however, that it was indeed the AD import account
ReplyDeletei have a diferent issue, at make an exportation of the attribute tumbnailphoto, the users that have this atributte can´t do th exportation.
ReplyDeletethe issue
name of user "permissions issue"
the user adminsp have the permissoon of replicate. whit this i executte the sincronization.
PD:sorry my bad inglish.
please someone help!
Do you have corresponding field in AD schema where thr thumbnailphoto would be exported to?
ReplyDeleteI can get into FIM SSM but I don't have any of the buttons other than Operations (no Management Agents, etc..) Any pointers on how I get the Management Agents section available to me?
ReplyDeleteThanks for the good post. For configuring I found a nice post here.
ReplyDeletehttp://sharepoint-2010-world.blogspot.com/2011/02/configure-user-profile-sync-in.html
It may helps to the guys who started fresh start. Keep up good work.
If Active full name (xyz.company.com) and netbios name (Company) are different then you have to enable netbios for User profile application
ReplyDeleteFollowing are the steps: run the command in Sharepoint powershell , you can paste them one by one or copy them in notepad and save file as *.ps1
Get-SPServiceApplication
$UPA = Get-SPServiceApplication –Id e8a0520a-cbd9-4e59-873d-5efa56ae68a7
$UPA.NetBIOSDomainNamesEnabled=1
$UPA.Update()
(Get-SPServiceApplication e8a0520a-cbd9-4e59-873d-5efa56ae68a7).NetBIOSDomainNamesEnabled
Great post! Very helpful.
ReplyDeleteAnyone have a clue on how to prevent this from happening in the first place? We will have to repeat the user profile setup a few times and my server admin is not happy about these errors...
This solved my 6050 issue
ReplyDeletehttp://meerasharepoint.blogspot.com/2010/12/management-agent-mossad-synch-ad.html. Also followed your solution and fixed other issues I have. Thanks!
Awesome post sir, thank you very much!
ReplyDeleteThank you so much for this post!!!
ReplyDeleteVery helpfull information, I also used this post to solve my problem, see here: http://www.sharepointfreehelp.com/2012/10/user-profile-service-application-error-fimsynchronizationservice-error-6050/
ReplyDeleteWorked for me! Like a charm.
ReplyDeleteDo you know how to prevent the Configuration DC to appear? (inside sharepoint, not with that tool)
Thank you, very much!
Unfortunately I'm not aware of any ways to actually prevent this from happening in the first place.
ReplyDeleteThank you for this post!
ReplyDeleteI am provisioning USP in SP2013 and mySite is stuck on "We're getting things ready" but it has been 2 days and the profiles haven't loaded. I checked SSM and saw that I have a successful connection but I'm getting a permission error for the 2 users who tried to create their MySites. Now I have to check the permissions on the account. Thank you for leading me in this direction!
Cannot thank you enough. All the posts on the net talk about replication rights and I knew I had this correct, plus all other settings.
ReplyDeleteIt was purely by removing that DC=Configuration partition that a full day of frustration was solved.
I also have found after 3 client installs of SP2013 this is a common occurrence for me.
Brilliant! Thanks. This was not my particular problem, but it showed what was.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteHi Jussi, thanks for this article. We had the exact same problem in SP 2013. When I created connection to AD, the FIM was adding additional Directory Partition with "DC=Configuration", FIM wasnt able to connect to this partition and was erroring out as not replicate permission. Deleting the partition and the respective steps resolved the issue.
ReplyDeleteSaved the day for me. Thanks
Pramod