Tag Archives: mappings

Coordinating URLs with AAM and DNS

Mark Arend, Senior Consultant, raised several good questions about coordinating URLs with alternate access mappings and DNS:

  • How do you configure alternate access mappings for single-name URLs, such as http://fabrikam?
  • How do you coordinate load-balanced access to Web applications that are extended with multiple zones, such as http://partnerweb and https://remotepartnerweb.fabrikam.com?

Configuring alternate access mappings can be tricky. After some research and consulting with our astute testers, Troy Starr, as well as working with Mark, I put together the following chart that lists the necessary information for creating or modifying alternate access mappings based on the classic authentication version of the logical architecture design sample.

As you can see, single-name URLs (for example, http://teams) can be configured for Intranet access.  These URLs are resolved by the client by appending the client’s DNS suffix, such as fabrikam.com, and then issuing a DNS lookup for the name with the suffix.  For example, when a client computer in the fabrikam.com domain requests http://teams, the computer sends a request to DNS for http://teams.fabrikam.com. 

In addition to configuring alternate access mappings, some DNS work is necessary as well. DNS must be configured with an A record for each Fully Qualified Domain Name (FQDN). The A record points to the load balanced IP address for the Web servers hosting a site. In a typical production deployment, servers are configure with statically assigned IP addresses, as well as statically assigned A records in DNS. 

After receiving the virtual IP address of the load balancer, the client browser establishes communication with a front-end Web server in the farm, then sends an HTTP request with the original single-name URL, http://teams.  IIS and SharePoint recognize this as a request for the Intranet zone, based on the settings configured in alternate access mappings.  If the user had instead requested https://teams.fabrikam.com, the process would be the same except IIS and SharePoint would receive this FQDN instead, and therefore recognize this request for the Default zone.

In environments with multiple domains, enter CNAME records for DNS in the domains that the sites do not reside in. For example, if the Fabrikam network environment includes a second domain called europe.fabrikam.com, CNAME records are entered for these sites in the Europe domain. For the Team Sites intranet site (http://teams), a CNAME record called teams is added to the europe.fabrikam.com domain that points to teams.fabrikam.com. Then, when a client’s DNS suffix is appended to DNS lookup requests, a request for http://teams from the Europe domain will issue a DNS lookup of teams.europe.fabrikam.com, and be directed by the CNAME record to teams.fabrikam.com.

After learning about how URLs are resolved by the browser, I realized that http://fabrikam is not a great choice for an illustrative URL (http://fabrikam.fabrikam.com?). Consequently, I updated the classic authentication version of the logical architecture design sample with the URL of http://intranet instead. You can download the updated version at  SharePoint Server 2010 design samples: Corporate portal with classic authentication or with claims-based authentication (http://go.microsoft.com/fwlink/?LinkId=196872).

Finally, there is a known issue with some Kerberos clients and resolving CNAME records. If your environment includes Kerberos authentication,  see Kerberos configuration known issues (SharePoint Server 2010).

Read More

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


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.

listener highlighted.PNG

The end user’s URL is comprised of the public protocol, the public hostname, and the public port number.


Public Protocol




Public Hostname




Public Port Number


Public URL





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.

bridging highlighted.png 

The SharePoint server’s URL is comprised of the internal protocol, the internal hostname, and the internal port number.


Internal Protocol




Internal Hostname




Internal Port Number


Internal URL





extend web application highlighted.png

Great – we’ve properly set up this reverse proxy server to receive web requests from end users at https://www.contoso.com and forward them to your SharePoint server at http://sharepoint.dmz.contoso.com. 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.

AAM after.png

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.

AAM after.png

All done! Now, when a user browses to https://www.contoso.com, the web request will be received by the proxy server and forwarded to http://sharepoint.dmz.contoso.com. SharePoint will then receive the web request, see that the URL of the request is http://sharepoint.dmz.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.dmz.contoso.com URL is assigned to the Internet zone, SharePoint will also generate links on the pages using the public URL for that zone – https://www.contoso.com. 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

Published: 8/16/2010 12:52 PM

Read More