What every SharePoint administrator needs to know about Alternate Access Mappings

[LEFT][CODE]http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx[/CODE]
[B][SIZE=3]
PART-1[/SIZE][/B]

Hi folks, this is Troy Starr again from the Windows SharePoint Services Test team. Today I'd like to talk about one of the most powerful, but often one of the least understood, features in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. That feature is called Alternate Access Mappings. Around here, we just call it "AAM" for short.
At the most basic level, AAM tells SharePoint how to map web requests (for example, browsing to the homepage of a SharePoint site) to the correct web application and site so that SharePoint can serve the correct content back to you. It then tells SharePoint what URL the users should be taken to as they interact with SharePoint.
Seems simple enough, doesn’t it? Those of you who are familiar with developing web applications in Internet Information Services may be wondering right now why we need such a feature since IIS can tell you what the URL of an incoming web request is. The major reason we need this is that there are common Internet deployment scenarios where the URL of a web request received by IIS is not the same URL that the end user entered. These are most common in reverse proxy publishing and load balancing scenarios.
How is this possible? Let's consider a reverse proxy scenario. A reverse proxy is a device that sits between end users and your web server. All requests to your web server are first received by the reverse proxy device, and if those requests pass the proxy's security filtering, the proxy will forward the requests on to your web server. Reverse proxies can perform advanced functionality such as receiving a web request over the Internet via SSL (HTTPS), but forward the request to the your server via HTTP. This is referred to as off-box SSL termination. They can also forward the request to a different port number than it was originally received on and can even change the HTTP Host header field. If SharePoint were base its links off of the URL of the request it received, the links that end users click on could be the incorrect "internal" URL rather than the correct "public" URL.
SharePoint is compatible with a variety of reverse proxy servers, but for this example we'll take a look at a publishing rule from Microsoft's reverse proxy software - Internet Security and Acceleration Server 2006. ISA Server 2006 includes a SharePoint publishing wizard that walks you through creating a publishing rule for SharePoint. Once the rule is created, you can modify it at any time. (The following images show a slightly modified publishing rule where the "Forward the original host header" option is turned off to help demonstrate the flexibility of AAM. If we left the "Forward the original host header" option turned on, the public hostname would also serve as the internal hostname when configuring AAM.) The first two dialogs show the "listener" and "public name" properties of the rule, which define what URL users will use to access your SharePoint site. Remember that this URL is really the URL of your reverse proxy server, which will forward the request to your SharePoint server.
[IMG]http://blogs.msdn.com/photos/sptblog/images/1818482/314x375.aspx[/IMG][IMG]http://blogs.msdn.com/photos/sptblog/images/1818576/314x375.aspx[/IMG]
The end user's URL is comprised of the public protocol, the public hostname, and the public port number.

[CENTER][B]Public Protocol[/B][/CENTER]
[CENTER][B]+[/B][/CENTER]
[CENTER][B]"://"[/B][/CENTER]
[CENTER][B]+[/B][/CENTER]
[CENTER][B]Public Hostname[/B][/CENTER]
[CENTER][B]+[/B][/CENTER]
[CENTER][B]":"[/B][/CENTER]
[CENTER][B]+[/B][/CENTER]
[CENTER][B]Public Port Number[/B][/CENTER]
[CENTER][B]=[/B][/CENTER]
[CENTER][B]Public URL[/B][/CENTER]
[CENTER]HTTPS[/CENTER]
[CENTER][url]www.contoso.com[/url][/CENTER]
[CENTER]443[/CENTER]
[CENTER][B][COLOR=red]https://www.contoso.com[/COLOR][/B][/CENTER]
The next two dialogs show the "to" and "bridging" properties of the rule, which define what URL the reverse proxy server will use to forward the request to your SharePoint server.
[IMG]http://blogs.msdn.com/photos/sptblog/images/1818588/314x375.aspx[/IMG][IMG]http://blogs.msdn.com/photos/sptblog/images/1818592/314x375.aspx[/IMG]
The SharePoint server's URL is comprised of the internal protocol, the internal hostname, and the internal port number.

[CENTER][B]Internal Protocol[/B][/CENTER]
[CENTER][B]+[/B][/CENTER]
[CENTER][B]"://"[/B][/CENTER]
[CENTER][B]+[/B][/CENTER]
[CENTER][B]Internal Hostname[/B][/CENTER]
[CENTER][B]+[/B][/CENTER]
[CENTER][B]":"[/B][/CENTER]
[CENTER][B]+[/B][/CENTER]
[CENTER][B]Internal Port Number[/B][/CENTER]
[CENTER][B]=[/B][/CENTER]
[CENTER][B]Internal URL[/B][/CENTER]
[CENTER]HTTP[/CENTER]
[CENTER]sharepoint.dmz.contoso.com[/CENTER]
[CENTER]80[/CENTER]
[CENTER][B][COLOR=red]http://sharepoint.dmz.contoso.com[/COLOR][/B][/CENTER]
[IMG]http://blogs.msdn.com/photos/sptblog/images/1818597/267x480.aspx[/IMG]
Great - we've properly set up this reverse proxy server to receive web requests from end users at [url]https://www.contoso.com[/url] and forward them to your SharePoint server at [url]http://sharepoint.dmz.contoso.com[/url]. We're halfway there! The next step is to configure your SharePoint web application and AAM to match the publishing rule above. To do this, we'll extend an existing web application to an additional IIS Web site just for your reverse proxy's publishing rule. Note that you're also able to create a new web application from scratch for this publishing rule - the fields you'll need to fill out are the same in either case.
Browse to your WSS 3.0 Central Administration site and click on the Application Management tab. Next, click "Create or extend Web application" and then click "Extend an existing Web application." Select the web application that you wish to use, and then fill out the port, host header, and SSL fields based on the internal URL properties that we defined above. In the URL field, enter the public URL that we defined above. Finally, you'll want to select an AAM Zone to assign this extension of your web application to. There are a maximum of 5 zones available in each web application. We'll use the Internet zone in this example, but you're free to use any available zone. All of the zones provide the same functionality, although the Default zone will always be used for certain features such as sending administrative e-mail messages to site collection owners. When you're finished, click OK to create the IIS Web site.
Next, you'll want to verify that your public URL was created correctly in AAM and then add your internal URL. Unless your internal URL is the same as your public URL, this is an extra step that you must perform manually. To do this, browse to your WSS 3.0 Central Administration site and click on the Operations tab. Next, click "Alternate access mappings." Click the Alternate Access Mappings selector drop-down and select the web application that you're publishing through your reverse proxy server. You should now see the AAM URLs assigned to your web application.
[IMG]http://blogs.msdn.com/photos/sptblog/images/1818600/640x151.aspx[/IMG]
As you can see, the public URL from the reverse proxy publishing rule has been assigned to your web application's Internet zone. The final touch is to add the internal URL from the reverse proxy publishing rule to your web application's Internet zone. To do this, click "Add Internal URLs" in the AAM toolbar, type in the internal URL, and select the same zone that you used for the public URL. In this case, that was the Internet zone. When you're finished, click Save. You should now see the additional URL is assigned to your web application, in the same zone as the public URL of your reverse proxy publishing rule.
[IMG]http://blogs.msdn.com/photos/sptblog/images/1818609/640x163.aspx[/IMG]
All done! Now, when a user browses to [url]https://www.contoso.com[/url], the web request will be received by the proxy server and forwarded to [url]http://sharepoint.dmz.contoso.com[/url]. SharePoint will then receive the web request, see that the URL of the request is [url]http://sharepoint.dmz.contoso.com[/url], find that this URL is assigned to the Contoso web application, and return the content from that web application. In addition, because the [url]http://sharepoint.dmz.contoso.com[/url] URL is assigned to the Internet zone, SharePoint will also generate links on the pages using the public URL for that zone - [url]https://www.contoso.com[/url]. This ensures that end users are taken to the proper URL when clicking on links on the page.
Load balancers work similarly, especially if they overwrite the end user's original URL with the URL of the individual web server that the request is being load balanced to. To address this, just add each individual web server's URL to AAM as an internal URL and associate them all to the same zone as end user's public URL.
I hope that this introduction to Alternate Access Mappings was helpful to you. Please feel free to post comments to this blog entry with any questions you may have about AAM. I will be posting another blog entry soon covering common AAM mistakes and how to avoid them.

Troy Starr

[/LEFT]

[LEFT][CODE]http://blogs.msdn.com/sharepoint/archive/2007/03/19/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-2-of-3.aspx[/CODE][B][SIZE=3]PART-2[/SIZE][/B]

In [URL="http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx"]Part 1[/URL] of my blog series on Alternate Access Mappings, I gave a brief introduction to the feature and an example of how it can be used. In this blog entry, I'd like to discuss some of the common AAM-related mistakes I've noticed people make when deploying SharePoint.
[B]Mistake #1: "I'm not deploying SharePoint in an unusual way, so I don't need to worry configuring Alternate Access Mappings."[/B]
Probably the most common cause of AAM-related issues is administrators not realizing that they need to configure it in the first place. It's certainly understandable as this is a new requirement in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. The reality is that every SharePoint administrator needs to make sure that AAM is configured correctly, even if you're performing a simple deployment.
For SharePoint to provide a robust and stable API that can work on multiple machines, even machines where the SharePoint web application service is not running, our resolution of URLs to SharePoint sites cannot rely on hosts files, DNS, or IIS bindings. Instead, once SharePoint receives a request it will only use AAM to perform that URL resolution. So while it is necessary to make sure your hosts files, DNS, and IIS bindings are properly configured so that a web request can reach the SharePoint server, it is also necessary to configure the URLs in AAM to match.
Here are some specific examples:

[LIST][*]Fully Qualified Domain Names (FQDN) - If you're using an FQDN URL to reach your SharePoint web application, you need to configure that domain name in DNS. You also need to configure a matching URL in AAM. If this is an URL that end users will use to reach your site, then make it a public URL. If this is an URL that a reverse proxy device will use to forward requests to your site, then make it an internal URL - just be sure that you've configured the end user's URL as the public URL in the same zone.[*]Localhost - Localhost is the syntactic sugar of networking. It allows you to type in [URL="http://localhost/"]http://localhost[/URL] in your browser and always reach the web site hosted on your local machine. However, since localhost is made possible through the machine's hosts file, SharePoint can't automatically take advantage of it. If you need [URL="http://localhost/"]http://localhost[/URL] to be a valid URL for SharePoint, you'll need to enter it into AAM.[*]IP addresses - If you're in an environment where there is no DNS or hosts name resolution and you're just using URLs with IP addresses, you still need to enter those URLs into AAM.[/LIST]
So, if you're seeing broken images or are being redirected to [URL="http://machinename/"]http://machinename[/URL] when browsing to your SharePoint site, then that URL probably hasn't been entered into AAM.
[B]Mistake #2: Your reverse proxy server's "link translation" feature is sufficient.[/B]
Some administrators understand that AAM will fix up the links on pages so that end users are taken to the proper public URL, but they also know that their reverse proxy server has a "link translation" feature that does something similar. If they both do the same thing, then why not just turn it on in the reverse proxy publishing rule and not worry about setting it in AAM?
There are several reasons why this is not a good idea. First off, in our compatibility testing experience, no link translation feature from any reverse proxy server, including ISA Server 2006, is sufficient to fix up all SharePoint links to use the public URL. SharePoint embeds its URLs in many places and in a variety of encodings. Reverse proxy servers are currently not sophisticated enough to find and fix them all. Second, SharePoint has features that use URLs but do not go through reverse proxy server publishing rules. E-mail alerts are a good example. Only AAM will be able to make sure the links in your e-mail alerts are using the correct URL for the user.
So while you're more than welcome to enable link translation in your SharePoint publishing rule, don't forget to properly configure AAM as well. And by the way, if you're exposing the SharePoint 3.0 Central Administration site via a publishing rule, be sure to disable the link translation feature for that rule. It will likely interfere with your ability to configure AAM.

[B]Mistake #3: Trying to reuse the same URL in AAM or not aligning the URLs to the same zone.[/B]
This is a mistake that often catches people when they configure SharePoint to expose a web application to both their internal network and the Internet. For example, suppose you've configured a SharePoint web application on your corporate network with [URL="http://sharepoint/"]http://sharepoint[/URL] as your Default zone URL. Now you want to expose it to the Internet as [URL="http://www.contoso.com/"]http://www.contoso.com[/URL]. When configuring your reverse proxy server, you tell it to forward the requests to [URL="http://sharepoint/"]http://sharepoint[/URL] and then add [URL="http://www.contoso.com/"]http://www.contoso.com[/URL] as a public URL to the Internet zone. Sounds good?
Not quite, unfortunately. While access to the site from your corporate network will continue to work as expected, you might find that access from the Internet isn't working so well and that there are several links pointing to [URL="http://sharepoint/"]http://sharepoint[/URL] This is because the two URLs have been entered into different AAM zones and therefore are not associated with each other.
An URL can be used only once in AAM, and the [URL="http://sharepoint/"]http://sharepoint[/URL] URL was already in use on your corporate network. To forward your Internet-based requests to the same web application, you should use a different internal URL for your reverse proxy publishing rule such [URL="http://sharepoint.dmz.contoso.com/"]http://sharepoint.dmz.contoso.com[/URL]. You can leave [URL="http://sharepoint/"]http://sharepoint[/URL] alone in AAM and still add [URL="http://www.contoso.com/"]http://www.contoso.com[/URL] as your public URL in the Internet zone. You just need to add [URL="http://sharepoint.dmz.contoso.com/"]http://sharepoint.dmz.contoso.com[/URL] as an additional internal URL in the same zone as your [URL="http://www.contoso.com/"]http://www.contoso.com[/URL] public URL - your Internet zone. With them both in the same zone, SharePoint can generate the proper links using the public URL for that zone.
[B]Mistake #4: Updates made in AAM automatically update IIS bindings and vice versa.[/B]
Actually, once a web application has been extended to a zone, SharePoint will not attempt to modify its IIS bindings. If you go into IIS and modify those bindings yourself, say by adding a host header binding, changing a port number, or adding an SSL port, SharePoint won't be aware of those changes and will not update the AAM URLs for you. Similarly, an update to the AAM URLs to add an SSL URL won't automatically update your IIS bindings to match.
Instead, if you need to make a change in your IIS bindings, our recommendation is that you remove the SharePoint web application from that zone. Then you can re-extend the web application to that zone with your updated bindings. This includes if you want to add an SSL port - we don't recommend reusing the same IIS Web site for your HTTP and SSL hosting. Instead, you should extend a dedicated HTTP and a dedicated SSL web site, each assigned to its own AAM zone and URLs.
[B]Mistake #5: Forgetting to configure your environment so that search can crawl your sites.[/B]
You may have configured AAM and your network so that end users can reach your sites, but did you remember to do the same for SharePoint search? The SharePoint search service browses to your web applications to crawl their content and needs to be able to access your public URLs. Make sure that the machine running the search indexing service can reach those public URLs - particularly the one using NTLM authentication. If necessary, configure the proxy settings of your search service account to use your proxy servers. You can do this by logging into the machine as that account and editing its LAN connection settings in IE.
[B]Mistake #6: Typos![/B]
It happens more often than you might think - a quick series of keystrokes and you transpose 2 digits in the port number or two letters in the hostname. Now all of a sudden, SharePoint starts giving you "Cannot find server or DNS Error" messages. Be sure to double check those URLs in AAM. If you're using a reverse proxy server, verify that they match the URLs in your publishing rule.
Hopefully these tips will save you a couple of hours of troubleshooting and perhaps even a few gray hairs. What are your most common mistakes when configuring AAM? Share them with everyone by adding a comment to this post. And of course, you're welcome to ask any additional questions you have about these tips. Next time, I'll dig a little deeper into AAM and how it integrates with other SharePoint features such as security.

Troy Starr

[/LEFT]

[LEFT][CODE]http://blogs.msdn.com/sharepoint/archive/2007/03/19/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-3-of-3.aspx[/CODE]

[B][SIZE=3]PART-3[/SIZE][/B]

In [URL="http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx"][COLOR=#800080]Part 1[/COLOR][/URL] of my blog series on Alternate Access Mappings, I gave a brief introduction to the feature and an example of how it can be used. In [URL="http://blogs.msdn.com/sharepoint/archive/2007/03/19/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-2-of-3.aspx"]Part 2[/URL], I described some of the common AAM-related problems people run into when deploying SharePoint and how to avoid them. For the final article in our series, I'll discuss how AAM integrates with some other features in SharePoint.

[B]Authentication Providers[/B]

As I mentioned in Part 1 of this blog series, AAM allows you to expose a web application in as many as 5 different AAM zones, with a different IIS Web site backing each zone. (As an aside, some people accidentally refer to this as having up to 5 different web applications sharing the same content database(s). In reality, there is just one web application.) Not only do these zones allow you to use multiple URLs to access the same web application, they allow you to use multiple authentication providers to access the same web application as well.

When extending a web application into a zone, SharePoint only offers you the choice of using Windows authentication provided by Internet Information Services. Once the web application has been extended into the zone, you can modify that zone to use a different type of authentication. To do this, browse to the SharePoint 3.0 Central Administration site and click Application Management --> Authentication providers. Next, select your web application from the Web Application selector on the right side of the page. Finally, select the zone that you wish to modify. Now you change your authentication settings for that zone.

The power of this feature is that it allows you to configure completely independent authentication settings to access the very same content. For example, you might configure some content to be anonymously accessible while other content requires credentials. You could configure one zone to have anonymous access enabled and all other forms of authentication disabled, guaranteeing that only the anonymous content will be accessible. At the same time, another zone can have anonymous access disabled while NTLM authentication is enabled, guaranteeing that only authenticated access will be allowed. Plus, you can even have different types of accounts to access the same content - one zone can be configured to use Windows Active Directory (AD) accounts while another zone can be configured to use non-AD accounts via ASP.NET Forms authentication.

[B]Web Application Policies[/B]

Web application policies allow administrators to grant or deny access to accounts and security groups for all sites exposed through a zone. This can be useful for a variety of scenarios.

For example, the SharePoint search crawler must go through the same authorization infrastructure as everyone else - it can only crawl content that it has access to. However, users would still like search to crawl restricted content so that authorized users can find that content in search results. The search service uses a "Full Read" policy on the web applications to give its crawler permission to read all content on that web application. That way, it can crawl and index all existing and future content, even content that the site administrator hasn't explicitly given it access to.

Another example would be help desk personnel who need administrative access to SharePoint sites so that they can assist users. To do this, you can create a web application policy that grants the help desk staff accounts "Full Control" permission so that they have full administrative access to all current and future sites on the web application.

Because policies are tied to both web applications and their zones, you can ensure that the policy you've applied to one zone doesn't affect other zones. This can be useful if you have content exposed both on the corporate network and to the Internet. For example, suppose you've given a help desk staff account Full Control permission over a web application's zone that has been assigned to the corporate network. If someone were to try and use that account to access the site over the Internet, that Full Control policy wouldn't apply because it would recognize that the URL is in a different zone. Therefore, the account wouldn't automatically be given administrative access to the site.

[B]External Resource Mappings[/B]

On the Alternate Access Mappings page, you may have noticed a button on the toolbar called "Map to External Resource." It allows you to extend the AAM functionality to content that is not hosted within the SharePoint farm. When you click on this button, you will be asked to create an entry for an external resource, which you could conceptually think of as another web application. Once you have an external resource, you can assign different URLs and zones to it in the same way that you do for SharePoint web applications. This feature isn't utilized in Windows SharePoint Services 3.0, but third party products that build on top of WSS can make use of it.

For example, Office SharePoint Server 2007's search technology is able to crawl content external to the SharePoint farm such as file shares and Web sites. If that content is available at different URLs on different networks, then you would want search to return search results using the appropriate URLs for the user's current network. By using AAM's external resource mapping technology, search can remap the external URLs in its search results to match the user's zone.

I hope you've found this series on AAM helpful. As always, feel free to ask any questions via the blog comments.


Troy Starr

[/LEFT]