My colleague Anthony Clegg and I have recently been working on a project together, for which I’ve designed and delivered the infrastructure, while he’s been delivering the solution. As part of my design, I extended the SharePoint Web Applications from the default HTTPS zones to new HTTP zones, exclusively for crawling. This approach has been around for some time, but there’s a new wrinkle on the SharePoint 2010 Enterprise Search Centre People Search results page, which I’ll discuss here:
- I have an intranet and a MySite, each with a default zone used by all users to access the application, in this example https://sp and https://my.
- I want to optimise my crawl performance by crawling over HTTP, in order to remove the encryption/decryption load for each request, so I create a new Alternate Access Mapping zone on HTTP, for each of these web applications. These new URLs are http://s and http://m.
- I also set up HOSTS file entries on my Crawl Component servers so they will be able to crawl these applications locally. I don’t want my crawls to add load to the WFE servers.
- If I don’t want real people to access the site on this zone (and I probably don’t), I don’t set up DNS entries for it. Only Search will be using this zone.
- (Optionally) I create a Web Application User Policy that restricts access to this zone, since it is not running under SSL.
-
I reconfigure my Content Sources in the Search Service Application to crawl the new zones, http://s, http://m and sps3://s
- Note, for an SSL-secured site, the final People Search Connector, “sps3://s” will actually be “sps3s://s” by default, so make sure to get rid of that last “s”.
- I run a full crawl and verify that it completes much faster than it did when I was crawling the site over HTTPS/SPS3S.
- Once my full crawl completes successfully, I verify that All Sites and People search results are returning as https://sp and https://my (the default zones).
This was all working as expected – until Anthony noticed that the Org Browser web part appeared to be broken. On further inspection, we identified that:
- Alternate Access Mappings didn’t appear to be working on this link (it displayed the crawled address).
- All other links on the People Search Results tab pointed at the default zone; they accurately respected Alternate Access Mappings.
- All results for the All Sites tab/scope successfully respected Alternate Access Mappings.
So we have one link to the wrong zone on the Enterprise Search Centre’s out-of-the-box People Search results page (or tab, if you prefer). I took this scenario to my development environment to confirm. Indeed, the behaviour was the same. I’ll illustrate below.
Alternate Access Mappings for my Blank Site
Alternate Access Mappings for my My Site
The updated Content Sources page
The “All Sites” Search Results Page With All Links Mapped
In the following four screen shots of the same People Search results, notice the status bar as I hover over various links on this page (see: bottom left of the browser).
The Correct Link to Me
The Correct Link to “Add as Colleague”
The Correct Refinement Link to “All Matches”
The Incorrect Organisation Chart Link (http://m)
It would be incorrect to say that this link is broken. It works, so long as you have name resolution for it. The link is just pointing at the wrong zone, which may not be in DNS. Further, clicking that link may not be desirable or could disrupt the user experience, if the zone is locked down. In short, we explicitly want to avoid edits from that zone in this case, for a number of reasons, all of which I will gloss over here as my preference for a single zone.
Long story short: this looks like a bug to me. I’ll call it a bug. These links are new to User Profiles in SharePoint 2010, so there’s a likelihood that Alternate Access Mappings were overlooked here.
What to do?
I still want to use Alternate Access Mappings, because the performance overhead of crawling encrypted data is not unsubstantial. This leaves me with an option to escalate this issue through Microsoft Support, which I really don’t have the time to do, or we could probably whip up some script quickly to update the results page and fix these two links up, but that’s not a very elegant solution. This is no longer a pressing need in my case, because this client has opted to delay launch of MySites and People Search for reasons completely off this map, but the bug remains and pertains elsewhere (like in my development environment). I will take this to Microsoft when I can find the time, but that’s not going to happen in the near future. Until then, any other ideas?
17-03-2011 update: David noted in the comments that he’s worked around this by running his sps3:// crawl on a different web application – even creating one with no real content, specifically for this purpose. I haven’t had a chance to test it out yet but it sounds like a great idea to me. See the comment for more detail. Anthony has put this to the test for our client and all is working now. Hooray!
Afterword: Server Name Mappings
Somewhere along the line I’ve got myself in a muddle regarding Server Name Mappings. When we first encountered this problem, I configured both Alternate Access Mappings and Server Name Mappings (with the same mappings). In this case, I don’t believe this has caused any problems, but it’s not necessary and isn’t correct. Alternate Access Mappings should translate search results to the same zone that you’re browsing from, without doing any extra work. Server Name Mappings translate crawled data like file shares to other links that don’t already exist as Alternate Access Mappings. As this Enterprise Search blog post explains, “Although Server Name Mapping and Alternate Access Mapping achieve seemingly similar results, they work independently, addressing different problems, and should not be used together”. This is perhaps the only content I’ve found that clearly explains how to use Server Name Mappings correctly, and is well worth a read.
It’s worth noting that the Server Name Mappings had no impact on the Organisation Browser link either.
What I have done to get around this was to point the sps3:// crawler (which crawls profiles and social data) to point to another site that shares the same service applications which is also on the default zone. You could create another SharePoint web application, say http://profiles and leave this on the default zone with an empty site, or if you do not want to have to configure another web application just point the crawl to the central admin site(which is on the default zone).
Hey David. That’s a clever idea! I will update my post accordingly. Cheers!
Thats really good!! I have tried that with the client who had the problem and it has fixed the link. Thank you David!!!
Nice one Ant! I was going to mention this to you but you’ve beat me to it!