Plan alternate access mappings (Windows SharePoint Services)

Applies To: Windows SharePoint Services 3.0

 

Topic Last Modified: 2009-04-15

In this article:

• About alternate access mappings

• Reverse proxy publishing

• Alternate access mapping integration with authentication providers

• Alternate access mapping integration with Web application policies

• Alternate access mapping and external resource mapping

• Troubleshooting alternate access mappings

Alternate access mappings direct users to the correct URLs during their interaction with Windows SharePoint Services 3.0 (while browsing to the home page of a Windows SharePoint Services 3.0 Web site, for example). Alternate access mappings enable Windows SharePoint Services 3.0 to map Web requests to the correct Web applications and sites, and they enable Windows SharePoint Services 3.0 to serve the correct content back to the user.

Alternate access mappings have been implemented because there are common Internet deployment scenarios in which the URL of a Web request received by Internet Information Services (IIS) is not the same as the URL that was typed by an end user. This is most likely to occur in deployment scenarios that include reverse proxy publishing and load balancing.

Note

Alternate access mappings must be configured for load balancing, even though it generally does not apply to host header site collections. The default zone public URL should be set to a domain URL that is appropriate for all users to see. Unless this is done, the names of Web servers or their IP addresses may be displayed in parameters passed between pages within Windows SharePoint Services 3.0.

About alternate access mappings

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 Windows SharePoint Services 3.0. Public refers to the URL of an externally accessible Web site. The public URL is the base URL that Windows SharePoint Services 3.0 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.

Note

Host-named site collections cannot use alternate access mappings. Host-named site collections are automatically considered to be in the Default zone, and the URL of the request must not be modified between the end user and the server.

Multiple internal URLs can be associated with a single public URL. Mapping collections can contain up to five authentication zones, but each zone can only have a single public URL. Mapping collections correspond to the following authentication zones:

• Default

• Intranet

• Internet

• Custom

• Extranet

Reverse proxy publishing

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 forwards the requests to your Web server. Reverse proxies can perform advanced functionality, such as receiving a Web request over the Internet by using HTTPS (Hypertext Transfer Protocol over Secure Socket Layer), but forward the request to the server by using HTTP. This is referred to as "off-box SSL termination." Reverse proxies can forward the request to a port number other than the port on which the request was originally received. Reverse proxies can also change the HTTP Host header field.

Windows SharePoint Services 3.0 is compatible with many reverse proxy servers, but in the following example the publishing rule is from the reverse proxy software, Microsoft Internet Security and Acceleration (ISA) Server 2006. ISA Server 2006 includes a publishing wizard to help you create a publishing rule for Windows SharePoint Services 3.0. After the rule is created, you can modify it at any time.

Note

Some reverse proxy devices can modify the path of a request (the portion of the URL that comes after the hostname and port number) in such a way that a request sent by the user to https://www.contoso.com/sharepoint/default.aspx, for example, is forwarded to the Web server as http://sharepoint.perimeter.example.com/default.aspx.
This is referred to as an asymmetrical path. Windows SharePoint Services 3.0 does not support asymmetrical paths. The path of the URL must be symmetrical between the public URL and the internal URL. In the preceding example, this means that the "/sharepoint/default.aspx" portion of the URL must not be modified by the reverse proxy device.

Configuring the reverse proxy server

The first two figures in this example show a modified publishing rule where the Forward the original Host header option is turned off to help demonstrate the flexibility of alternate access mapping. If the Forward the original Host header option is selected, the public hostname also serves as the internal hostname when configuring alternate access mapping.

The following figures show the Listener tab and Public Name tab on the properties sheet for the rule. These properties define the URL to use to access your Web application. This URL is actually the URL of your reverse proxy server, which forwards the request to your server running Windows SharePoint Services 3.0.

The end user's URL is made up of the public protocol, the public hostname, and the public port number, as shown in the following table.

Public protocol		Public Hostname		Public port number		Public URL
HTTPS	+ "://" +	www.contoso.com	+ ":" +	443	=	https://www.contoso.com

The following figures show the To tab and Bridging tab on the properties page for the rule. These properties define the URL that the reverse proxy server uses to forward the request to your server running Windows SharePoint Services 3.0.

The URL of the server running Windows SharePoint Services 3.0 is made up of the internal protocol, the internal hostname, and the internal port number, as shown in the following table.

Internal protocol		Internal Hostname		Internal port number		Internal URL
HTTP	+ "://" +	sharepoint.perimeter.contoso.com	+ ":" +	80	=	http://sharepoint.perimeter.contoso.com

At this point, the reverse proxy server is configured to receive Web requests from end users at https://www.contoso.com and forward them to your server running Windows SharePoint Services 3.0 at http://sharepoint.perimeter.contoso.com.

Configuring the SharePoint Web application

After you have configured the reverse proxy server publishing rule, configure your Web application and alternate access mappings to match the publishing rule. You can do this by extending an existing Web application to an additional IIS Web site specifically for the reverse proxy publishing rule. You can also create a new Web application for this publishing rule. The values you need to enter are the same in either case.

Use the following procedure to extend an existing Web application.

Extend an existing Web application

1. From Administrative Tools, open the SharePoint Central Administration Web site.

2. On the Central Administration home page, click Application Management.

3. On the Application Management page, in the SharePoint Web Application Management section, click Create or extend Web application.

4. On the Create or Extend Web Application page, click Extend an existing Web application.

5. On the Extend Web Application to Another IIS Web Site page, select a Web application. When you have selected a Web application, enter values for the port, Host header, and SSL fields, based on the internal URL properties defined in "Configuring the reverse proxy server" earlier in this article. In the URL field, enter the public URL defined in "Configuring the reverse proxy server," as shown in the following figure.

   

6. Select an alternate access mapping zone to assign this extension of your Web application to. There are a maximum of five zones available for each Web application. In this example, we will use the Internet 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.

7. To create the IIS Web site, click OK.

After you have completed these procedures, verify that your public URL was created correctly in alternate access mappings 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.

Use the following procedure to view the Alternate Access Mappings page.

View the Alternate Access Mappings page

1. From Administrative Tools, open Central Administration.

2. On the Central Administration home page, click Operations.

3. On the Operations page, in the Global Configuration section, click Alternate access mappings.

4. On the Alternate Access Mappings page, select the Web application to publish through the reverse proxy server.

At this point, you should see alternate access mapping URLs assigned to your Web application, as shown in the following figure.

The public URL from the reverse proxy publishing rule has been assigned to the Internet zone of your Web application. Use the following procedure to add the internal URL from the reverse proxy publishing rule to the Internet zone of your Web application.

Add the internal URL from the reverse proxy publishing rule to the Internet zone of your Web application

1. On the Alternate Access Mappings page, click Add Internal URLs.

2. Type the name of the internal URL and select the same zone that you used for the public URL. In this example, we will use the Internet zone.

3. Click Save.

At this point, you should see that the additional URL is assigned to your Web application (in the same zone as the public URL of your reverse proxy publishing rule), as shown in the following figure.

When a user browses to https://www.contoso.com, the Web request will be received by the reverse proxy server and forwarded to http://sharepoint.perimeter.contoso.com. Windows SharePoint Services 3.0 will then receive the Web request, see that the URL of the request is http://sharepoint.perimeter.contoso.com, find that this URL is assigned to the Contoso Web application, and return the content from that Web application. In addition, because the http://sharepoint.perimeter.contoso.com URL is assigned to the Internet zone, Windows SharePoint Services 3.0 will generate links on the pages by using the public URL for that zone: https://www.contoso.com. This ensures that end users are taken to the proper URL when clicking 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 account for these overwritten URLs, just add the alternate access mappings for the URLs of each individual Web server, as internal URLs, and associate them to the same zone as the public URL of the end user. If they preserve the original URL, then simply have the original URL be the public URL.

Alternate access mapping integration with authentication providers

Alternate access mappings allow you to expose a Web application in as many as five different zones, with a different IIS Web site backing each zone.

Note

Some people mistakenly refer to this as having up to five different Web applications sharing the same content databases. 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 also allow you to use multiple authentication providers to access the same Web application.

When extending a Web application into a zone, you have to use Windows authentication provided by IIS. After the Web application has been extended into the zone, you can modify the zone to use a different type of authentication.

Use the following procedure to modify the authentication configuration for a zone.

Modify the authentication configuration for a zone

1. From Administrative Tools, open Central Administration.

2. On the Central Administration home page, click Application Management.

3. On the Application Management page, in the Application Security section, click Authentication providers.

4. On the Authentication Providers page, select your Web application, listed in the Web Application box.

5. Click the name of the zone whose authentication configuration you want to modify.

   Note

   You will only be able to select from among zones that have a backing IIS Web site. These zones were assigned an IIS Web site during the "Extend an existing Web application" procedure.

6. On the Edit Authentication page, in the Authentication Type section, select the authentication type you want to use for this zone:

   • Windows

   • Forms

   • Web single sign on

7. Modify any other authentication configuration settings that you want to change and click Save.

At this point, you can change authentication configuration settings for any other zone as well. You can configure completely independent authentication settings for different zones accessing the 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. In addition, you can have different types of accounts to access the same content: one zone can be configured to use Windows Active Directory accounts while another zone can be configured to use non–Active Directory accounts with ASP.NET forms-based authentication.

Alternate access mapping integration with Web application policies

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 Windows SharePoint Services 3.0 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 has not explicitly given it access to.

Another example would be Helpdesk personnel who need administrative access to Windows SharePoint Services 3.0 sites so that they can assist users. To do this, you can create a Web application policy that grants the Helpdesk 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 have applied to one zone does not 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 have given a Helpdesk staff account Full Control permission over a Web application's zone that has been assigned to the corporate network. If someone were to try to use that account to access the site over the Internet, that Full Control policy would not apply because it would recognize that the URL is in a different zone. Therefore, the account would not automatically be given administrative access to the site.

Alternate access mapping and external resource mapping

Windows SharePoint Services 3.0 allows you to extend the alternate access mapping functionality to content that is not hosted within the Windows SharePoint Services 3.0 farm. To configure this functionality, browse to the Alternate Access Mappings page and click Map to External Resource. You will then be asked to create an entry for an external resource, which you can think of as another Web application. After you have an external resource, you can assign different URLs and zones to it in the same way that you do for Web applications. This feature is not utilized in Windows SharePoint Services 3.0, but third-party products that build on top of Windows SharePoint Services 3.0 can make use of it.

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

Troubleshooting alternate access mappings

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 the request is from 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 also creates a critical error in the Windows event log, and in the Windows SharePoint Services ULS logs, to notify the Windows SharePoint Services administrator to configure alternate access mappings for the unrecognized URL.

Note

Installing the Infrastructure Update for Windows SharePoint Services 3.0 in a Windows SharePoint Services 3.0 farm that uses alternate access mappings with a reverse proxy or a network load balancer, such as in an extranet deployment, may cause some public URLs to become unresponsive. Microsoft is aware of this issue and is developing a solution. Before installing the Infrastructure Update for Windows SharePoint Services 3.0, customers who use this configuration should use a test environment to verify that public URLs remain accessible after the update is installed.

For Windows SharePoint Services 3.0 to provide a robust and stable API that can work on multiple computers, even computers where the Web application service is not running, the resolution of URLs to sites cannot rely on hosts files, DNS, or IIS bindings. Instead, when Windows SharePoint Services 3.0 receives a request, it will only use alternate access mappings to perform URL resolution. While it is necessary to make sure your hosts files, DNS, and IIS bindings are properly configured to ensure that Web requests can reach the Windows SharePoint Services 3.0 server, it is also necessary to configure the URLs for alternate access mappings, as shown in the following examples.

Fully Qualified Domain Name (FQDN)

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.

Note

If the URL is internal, make sure that you have configured the URL of the end user as the public URL in the same zone.

Localhost

Localhost is a special host name that enables you to type https://localhost in your browser and reach the Web site hosted on your local computer. However, because localhost is made available by accessing the computer's hosts file, Windows SharePoint Services 3.0 cannot automatically take advantage of it. If you need https://localhost to be a valid URL for Windows SharePoint Services 3.0, you need to enter https://localhost as an alternate access mapping.

IP addresses

If you are in an environment in which there is no DNS or hosts name resolution, and you are just using URLs with IP addresses, you still need to enter those URLs as alternate access mappings.

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 "https://sharepoint" as your Default zone URL and you want to expose it to the Internet as https://www.contoso.com, you might configure your reverse proxy server to forward the requests to https://sharepoint and then add https://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 https://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 https://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. You can leave https://sharepoint in alternate access mappings and still add https://www.contoso.com as your public URL in the Internet zone. You need to add http://sharepoint.perimeter.contoso.com as an additional internal URL in the same zone as your https://www.contoso.com public URL, your Internet zone. By using both in the same zone, Windows SharePoint Services 3.0 can generate the correct links using the public URL for that zone.

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.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

• Planning and architecture for Windows SharePoint Services 3.0, part 2

See the full list of available books at Downloadable books for Windows SharePoint Services.

See Also

Concepts

Configure alternate access mapping (Windows SharePoint Services)