Freigeben über

Publishing SharePoint with IAG 2007 – Part 1: What is SharePoint AAM and why do we need it?

  • Artikel

Hi,

My name is Meir Mendelovich and as a Program Manager in the IAG product group I’m responsible for SharePoint publishing. Over the last year IAG has made a tremendous leap in its SharePoint publishing capabilities. In May 2008 we released an update that introduced a new publishing mechanism and we are continuing to improve it.

In this post series I will elaborate on how this new publishing mechanism works, and will try to explain the logic behind it. I’ll also review some advanced SharePoint configuration options, and the implications for IAG.

Parallel with this blog post series, our User Assistance team recently updated our TechNet content with detailed step-by-step planning and deployment guides for SharePoint publishing.

 

Let’s start with the question in the post title, “What is SharePoint AAM and why do we need it?” As you know, starting with IAG SP1 Update 2 you can publish SharePoint using two application templates:

1. SharePoint Server 2007

2. SharePoint Server 2007 (Backward Compatibility)

The second template (Backward Compatibility) is the old method that works like most of IAG applications - whereby IAG analyzes the HTML content that is returned from the application and rewrites the links (a.k.a. link translation, link signature, HAT) so that they point to the IAG external address rather than the application internal address. Here‘s a description of the traditional application publishing mechanism:

IAG Link translation without AAM

What is SharePoint AAM?

AAM (Alternate Access Mapping) is a method that allows a server to perform URL changes on its own, so that reverse proxies such as IAG don’t have to change the content of the pages they serve to external sources.

Using AAM the SharePoint server replies with a page that already contains the public, resolvable from the Internet, URL (“https://HRPortal.contoso.com/b” in the example below) rather than the URL that is used internally (e.g. “https://HRPortal/b”). Each such public URL defines an “AAM zone”. There are up to five AAM zones available in the SharePoint configuration. Each zone has a unique name like “Intranet”, “Extranet” and “Custom”, although from a functional standpoint they are identical and it isn’t important which one is used.

SharePoint selects the AAM zone for each HTTP request according to the HOST header, protocol (HTTP or HTTPS) and port. Each combination of request parameters is defined by an “internal URL” definition. Each AAM zone has one or more internal URLs.

Every time an HTTP request is received, the SharePoint server attempts to match the request to one of the AAM zones’ internal URLs. When the HTTP response to this request is rendered, all the embedded links within it are formatted according to the external URL of that specific zone.

This drawing shows an example for such configuration:

 

IAG link translation with AAM

 

Why do we need AAM?

AAM was created to support scenarios in which several different URLs are used to access the same content. This occurs with components such as load balancers, and with reverse proxies such as IAG. AAM is required in these scenarios because trivial link translation mechanisms fail. They fail because some of the links are embedded into ActiveX components, which cannot be rewritten by the link translation mechanism, or links are composed by scripts running on the client-side, so after the content has already passed through the link translation mechanism. Products that publish SharePoint 2007 without AAM experience reduced SharePoint functionality, with some SharePoint components not working as expected. This is mainly true for:

· Datasheets

· Explorer view

· InfoPath forms

· Office integration

· Excel Services

· Dashboards

I have seen a number of SSL VPN products that attempt to publish SharePoint without AAM and they all fail when publishing most of the above scenarios.

 

What to remember about publishing SharePoint with AAM

1. Select a new unique external URL to be used for accessing the SharePoint server. This URL is not identical to the IAG trunk’s URL although they must belong to the same parent domain. See an explanation about the domain names here.

2. After publishing SharePoint server using the new template, the SharePoint server AAM settings must be updated with the new external URL. See a step-by-step explanation here.

3. The trunk’s SSL certificate should include the new domain - as explained here.

4. The new domain should be registered on a public DNS server.

Comments