A SharePoint site by any other name...

There are quite a few situations where you want your SharePoint Web Application available to different sets of users, using different web addresses. For example, our internal users may use http://XYZ to access our web application, but our external clients may have to enter https://secure.xyz.com

SharePoint allows you to assign up to five different "end-user addresses" for each of your Web Applications. These "end-user addresses" are ones that people will type into their browser to access your site. SharePoint uses a feature called Alternate Access Mapping (AAM) to make sure that the web application is available through different addresses while still ensuring that the links in the page sent back to the user are formatted correctly.

For a standard, non-SharePoint web site, this is relatively easy. Microsoft's IIS web server allows an administrator to specify as many addresses as they want for a single web site. These are called "host headers". If you are careful and make sure that all the internal links in your standard web site are written without a domain (e.g. /contactus.aspx), then the end user will always get the correct links based on the address they have used to access the website.

So why doesn't SharePoint work the same way? Well, part of the reason is that there are some scenarios where SharePoint will receive requests using one address, but it needs to translate these to another address before sending the final page to the end user. More on this later.

The end result is that IIS is responsible for accepting the page requests and passing them to SharePoint. It is then SharePoint's job to figure out which Web Application on the server farm the user is trying to access, and what "end user address" it should use when creating the output page.

So this is where Alternate Access Mapping comes into play. However, I got to say, it must be one of the most confusing user interfaces in the whole Central Administration. Even the Search Managed Properties is easier to figure out than this one. Here is my attempt to explain its workings. There is also a great set of MSDN blog articles from Troy Starr, and some screen webcasts from Bob Fox

What I have been referring to as "end user addresses" SharePoint calls Public Zone URLs. We have five different zones:

1. Default
2. Intranet
3. Extranet
4. Custom
5. Internet

They all work the same way, the names just reflect common uses, feel free to use each one as you please. The Default zone is set up for you when you create the Web Application. This zone is given the address that you specified during the "Create Web Application" process. It's up to you to set up the remaining four if you need them.

The easiest way to set these up is to use Edit Public Zone URLs from the Central Administration - Operations - Alternate Access Mapping page:

You need to make sure that you have the correct Alternate Access Mapping Collection specified at the top of the page. This is the Web Application that we want to configure "end user addresses" for. You might find the term "Public URLs" confusing. This does not mean that these are URLs that will be available outside your firewall. It refers to the URLs that your end-users will use to access your site. Some of these may be available outside your firewall, others will only be available internally.

In my example above, I am going to make my Web Application available on all five possible zones. The default name may reflect the machine that my web application is running on. My internal users will go to http://Intranet, but when they are out of the office they will use https://secure.xyz.com. Finally, I will allow clients to access certain information on the same web application at http://extranet.xyz.com

Once we click Save, SharePoint creates one entry in the AAM for each of our Public URLs. I would also update my IIS configuration at this stage to include host headers in my web site for each of these addresses.

But what does the Internal URL section of the table refer to? And how come it is identical to the Public URL? For me, it would have been better if Internal URLs were called Incoming URLs and Public URL was called Out-Going. Basically what happens is that SharePoint looks at the request for a page that it receives from IIS to determine which Public URL to use when creating the final page for the user.

For our example above, this is very straight-forward. If one of our road-warrior salespeople accesses https://secure.xyz.com from their browser, SharePoint will know that they are in the Custom zone, so any URLs on the page that refer to the web application should use the prefix of https://secure.xyz.com on the page it sends to the user. So simple, it almost sounds useless.

However, there are situations when the request that SharePoint receives does not match the address that the user entered. For example, we may have a Reverse Proxy server (such as Microsoft ISA 2006) that receives all the page requests from our external users and then forwards them to our server farm using the SharePoint server name. In this case, we want our our Internal URL to be something like http://AppServer01 but we still want the page sent to the user to use https://secure.xyz.com for any links to other content on the Web Application.

To configure this we use the Add Internal URLs button. This will allow us to specify another address that SharePoint should listen on for requests for our Web Application. By setting the zone to Custom we let SharePoint know what format we want the Web Application links written as.

This will create a 6th entry on our Alternate Access Mapping Collection. Note that we now have two entries for the Custom zone, both with different Internal URLs. We can add as many Internal URLs as we need for each of the zones. However, each Internal URL must be unique across the collection - otherwise SharePoint would not know which Public URL to use to generate the page for the end user.

In our example above, we might think of getting rid of the Custom Zone entry that defines http://secure.xyz.com as a valid Internal URL. After all, SharePoint will never receive requests directly with this URL (only our Proxy Server will). However, this is one of the quirks of the AAM interface - you must have an entry where the Internal and Public URL match. If you do delete this entry, then SharePoint will assign the Default Zone URL to the remaining Custom entry. Just accept that they need to be there.

If you haven't defined a Public URL for one of the zones, you can either use the Edit Public URLs or the Add Internal URLs button to configure it. Confusing, but the end result is the same - a new entry set up in your Web Application's AAM Collection that uses the same URL for both the internal and Public URL.

Similarly, when you use the Edit Public URLs screen to clear one of the Zones, SharePoint will remove the entry from the Collection that uses the same Internal and External URL. If there are any other entries in the collection for that Zone, SharePoint will reconfigure it to use the the Default Public URL.

Finally, here's a graphic to illustrate what is happening. Each zone can have many Internal URLs. SharePoint translates these to the appropriate Public URL based on the Web Application's AAM settings.