I stumbled across an interesting issue with People Search in SharePoint 2016. I was attempting to crawl the user profile store with URL: sps3://server-name and getting Access Denied in the crawl log. I checked the Administrators for the User Profile Service in Manage Service Applications and confirmed my default content access account (crawl account) had access to Retrieve People Data for Search Crawlers (see here).
Looking at the ULS I noticed errors about missing Alternate Access Mappings for an HTTP address, before seeing the Access Denied error. This caught my eye because I’ve configured my collaboration web application and my-site host as HTTPS.
For kicks, I added an IIS binding for HTTP://SERVER-NAME and added an AAM for the server name on HTTP, alongside my HTTPS FQDN. Lo-and-behold, after starting a full crawl the log reported successes for people data.
So, it appears that SharePoint takes the URL sps3://server-name and converts it to http://server-name to make some determination of access to the User Profile store. I’m not sure why this is the case (not yet anyway).
Lesson learned (for now): make sure SharePoint’s default content access account can access the same domain URL on HTTP as that of the SPS3 protocol. As mentioned at the top of this post, I found this out on SharePoint 2016, and I need to test to see if the results are the same on SharePoint 2013.
[Update 5/13/2016]: Turns out I should read the TechNet articles carefully. The following article indicates using sps3s://mysite-url, which then works correctly.