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.
Image may be NSFW.
Clik here to view.
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 |
|
HTTPS |
www.contoso.com |
443 |
https://www.contoso.com |
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.
Image may be NSFW.
Clik here to view.
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 |
|
HTTP |
sharepoint.dmz.contoso.com |
80 |
http://sharepoint.dmz.contoso.com |
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
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