What every SharePoint administrator needs to know about Alternate Access Mappings (Part 2 of 3)

In Part 1 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.

Mistake #1: "I'm not deploying SharePoint in an unusual way, so I don't need to worry configuring Alternate Access Mappings."

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:

• 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 http://localhost 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 needhttp://localhost 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.

So, if you're seeing broken images or are being redirected to http://machinename when browsing to your SharePoint site, then that URL probably hasn't been entered into AAM.

Mistake #2: Your reverse proxy server's "link translation" feature is sufficient.

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.

Mistake #3: Trying to reuse the same URL in AAM or not aligning the URLs to the same zone.

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 http://sharepoint as your Default zone URL. Now you want to expose it to the Internet as http://www.contoso.com. When configuring your reverse proxy server, you tell it to forward the requests to http://sharepoint and then add http://www.contoso.com 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 tohttp://sharepoint 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 http://sharepoint 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 http://sharepoint.dmz.contoso.com. You can leavehttp://sharepoint alone in AAM and still add http://www.contoso.com as your public URL in the Internet zone. You just need to add http://sharepoint.dmz.contoso.com as an additional internal URL in the same zone as yourhttp://www.contoso.com 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.

Mistake #4: Updates made in AAM automatically update IIS bindings and vice versa.

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.

Mistake #5: Forgetting to configure your environment so that search can crawl your sites.

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.

Mistake #6: Typos!

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.