Iâ€™m documenting this issue I discovered last week because I havenâ€™t seen it mentioned elsewhere.
The issue occurs only when using the new SharePoint Active Directory Import in SharePoint 2013 when your Central Administration site is running over SSL. When you first setup your profile sync, you have three choices under â€œConfigure Synchronization Settingsâ€:
- Use SharePoint Profile Synchronization (This one leverages the built-in FIM)
- Use SharePoint Active Directory Import (This is the direct AD Import)
- Enable External Identity Provider
I havenâ€™t tested with #1 and #3 so this issue may not apply to those. I originally configured Central Administration to run over port 443 (the default SSL port) and my IIS bindings only have the â€œhttpsâ€ type installed. By selecting my certificate in IIS, it gives me the proper host header: https://spadmin.mynetwork.com.
I did test using alternate ports without success. When using http, any port will work, whether you use the default port 80 or some other port like 8888. I’d like to mention if everything is setup correctly and working, Spence Harbar (@harbars) has a great blog post which explains how to set this up: http://www.harbar.net/archive/2012/07/23/sp13adi.aspx. Refer to that post to see how good ULS logs look. What if you have a similar configuration to the one I have?
Youâ€™ll see something like this first:
CreateProfileImportExportId: Could not InitializeProfileImportExportProcess for end point 'direct://spadmin.mynetwork.com:443/_vti_bin/profileimportexportservice.asmx?ApplicationID=03063851-9e17-4f94-8db6-a71f7b967bd3', retries left '0': Exception 0
ActiveDirectory Import failed for ConnectionForectName 'mynetwork.com', ConnectionSynchronizationOU 'DC=mynetwork,DC=com', ConnectionUserName 'mynetwork\spupssync'. Error message: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Microsoft.Office.Server.UserProfiles.UserProfileApplicationNotAvailableException: No User Profile Application
As far as I know, there is no true fix, its a bug. I hope this will be addressed by an update. To get this working you must use a non-SSL Central Administration. However, as a workaround, you can put a load balancer in front of Central Administration so that client to server communications are encrypted but theyâ€™re unencrypted from the load balancer to Central Administration.