Alternate Access Mappings (AAMs) *Explained

Based on many of the support cases that I've seen, Alternate Access Mappings (AAM) may be one of the least understood aspects of SharePoint and can have substantial impact on Search (both Crawl and Query). In this post, I'll document some of my experiences and insights on AAMs.

Note: "Plan alternate access mappings (Office SharePoint Server)" is the best resource I've found for documenting AAMs, which covers both several configuration scenarios and troubleshooting common mistakes. Although listed as SharePoint 2007 content, its information largely applies to both SharePoint 2010 and SharePoint 2013. I won't duplicate that TechNet page, but I will make reference (calling it the "Plan for AAMs" document) to reiterate some aspects that have particular impact for Search.

Updates: I recommend also reading my follow on post here that further dives into the problems that occur when crawling the non-default zone and work to show why crawling the default zone should be considered required (*hint: it's going to break otherwise). I also have a redux post here on AAMs that provides even more illustrations to explain this.

The most common mistakes I see regarding AAMs tend to fall into the following groups (more detail on each of these throughout this post):

  • Crawling the non-Default zone URL for the Web Application 
  • Creating a new AAM zone without extending the Web Application or manually altering the Public URL of any zone from Central Admin
    • This can cause ambiguous scenarios for routing requests to SharePoint and result in connectivity issues or unexpected authentication failures
    • Unless configuring for Reverse Proxy or adding additional Internal address (both fairly uncommon), there's almost no reason to manually alter AAMs
  • Assuming that updates made in AAMs automatically update IIS bindings (Source: Plan for AAMs)
    • A by-product of this: If IIS host name bindings are generic across multiple IIS Sites and AAMs are modified incorrectly, a single w3wp.exe process may be incorrectly handling requests for another SharePoint Web Application
  • Not configuring External Resource Mappings in the Search Farm when crawling another farm 


AAMs: An Overview and Base Example

In the Plan for AAMs document (referenced above), it provides the following description (again, this also applies to SP2010 and SP2013):

"Alternate access mappings enable a Web application that receives a request for an internal URL, in one of the five authentication zones, to return pages that contain links to the public URL for the zone. You can associate a Web application with a collection of mappings between internal and public URLs. Internal refers to the URL of a Web request as it is received by Office SharePoint Server 2007. Public refers to the URL of an externally accessible Web site. The public URL is the base URL that Office SharePoint Server 2007 uses in the pages that it returns. If the internal URL has been modified by a reverse proxy device, it can differ from the public URL."

That accurately describes it, but if you've never seen it defined before, it's easy to get hung up on the difference between the Internal URL versus the Public URL or some other nuance of this. Or if you're like me... you made it about fifteen words into that before your eyes glazed and you started skimming it. So, let me try to describe this with pictures (which you can click on these to see a bigger view).

First, assume you just created a Web Application with a load balanced URL http://initech and haven't configured any other modifications to the AAMs. For this, your AAMs would resemble the following:

And the communication flow for a page request from the user would look something like this...

Now, let's look at some definitions to help you get your mind wrapped around Internal and Public URLs:

  • Internal URL: It would probably  make more sense if this were named with the OM property "Incoming URL", because (I can't find an "official" definition, but) the Internal URL essentially defines the URL(s) that SharePoint deems as viable requests coming into SharePoint (It's important to distinguish this from the bindings at the IIS level, which occur before the request gets to SharePoint). In this example above, the Internal URL is represented by the "HTTP GET (http://initech)" arrow coming from the client. As an analogy, if you called me "Brian" or "bspender", I'd answer you. However, if you called me "Todd", I might not realize you were talking to me.
  • Public URL: After a request is received by SharePoint, a page is built by the server and returned to the client. In this page, there are links to other content (think menus, web parts, and so on), and these links are all relative to the current URL. For example, if you're visiting http://initech, all of these links in this page would be relative to http://initech (think: http://initech/path/page.aspx). If you had multiple AAMs configured, you may be accessing this same page as http://foo/path/page.aspx where all of its links would then be relative to http://foo as in the example below. The Public URL is essentially the root to all of these relative URLs (e.g. http://initech or http://foo )... it defines with which URL root each anchor tag will be stamped when the page is built by the server and returned to the requesting client. Below demonstrates the same page being loaded from two different URL zones. In this, the structure of the page is the same, but the URLs in each anchor tag have a different root:


Typically, the Internal URL is the same as the Public URL, so it's not always obvious that there is a difference between the two. But what if you added a second Internal URL, such as:

Adding a second internal address is common when you want to target a specific server rather than a load balanced address. In both cases, the user is targeting the same SharePoint Web Application (and more specifically, the same Web Application Zone), but via a different "incoming" URL.

In this scenario of browsing to http://someServer, the picture would look exactly as the communication flow depiction above, except the initial request from the client would contain "HTTP GET (http://someServer)". Even so, the rendered page would still show relative to its Public URL, http://initech. In other words, if the user browsed to http://someServer, it would pull the same content as when browsing to http://initech. However, when browsing to http://someServer, the URL in my address bar would change back to http://initech (the Public URL) such as:

Note: Technically, this isn't redirecting to http://initech, but the page will display relative to http://initech. However, the page has to then pull back JavaScript, CSS files, images and other resources to full load the page content. The links to these resources are defined server-side as relative URLs...using the Public URL for this request. Thus, the page loads with references to the load balanced address http://initech and will pull these resources from http://initech.

This is common a strategy for troubleshooting/targeting a specific web server to process a request. Think http://your.typical.load.balanced.url (which would  route through a NLB) versus the same request targeted to a specific server such as http://server1 or http://server2 etc...). It is also required when setting Web App's SiteDataServers property for implementing dedicated crawl targets. 


Extending the Web Application and Why It's Important

In a second example, the Web Application gets extended into another zone, such as:


Which would have a corresponding communication flow like:

In this, the same content is rendered via different URLs, where each URL represents a different zone (and in this case, each zone also has a different Authentication Provider, but it is not required to be different). A common problem occurs when creating a new AAM zone without extending the Web Application (or similarly, manually altering the Public URL of any zone from Central Admin). To better describe why this causes a problem, I need to first provide some background.

When creating a Web Application, SharePoint also creates a corresponding IIS Site (an IIS Site is different than a SharePoint Site [which is really a Site Collection] or a SharePoint Web [which is often called the root or sub-site]... unfortunately, the term "site" is often used interchangeably causing a ton of confusion). When a request reaches a server, the underlying server subsystems (such as HTTP.SYS) route these to IIS. Using the IIS Sites and its bindings, these requests are then routed to the appropriate w3wp.exe for processing (in other words, an IIS Site is bound to a particular App Pool, which has a w3wp.exe process).

Note: Check out SharePoint as an ASP.NET-IIS Application for much more information on this topic, which includes the following:

"A web application in SharePoint terminology is closely related to what is called a website in IIS terminology...  It can be helpful, especially when you are trying to see the relation between SharePoint and IIS from a high and broad perspective, to think of the SharePoint web application and its corresponding IIS website as a single entity...  [A]lthough there is usually a one-to-one relation between SharePoint web applications and IIS websites, this is not always the case."

When extending a Web Application into another zone, SharePoint:

  1. Creates a new IIS Site to represent this extended zone (which uses the same App Pool as the default zone, meaning the same w3sp.exe process for each Web Application zone)
    • Because IIS Bindings are set at the IIS Site, this has significant implications on how requests get routed to the appropriate SharePoint Web Application
    • The web.config also lives within the IIS Site, which should be of consideration if this zone has different Authentication Providers [per zone] and/or customizations
  2. Modifies the Alternate Access Mappings to include the new zone

When just simply modifying the AAMs without extending the Web Application, the IIS Site does not get created for the extended zone. In fact, from PowerShell, we can verify that the IisSettings object does not created for the Web Application. For example, in my Farm, I manually created an Intranet zone by simply adding a new AAM rather than extending the Web Application, then ran the following:

$webApp = Get-SPWebApplication http://initech   

    ServerComment     : SharePoint Initech 80
    Path              : C:\inetpub\wwwroot\wss\VirtualDirectories\initech80
    ServerBindings    : {Microsoft.SharePoint.Administration.SPServerBinding}

    #...this is empty because IisSettings is $null

The Plan for AAMs also notes the following (and I wish this were also explicitly documented for SP2010 and SP2013, but this article was never updated for these newer versions. In either case, this functionality hasn't really changed across the versions, so it - in my mind- applies to all version of SharePoint):

"We recommend extending a Web application to a new IIS Web site for each zone you want to use. This provides a backing IIS Web site. We do not recommend reusing the same IIS Web site for multiple zones, unless you are specifically told to do so by Microsoft."

Depending on the bindings in the other IIS Sites (particularly with "*" [wildcard] host headers and/or multiple sites using the same port), it is quite possible to create ambiguous scenarios where requests may reach the incorrect w3wp.exe for processing (here is a Microsoft KB and here is another blog describing this behavior). In this scenario, SharePoint can in cases still accept the request and process it. Here, it is quite possible that things will appear to work, but it might also create some weird idiosyncrasies that can't be fully explained.

  • For the customers that I've had with these types of problems, the was generally resolved by detaching the Content DB(s), rebuilding the Web Application, and then extending the Web App into the additional zones.

A similar problem occurs when manually altering the AAMs from Central Admin (e.g. changing the AAMs without extending). This, as noted as "Mistake 4" in the Plan for AAMs TechNet, seems to correlate to a common misconception that "updates made in alternate access mappings automatically update IIS bindings". However, changes to AAMs are not reflected in IIS (whereas extending the Web Application creates a new IIS Site with the appropriate IIS settings/bindings in place). Thus, manually changing the AAMs could induce these problems even if the zones were originally extended.


Some Impacts to Crawling the non-Default URL

This isn't documented anywhere, but I'm convinced that there is an inherent assumption built into SharePoint that a Web Application's Default zone will be crawled (specifically, the Public URL).

For example, in SharePoint 2010, contextual scopes and popular social tags both break if crawling the non-Default zone (Contextual scopes break because the query processor attempts to translate the URL to the Default zone's Public URL before processing the query. For Social Tags, SharePoint normalizes the tagged target URL to its Default zone's Public URL before storing it in the Social DB).

In SharePoint 2013, URL-related managed properties including Path, ParentURL and SPSiteUrl all store values relative to the URL that was crawled. However, as demonstrated in my previous post, these clearly get negatively impacted at query time by crawling the non-Default zone (again because the query processor attempts to translate the URL to the Default zone's Public URL before processing the query).

  • It is possible in these cases that queries may seem to function properly from one zone, but not another (and things may be misbehaving from all zones)
  • If crawling the non-Default zone, change the Search Content source to specify the Default URL and start a full crawl
    • Note: Don't just simply add the Default URL... replace one URL for the other (in other words, you should not be crawling the same Web Application using multiple URLs)

Also, although not directly caused by AAM configuration, AAMs do play a contributing role on the configuration of IIS Bindings, DNS (or HOSTS files), load balancers, proxy servers, and the DisableLoopbackCheck (or BackConnectionHostNames) registry settings.


Mapping External Resources

As noted above, some query-time scenarios require a translation between zones using the AAMs. However, AAMs are an aspect of Web Applications, so what happens if the Web Application is in a remote farm (e.g. as in a Enterprise Services Publishing/Consuming scenario where the Search Farm is different than the content Farm)? For this, we have the ability to create an "External Resource Mapping" in the Search Farm. These allow you to create AAMs for an external Farm within the local Search Farm. In this blog, the author describes this scenario and shows how to build the External Resource Mappings.

Essentially, you're duplicating the alternate access mappings in the Search Farm so the query processor can properly map the requests to the correct Default zone. For example, if the original Web App in the content farm has a Default, Intranet, and Extranet mapping, you'd want to create an External Resource Mapping in the Search farm and provide the URLs for the target's Default, Intranet, and Extranet zones.

Comments (36)
  1. Praveenh says:

    Awesome article, Brian. Way to go.

  2. ZZ says:

    Super Nice!!!

  3. The Bobs says:

    Nice article, we think you may be management material.

  4. Jason Warren says:

    "Unless configuring for Reverse Proxy or adding additional Internal address (both fairly uncommon), there's almost no reason to manually alter AAMs" YES. THANK YOU.

  5. Coderbond says:

    Great Read, simple and consice.

    How does this short article factor in to the 2013 equation?

    Thanks Brian!

  6. Ciprian says:

    You said:

    "This is common a strategy for troubleshooting/targeting a specific web server to process a request. Think your.typical.load.balanced.url (which would  route through a NLB) versus the same request targeted to a specific server such as http://server1 or http://server2 etc…)" on Internal URL section. Now if you want to have this approach to be able to access the website by http://server1 or http://server2 for reasons like monitoring each WFE, it will not work unless you will add an IIS binding with those entries. After you will add that it will happen what is done by design, which means when you will access http://server1 it will be changed to your.typical.load.balanced.url

    Maybe you can add this to the article or at least try to get a working approach.



  7. Prasath C says:

    Nice article, thank you.

  8. Matt Warburton says:

    Thanks for this. Bookmarked for when I next forget the difference bwteen internal and public URLs!

  9. bspender says:

    Ciprian… sorry for the late response.

    You'll only need IIS bindings if you have multiple things (e.g. multiple Web Apps) using port 80, but not required otherwise.

  10. Hilton Giesenow says:

    Thanks Brian for this great overview, helped to confirm some things – wish I'd had it YEARS ago!

  11. Andy Daniel says:

    Brian, FYI, I've found that the External Resource Mapping in a 2013 publishing farm is broken and the consuming farm does not receive the AAM mapped results.  Scenarios are:

    2010 SearchCenter consuming 2010 SSA from Publishing farm: Works

    2010 SearchCenter consuming 2013 SSA from Publishing farm: Broken

    2013 SearchCenter consuming 2013 SSA from Publishing farm: Broken

    2013 SearchCenter on same farm as 2013 SSA: Works

    Have an MS case open.  Will update here if we find a fix.

  12. bspender says:

    Thanks Andy! (I was working with your engineer behind the scenes when you opened the case, so now very aware of what you're talking about).

    I'll write more on this as soon as I can… but turns out the query time AAM re-mapping in SP2013 got moved into the SSA Proxy (and in SP2010, it occurred in the SQ&SS), which impacts the ability of SP2010 farms consuming from SP2013 SSAs to properly remap AAMs…

    Curious to see the final outcome of that one myself 🙂

  13. Swanl says:

    Thanks so much.  Exellent

    This have helped me clear up my confusion about how AAM need to be setup and how it work


  14. Swanl says:

    Thanks so much

    This have helped me to clear up many confusion on AAM. How to setup and how it work

    can't get a better picture…

  15. Great Post!  Do you have an update on the SP2013 search center issue above?  

  16. Sam says:

    Hi Brian/Others,

    This is an excellent article and explains some of the very confusing terms in a very easy way, well done !

    I do have couple of questions as well though if I may ask:

    Q. What are the zones (5) exactly for? What is their purpose and when to use the different zones?

    Q. If I have a scenario where the SP Intranet is accessed via http://myintranet inside the organisation. What if I wish to extend this to outside of the organisation via a URL like and serve the same web app and content DB, but also resolve/convert this external URL into the internal format, So:

    1- Client asks for – http://myintranet AND gets – http://myintranet inside the organisation

    2- Client asks for – AND IS IT POSSIBLE TO GET – http://myintranet

    Look forward to some interesting and insightful answers !



  17. bspender says:

    Hi Sam,

    I hope this link answers your first question (e.g. what are the zones for?)…/cc261814.aspx

    For the second…

    I'm assuming that there are different authentication providers being used for each zone, and if so, then I am not aware of a means of achieving your scenario (e.g. attempting to use the same public URL across two zones)

    I hope that helps…


  18. bspender says:

    Thanks Matt,

    That issue is fixed in the Dec '14 CU …a new property ($ssa.UrlZoneOverride) is added to the SSA (to which I'll post a more detailed post in the near future to further explain it)

  19. Prasath C says:

    Very helpful! thanks

  20. ravindra says:

    That was fantastic. Appreciate it and now i am at certain level of understanding. Thanks Brian.

  21. someonefromthecrowd says:

    fantastic, fantastic, fantastic. thank u so much.

  22. Amir says:

    Excellent Article, very clear for concept and for setup. However i have a question on the usage.

    What if an internal staff member, who would work on a file with an internal / intranet URL, wants to send a document link to an external customer. I believe that has to be a manual process of URL rewrite in the email to make it fit for the external collaborator… is there a solution for this?

  23. bspender says:

    Hi Amir, I'm not familiar with the specifics of that particular sharing functionality… but I would assume that it just assumes the default zone (I'm also assuming from your question that the link does not align with the zone from which the share is initiated… but admittedly have not tested this scenario. Being said, have you tried browsing to [for example] the extranet zone and shared the document from that zone? Does the shared link align to the extranet zone, too?)

  24. Sorathia says:

    if you want to support managed paths with wildcard inclusions on multiple host names, you should use Alternate Access Mapping instead of host-named site collections. If you want to support self-service site creation and provide multiple paths to content, you should use Alternate Access Mapping instead of host-named site collections.

    Can someone explain above.

    Thanks is advance

  25. Jeremiah Anderson says:

    Wow!! Simple, accurate helpful!!! Thank you!

  26. Praneeth Tetali says:

    Thank you Brian, amazing artical !

  27. Thank you for nice Article, I have couple of questions if you cleared it.
    1) I want to change the port number of my Web Application, what is the best way to do? i think Update the IIS bindings with new port and Update AAM with new port in Internal URL, is it ok or should i delete the Web app and recreate it?
    2) I want to change the URL of existing Web Application from http://Public to http://Public-New, what is the best way to do? i think, simply update the AAM, update the IIS settings for Hostheader and Bind new certificate. or should i delete and recreate it?

    1. bspender says:

      …either should work for 1 and 2.

      1. So no need to extend the web application in both question (1 & 2)? What i understand that i have to extend or delete & recreate the web application.

  28. Jeff says:

    What if i have an http web application (SharePoint 2010) with a https IIS binding. I want the site to be mixed, for users can access both http and https. Should I extend the web application into a different zone and create a https version iis site, or is there another way to do this?

    1. bspender says:

      Do you want users to browse but the page respond with https? If so, then just add an Incoming URL of http to your https web application…
      – But if you want http traffic and https traffic (*not sure of the use case here… why both?), then you would need separate zones
      (just make sure you crawl the Public URL of the Default zone)

  29. AJ says:

    We have an intranet home page with http. We want to buy a certificate and get the same site working on https. Will I need to add an Internal URL and point to the same public URL as it is now and also in the same zone ?

  30. lasertest says:

    I am actually thankful to the owner of this web page who has shared this impressive piece of writing at at this place.

  31. Arosh mahavidanalage says:

    I got a requirement of mapping 30+ AAM URLs to the same web application. Seems like SharePoint has a hard limitation like 5. Is there any work around/ approach to achieve this.

  32. Nice article, thanks ))

Comments are closed.

Skip to main content