Server Name Mapping and Alternate Access Mapping (AAM)


Alternate Access Mapping (AAM) and Server Name Mapping are two features SharePoint provides to alter the URLs returned in search results – a common practice used by many companies for their internal and external users. Both features are available in both the out of the box search in SharePoint 2010 and in the new FAST Search Server for SharePoint 2010.

This post is intended for people with working knowledge about the two features who want to know when to use which. If you need to brush up on your basic understanding about the two features, here are a couple good sources for your convenience:

·         Alternate access mapping:  http://technet.microsoft.com/en-us/library/cc261814.aspx

·         Server name mapping: http://technet.microsoft.com/en-us/library/cc164184.aspx

Although Server Name Mapping and Alternate Access Mapping achieve seemingly similar results, they work independently, addressing different problems, and should not be used together. I’ve listed the similarity and differences below:

Server Name Mapping

·         Is designed for file share and http content.

·         Allows you to map any server name to anything you like as long as the name you mapped to actually points to the same set of pages.  For example, you might have a Web site with a real access URL http://foo that you want show as http://microsoft.com ; or an internal file share server \\foo and you want to use \\microsoft instead. By setting up Server Name Mapping, your crawler will use http://foo or \\foo for indexing, but your users will only see http://microsoft.com, or \\Microsoft .

·         Requires a full crawl for the mapping, once set up, to be applied.

·         Search results will always use the new name for all users.

·         Settings overwrite the AAM setting for the same results, if you use them together – which you shouldn’t.

·         Is defined by the search admin for each SSA (search service application)

Alternate Access Mapping

·         Is designed for SharePoint content.

·         Allows you to modify results URLs based on the access URLs for a site.  So, for the same result page,  a user accessing from an internal URL will see results with URLs matching the internal site, and a user  accessing from an external URL may get the same result set but with URLs matching the external site. For example, for the same set of SharePoint content, internal users use http://server to access the site, all the URLs they get in search results are prefixed with http://server/… ; external users use http://www.microsoft.com, all the search results they see are prefixed with http://www.microsoft.com.

·         Does not require a crawl for the settings to take effect.

·         Generates results URLs based on how the site is accessed.

·         Is set per farm, so if you have more than 1 search service application in your farm, all of them will use the AAM setting.

The combination of Search Server Mapping and Alternate Access Mapping offers a lot of flexibility in managing URL mappings in search results. I hope this post helps to clarify how these features work and compare. If you have any questions or observations, please don’t hesitate to post your comments here.

Ying Tao, Test Engineer, SharePoint Productivity Search

 

Comments (1)

  1. bspender says:

    In a nutshell, there is an undocumented assumption baked into SharePoint Search that the Default Public URL of a Web Application will be crawled. If you want everything to work auto-magically, just crawl the Web Application's Public URL for the Default zone (and, the crawler requires Windows Authentication in whatever zone your crawl).

    For reference, please see the following (apologies for the self promotion) where I have written extensively on this topic:

     • Alternate Access Mappings (AAMs) *Explained (blogs.msdn.com/…/alternate-access-mappings-explained.aspx)

     • Beware crawling the non-Default zone for a SharePoint 2013 Web Application (blogs.msdn.com/…/beware-crawling-the-non-default-zone-for-a-sharepoint-2013-web-application.aspx)

     • And here, where I discussed this at SPC14 [#SPC375] at the 58 minute mark (channel9.msdn.com/…/SPC375)

    In other words, if you do not crawl the Default URL, you will see the unexpected behaviors described below:

    • Contextual scopes (like "this site" and "this list") will break and not return any results

    • Cross-Web App queries will not map to the correct zone (this is what's being described in the post below stating "when I visit the search center from intranet zone, the items returned in search result page have URL for intranet zone corresponding to their specific web application also"), and I have described this same behavior in my post here

    Similarly, if you use Server Name Mappings with SharePoint content (particularly in SharePoint 2013), the results will be further impacted in a negative way:

     • Server Name Mappings were not intended/designed for SharePoint content, so they are not expected to work (admittedly, in SP2010, they did seemingly *fix the problems that occurred when crawling the non-Default zone… but they were not designed for SharePoint content and they are not recommended for this scenario

     • Server Name Mappings do not re-map all URL based Managed Properties in the Search Index (see the first bullet point 🙂 …not intended for this), so using Server Name Mappings will actually result in an inconsistency in your Search Index where some URL-based MPs will reference one URL root, where others will reference the mapped URL root

     • Office Web Apps will break because the ServerRedirectedUrl MP does not get re-mapped, so the iFrame used to render the OWA part will actually reference the URL root that was crawled rather than the default URL

    As a side note:

    The SharePoint 2013 Search Query Tool on CodePlex is a great way to see this inconsistency (assuming you have Server Name Mappings configured) among managed properties such as OriginalPath, Path, SitePath, ParentLink, ServerRedirectedUrl, and SPSiteUrl…