Troubleshooting Alternate Access Mappings in SharePoint

Microsoft TechNet has a detailed document on planning Alternate Access Mapping for SharePoint. It’s a lengthy article but here are some highlights from the section that pertains to troubleshooting. I encourage you to check out the complete article here.

“Use the following guidance to avoid the six most common mistakes that administrators make with regard to alternate access mapping.

Mistake 1: Assuming that you do not need to configure alternate access mappings unless you are deploying SharePoint in an unusual way

The most common cause of alternate access mapping-related issues is administrators not realizing that they need to configure alternate access mappings in the first place. It is certainly understandable because alternate access mappings are a new requirement in Windows SharePoint Services 3.0. Every Windows SharePoint Services 3.0 administrator needs to make sure that alternate access mappings are configured correctly, even for a simple deployment.

Your alternate access mappings might not be configured correctly if you are experiencing any of the following problems.
•    You see broken images on your site.
•    If you experience DNS error messages or error messages indicating that a server cannot be found when you browse to a site without specifying a filename (such as http://computer_name/site_name), but you are able to access the site if you browse directly to a specified file within the site (such as http://computer_name/site_name/default.aspx), incorrectly configured alternate access mappings might be the cause of the problem.
•    You are redirected to http://computer_name when browsing to your site. If Windows SharePoint Services 3.0 receives a request from an unrecognized URL (or a URL that has not been configured for alternate access mappings), and you have installed the Infrastructure Update for Windows SharePoint Services 3.0, Windows SharePoint Services 3.0 tries to determine the correct Web application and then responds to the request by using the same base URL in the links on the page that it returns.

If you are using an FQDN URL to reach your Web application, you need to configure that domain name in DNS. You also need to configure a matching URL for alternate access mappings. If this is a URL that end users will use to reach your site, make it a public URL. If this is a URL that a reverse proxy server will use to forward requests to your site, make it an internal URL.

Mistake 2: Assuming that you can use the reverse proxy server link translation feature instead of alternate access mapping

Although some administrators understand that alternate access mappings will fix links on pages and ensure that end users are taken to the correct public URL, they might assume that because the link translation feature of their reverse proxy server performs a similar function, alternate access mappings might not be required. There are several reasons why this can be a false assumption:
•    In compatibility testing, no link translation feature from any reverse proxy server, including ISA Server 2006, is sufficient to fix all Windows SharePoint Services 3.0 links to use the public URL. Windows SharePoint Services 3.0 embeds its URLs in many places and in a variety of encodings. Reverse proxy servers are currently not sophisticated enough to find and fix all of the URLs.
•    There are Windows SharePoint Services 3.0 functions that do not go through reverse proxy server publishing rules, for example e-mail alerts. Only by using alternate access mappings will you be able to ensure the links in your e-mail alerts are using the correct URLs for your users.

Important: If you expose Central Administration by using a publishing rule, make sure the link translation feature is disabled for that rule. If link translation is not disabled, it can interfere with your ability to configure alternate access mapping.

Mistake 3: Trying to reuse the same URL in alternate access mapping or not aligning the URLs to the same zone
This is a mistake that often catches people when they configure Windows SharePoint Services 3.0 to expose a Web application to both their internal network and the Internet. For example, if you have configured a Web application on your corporate network with “http://sharepoint” as your Default zone URL and you want to expose it to the Internet as http://www.contoso.com, you might configure your reverse proxy server to forward the requests to http://sharepoint and then add http://www.contoso.com as a public URL to the Internet zone. This is a mistake. While access to the site from your corporate network will continue to work as expected, you might find that access from the Internet is not working very well and there are several links pointing to http://sharepoint. This is because the two URLs have been entered into different alternate access mapping zones and therefore are not associated with each other.

A URL can be used only once in alternate access mappings, and in the preceding example, the http://sharepoint URL was already in use on your corporate network. To forward your Internet-based requests to the same Web application, use a different internal URL for your reverse proxy publishing rule, such as http://sharepoint.perimeter.contoso.com.

Note: 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.

Mistake 4: Assuming that updates made in alternate access mappings automatically update IIS bindings

After a Web application has been extended to a zone, Windows SharePoint Services 3.0 will not attempt to modify its IIS bindings. If you modify these bindings in IIS by adding a host header binding, changing a port number, or adding an SSL port, Windows SharePoint Services 3.0 will not be aware of the changes and will not update the alternate access mapping URLs. Similarly, an update to the alternate access mapping URLs to add an SSL URL will not automatically update your IIS bindings to match.

If you need to make a change in your IIS bindings, remove the Web application from the zone by using the Remove SharePoint from IIS Web site link on the Application Management page.

Note: This action only removes an IIS Web site and its zone from the Web application. It does not delete the Web application itself, or the content databases of the Web application.

Then you can re-extend the Web application to the zone, using your updated bindings. This is also true if you want to add an SSL port. We do not recommend reusing the same IIS Web site for your HTTP and SSL hosting. Instead, extend a dedicated HTTP and a dedicated SSL Web site, each assigned to its own alternate access mapping zone and URLs.

Mistake 5: Forgetting to configure your environment to enable search to crawl your sites

If you have configured alternate access mappings and your network to enable end users to reach your sites, you must also configure alternate access mappings and your network for Windows SharePoint Services 3.0 search. The Windows SharePoint Services 3.0 Search service browses to your Web applications to crawl their content and must be able to access your public URLs. Make sure that the computer running the search indexing service can reach those public URLs. This is particularly important for any computer that uses NTLM authentication. If necessary, configure the proxy settings of your Windows SharePoint Services 3.0 Search service account to use your proxy servers. You can do this by logging into the computer as that account, and editing the LAN connection settings in Internet Explorer.

Use the following procedure to edit LAN connection settings in Internet Explorer.

Edit LAN connection settings in Internet Explorer
1.    From Control Panel, open Internet Options.
2.    On the Connections tab on the Internet Options properties page, click LAN Settings.
3.    Edit the LAN connection settings in the Local Area Network (LAN) Settings dialog box, and then click OK.

Mistake 6: Making typographical errors

Make sure that the URLs in alternate access mappings are entered correctly. If you are using a reverse proxy server, verify that URLs in the alternate access mappings match the URLs in your publishing rule.”