SharePoint 2010 and 2013 both use some parts of ForeFront Identity Manager (FIM) for the synchronization of users between for example AD and SharePoint. It is possible to use the FIM client to monitor this process and review issues related to the User Profile Service Application. SharePoint 2013 Installation. SharePoint 2016 now comes with the new MinRole feature which configures a server for a specific role in a SharePoint topology like a Web Server or Application Server. SharePoint 2013 Installation. Start the installation of SharePoint Server 2013 and enter the product key. SharePoint: Monitor UPS Service using FIM Client in SharePoint Synchronization Server SharePoint 2013 offers different methods by which we can synchronize the User profiles with Active Directory. SharePoint Profile Synchronization and Active Directory Import are the two primary methods by which we can implement Profile Synchronization. If you're new to SharePoint, here are the directions to install SharePoint 2013 Foundation (I have no idea how SharePoint Server differs): 1) Click on the SharePoint installer (sharepoint.exe). 2) On the 'SharePoint Foundation 2013' screen, click on 'Install SharePoint Foundation'. 3) Follow the prompts through the wizard. Configuring SharePoint 2013 for the Forefront Identity Manager 2010 R2 Service Pack 1 Portal Print posted on Sunday, February 17, 2013 5:05 AM. Recently Service Pack 1 for Forefront Identity Manger (FIM) 2010 R2 shipped. For IdM heads, this is really good news. Along with a bunch of interesting updates and new bits and bobs it is now possible.
- You have one of the following User Profile Synchronization configurations for SharePoint:
- SharePoint 2010, which utilizes Forefront Identity Manager (FIM) for User Profile Synchronization.
- SharePoint 2013, using the 'Use SharePoint Profile Synchronization' option, which also uses FIM.
- SharePoint 2016 or 2019, using the 'Enable External Identity Manager' option, which (typically) uses an external implementation of Microsoft Identity Manager (MIM).
- Note: MIM is the successor to FIM, and works similarly. However, there are differences in how this problem is reported in each version. See 'errors reported' below.
- You have configured profile synchronization to either import or export user profile pictures, typically by mapping the pictureURL property to the thumbnailPhoto attribute in Active Directory.
- You notice that profile synchronization is not importing new users or updating existing users.
Errors Reported:
SharePoint 2010 / 2013 with FIM:
- In the FIM client (miisclient.exe), you notice that the MOSS_FullImport / MOSS_DeltaImport steps fail with 'stopped-extension-dll-exception'.
- If you look at the Application Event Log on the Synchronization server, you should find an error like this:
Log Name: Application
Source: FIMSynchronizationService
Event ID: 6801
Task Category: Server
Level: Error
Keywords: Classic
Computer: The_Sync_Server
Description:
The extensible extension returned an unsupported error.
The stack trace is:
System.Net.WebException: The remote server returned an error: (404) Not Found.
at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
at System.Net.WebClient.DownloadData(Uri address)
at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.DownloadPictures(ProfileChangeData[] profiles)
at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleFileImport.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescription
Notes:
The error is not always '404 Not Found'. That's just the most common scenario. It could be any exception for the FIM service trying to complete an HTTP GET for a profile picture thumbnail. As a rule, if the MOSS_FullImport or MOSS_DeltaImport steps are failing with 'stopped-extension-dll-exception' and you see a 6801 error from FIMSynchronizationService in the app log with ProfileImportExportExtension.DownloadPictures in the stack trace, you are running into some version of this issue.
Here are some alternate stack traces for the 6801 FIMSynchronizationService error that could be thrown:
System.Net.WebException: The remote server returned an error: (401) Unauthorized.
at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
at System.Net.WebClient.DownloadData(Uri address)
at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.DownloadPictures(ProfileChangeData[] profiles, Boolean delayErrors)
at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleFileImport.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData)
à
System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
Fim Path Sharepoint 2013
at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
at System.Net.WebClient.DownloadData(Uri address)
at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.DownloadPictures(ProfileChangeData[] profiles, Boolean delayErrors)
at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleFileImport.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData)
à
System.Net.WebException: The remote server returned an error: (403) Forbidden.
at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
at System.Net.WebClient.DownloadData(Uri address)
at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.DownloadPictures(ProfileChangeData[] profiles)
at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleFileImport.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData)
Note: For the above 403 – Forbidden condition, see my other post here: https://joshroark.com/sharepoint-issues-with-profile-pictures-when-mysite-uses-saml-auth/
SharePoint 2016 / 2019 with MIM:
With MIM, the errors are much more subtle. There is no outright failure of an entire Sync step. Instead, you'll see:
- 'Completed-discovery-errors' for either the FULLIMPORT or DELTAIMPORT steps for the SharePoint Management Agent (SPMA).
- In the Discovery Errors pane, it doesn't even list which users had the problem. It just shows generic entries (ex: entry 5) with a 'read-error'.
Delete Fim Certification Sharepoint 2013
During the DeltaImport and FullImport steps, FIM / MIM needs to get each users profile picture. It does so by making a regular HTTP GET call to the URL listed in the PictureURL property for that user. For example: http://MySiteRoot/User Photos/Profile Pictures/UserName_LThumb.jpg. If this HTTP GET fails for any reason, the user will fail to be updated. MIM appears to be more forgiving and moves on to process other users.
However, with the version of FIM built into SharePoint 2010 and 2013, if it fails to get picture thumbnail, even for a single user, it causes the entire Sync step to fail. Since the entire step fails to import users from the SharePoint side, no user profiles can be updated. As such, a problem with a single picture thumbnail can cause the entire sync to fail for all users.
In the most common scenario (404), the web request to download the picture fails with a 404 (not found) error because the picture thumbnail no longer exists at the location the link is pointing to. It may have been deleted, or the host name part of the URL may have changed. For example, if the mysite host URL was changed from http://MySiteRoot to https://my.contoso.com, any users that still have a profile picture pointing to the old URL will fail (assuming the old URL no longer resolves).
You need to identify the user profile or profiles that have this problem. The Application Event Log will not tell you which users are problematic, and neither will the SharePoint ULS logs. You could review the IIS logs for the Mysite web application and look for 404 responses to LThumb.jpg and MThumb.jpg requests, or configure Fiddler to capture the FIM / MIM traffic, but if there are multiple users with this problem, you will likely only be able to find the first problem profile, and be forced to keep running Syncs and capturing new data until you find them all.
To detect the problematic profiles, there are a couple of options:
You can use this SQL query on the Profile database to see which user profiles have a picture set in SharePoint:
2010 / 2013 version:
select RecordID, Bdeleted, NTName, PreferredName, Email, PictureUrl from UserProfile_Full where PictureUrl like ‘%http%' order by PictureURL
2016 / 2019 version:
select RecordID, Bdeleted, NTName, PreferredName, Email, PictureUrl from upa.UserProfile_Full where PictureUrl like ‘%http%'order by PictureURL
Since it's sorted by pictureURL, any URLs that use a different host name will be at the top or bottom of the query results. If there are any that use a host name other than your current MySite host name, those are highly suspect. To test a given Picture URL, you can just paste it in your browsers address bar. The browser should be able to fetch the picture thumbnail and display it. For the most accurate results, and to account for any network problems, you would want to browse to the picture URL from the Sync server.
If you find that the problem is that the mysite host name was changed, and the old host name no longer resolves, you can update those pictureURL links with the Update-SPProfilePhotoStore commandlet, using the 'OldBaseURI', and 'NewBaseURI' switches. Example:
If nothing sticks out as wrong after reviewing the results from the SQL query above and testing a few URLs, you'll have to test each thumbnail individually to find the problematic ones. I wrote the PowerShell script shown in the 'Script' section below for this purpose. The idea is that it mimics what the Sync engine does. It does an HTTP GET for each pictureURL that is currently set in SharePoint. This is how you use it:
1. Save the PowerShell script as 'CheckProfilePictures.ps1' and move it on to your FIM Sync server at the root of the C: drive.
2. Log into the Sync server as the Farm account.
3. Run the script like this: .CheckProfilePictures.ps1 -url http://mysite -filepath c:logs
— Where 'http://mysite' is the URL for your MySite host, and 'c:logs' where you want it to create the output log file.
Important: Normally, we'd want to run this script from the Sync server. However, if you are using MIM with SharePoint 2016 or 2019, the MIM server is not part of the SharePoint farm, and the script will not work. In that case, you will need to choose a SharePoint server to run it from. Please note that the results may be less valid because, in that case, the script cannot account for networking problems between MIM and SharePoint.
Expected output:
Ondemand5.
When it's done, the console will give you a status update and alert you to any problems:
And it will automatically open the log file ex: 'c:logsProblemPicLog.txt' in Notepad.
If it finds any profiles with problem picture URLs, it will prompt you to decide if you want to automatically remove the picture for those profiles. Just answer Y or N.
WARNING: It generally only makes sense to remove the identified picture thumbnails if there are a small number of them failing with 404 – Not Found. If they are failing with any other error, it could be a permission, networking, or configuration problem. Removing the thumbnails in those cases not only will not solve the problem, it will result in data loss.
Once all the identified problem picture thumbnails have been corrected, you'll want to run a Full Profile Sync.
WARNING: Please do not just run this script and have it delete all of the picture thumbnails it finds as being problematic without further consideration (It will pop up a log file and prompt you Y or N to do the delete). It marks picture thumbnails as being problematic if it fails to get them for any reason. Having the script delete the pictures can result in data loss. Please review the log file it creates and verify that it makes sense to have the script delete the identified picture thumbnails before doing so. You can always answer 'N' on the first run, review the log file and run the script again.
