Microsoft Forefront Unified Access Gateway Product Team Blog : Sharepoint Publishing

Enabling SharePoint bookmarking for SharePoint AAM Optimizer in IAG SP1

edgeaccessblog — Sun, 08 Feb 2009 11:16:00 GMT

General

Starting with Intelligent Application Gateway (IAG) 2007 Service Pack 1 (SP1), IAG includes an optimizer for publishing SharePoint Products and Technologies with alternate access mapping (AAM). In IAG 2007 SP1, the optimizer uses HTML frame to publish SharePoint via IAG, thus preventing users from bookmarking URLs in SharePoint sites. In IAG Service Pack 2 (SP2), frames are no longer used by the SharePoint optimizer, and users can use SharePoint bookmarks.

This article describes how to disable the HTML frame in IAG SP1.

Implementation Procedure:

All the changes in the files have to be made using the IAG CustomUpdate mechanism, as follows:

1. Copy the file you wish to customize from the folder where it is installed by default to the CustomUpdate subfolder that is nested under it.

2. If you want the changes you make to affect all trunks, copy the file without renaming it. This is always the method you should apply for Web Monitor changes; because the Web Monitor monitors all the trunks in IAG, it cannot be customized per trunk.

If you want the changes you make to be applied to a single trunk, rename the file: <Trunk_Name><Secure(0=no/1=yes)><OrigFile.extension>

Where:

· <Trunk_Name> is the name of the trunk where you want the changes to take effect.

· <Secure(0=no/1=yes)> : enter 1 for an HTTPS trunk or 0 for an HTTP trunk.

· <OrigFile.extension> is the name of the original file, including file extension.

The following steps are required:

1. In the application's Portal Link page, uncheck the option Startup Page

2. Fix a Rule set.

Change Internal Site ruleset 34 from

/internalsite/sharepointredirector\.asp To /internalsite/(sharepointredirector|sharepoint)\.asp

3. Add a section to the AppWrapfile (found under \Whale-Com\e-Gap\von\conf\wizarddefaults\appwraptemplates )

Under the whlsp2007.sp section add this <SAR> :

<SAR>

ZGh0bWxMb2FkU2NyaXB0KCJXaGxPd25VUkxzaGFyZXBvaW50LmFzcD9zaXRlX25hbWU9V2hsU2l0ZU5hbWUmc2VjdXJlPVdobFNlY3VyZSIpOw0KZnVuY3Rpb24gZGh0bWxMb2FkU2NyaXB0KHVybCkNCnsNCg0KICAgdmFyIGUgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCJzY3JpcHQiKTsNCiAgIGUuc3JjID0gdXJsOw0KICAgZS50eXBlPSJ0ZXh0L2phdmFzY3JpcHQiOw0KICAgZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoImhlYWQiKVswXS5hcHBlbmRDaGlsZChlKTsgDQp9DQo=</REPLACE>

</SAR>

4. Add a section to the SRA file. (found under <Install Dir>\Whale-Com\e-Gap\von\conf\SRATemplates ) Under the sharepoint2007AAM section

Change the core.js to be

<SEARCH encoding="base64">dG9wLmxvY2F0aW9uPXVybDs=</SEARCH>

<REPLACE encoding="base64">d2luZG93LmxvY2F0aW9uID0gdXJsOw==</REPLACE>

<SEARCH encoding="base64">dmFyIGl0ZW1UYWJsZURlZmVycmVkPW51bGw7</SEARCH>

dmFyIGl0ZW1UYWJsZURlZmVycmVkPW51bGw7DQovL2luc2VydHNw</REPLACE>

</URL>

5. Contact support to obtain the file sharepoint.asp and place it under the internalsite folder.(found under: <Install Dir>\ Whale-Com\e-Gap\von\InternalSite )

6. Activate the configuration.

7. Access the SharePoint AAM.

8. Check that now SharePoint URLs are shown and that you can use bookmarks.

9. Verify that Office integration is working. Open an Office document from SharePoint and verify you can see its content.

Author

Dror Malovany

Application Engineer – UAG Team

Microsoft

Publishing SharePoint with IAG 2007 – Part 3: SharePoint Topologies

edgeaccessblog — Mon, 13 Oct 2008 22:05:00 GMT

In this post I will review several SharePoint topologies and discuss how they influence IAG and AAM settings. For each topology I’ll explain the considerations and provide sample configurations. For complete step-by-step configuration guide, please use this TechNet article.

These topologies are simplification of much more complexed SharePoint topologies that are detailed in this SharePoint article along with IAG network location related to the SharePoint machines.

Publishing a SharePoint Web application – HTTP internal

This is the baseline topology for SharePoint publishing and it is the most common one. In this topology several SharePoint applications may be published from a single IAG trunk, and each application has a unique server and port. It is assumed that HTTPS is used externally outside the corporate network, and HTTP is used within the corporate network.

In order to publish SharePoint in this topology, the applications should be defined on the IAG trunk with a proper public host name, and a new AAM zone should be defined on the SharePoint server to support the external address.

HRPortal Application Settings

Web Server Address: HRPortal

Web Server Port: 80 (HTTP)

Public Host Name: HRPortal.contoso.com

Replace Host Header: Empty

Example for a configuration of such topology:

Semantics for all the drawings:

Grayed – Default configuration that should not be added or changed by the admin

Bold – Configuration that is unique to this topology or requires special attention

Publishing a SharePoint Web application – HTTPS internal

This topology is almost identical to the baseline. The only difference is that HTTPS is used both in the corporate network as well as over the Internet.

Publishing multiple SharePoint Web applications

This topology is also similar to the baseline. The only difference is that one of the applications is published on a non-default port. In this case the port number should be defined in the IAG application, and embedded in the URLs of the AAM zone.

Publishing multiple SharePoint Web applications on a single port

This topology assumes that there are several SharePoint Web applications published on the same port. In this case, the SharePoint server differentiates between the applications using the host header in the HTTP request.

In this topology, IAG is published in a similar manner to the baseline topology. But, there is one thing that is important to remember - when configuring the Web server address in IAG, it is important to put the SharePoint WebApp address (“HRPortal” and “Teams” in this example) rather than the actual SharePoint machine name or IP address so in every IAG application there is a unique Web server address.

Publishing a SharePoint Web application when using identical internal and public addresses

This topology refers to organizations that use the same URL for internal and external access to SharePoint (and usually with other applications), but use HTTP for internal traffic and HTTPS for external traffic. If HTTPS is used both internally and externally no additional configuration is required. In fact, in this case no AAM configuration should be made.

When publishing SharePoint in this topology, IAG has to “signal” to SharePoint that this request has to be replied to with HTTPS links rather than HTTP links. This “signal” is passed by replacing the host header with a bogus host header that is configured in one of the AAM zones.

Publishing a single SharePoint Web application via multiple IAG trunks

In this topology two IAG trunks are publishing the same SharePoint Web applications. Hence the same SharePoint Web application has two different external addresses.

In order to do this, two different AAM zones should be defined on the SharePoint server with two different external URLs.

Publishing SharePoint with IAG 2007 – Part 2: Common Questions

edgeaccessblog — Mon, 13 Oct 2008 21:44:00 GMT

Hi,

SharePoint publishing with IAG is a very popular scenario. Here is a list of common SharePoint publishing questions and issues I was frequently asked about during the last months:

· I can’t edit SharePoint datasheets / explorer view / other SharePoint functionality when it is published by IAG.

You have to install IAG 2007 SP1 update 2 or above on your IAG server. This update will also be incorporated into IAG 2007 SP2.

· I installed IAG 2007 update 2 and it still has the old limitations

Just installing the update is not enough. By default, after the update installation, existing SharePoint applications use the “backward compatibility” template to ensure that we don’t break anything until AAM is configured. After configuring the SharePoint server’s AAM settings, updating the trunk’s SSL certificate, and registering the new entry in DNS, you should remove from your portal trunk the old SharePoint application and publish it again by using the new template.

· Does such an update exist for the e-Gap v3.6 appliance?

Yes, e-Gap 3.6 update 2 has almost the same functionality as IAG 2007 SP1 update 2. Look here for more details.

· I see no difference between the “old” and the “new” templates

The two templates look almost the same. The main difference is two new fields in the Web Servers tab (highlighted in the screenshot):

· Public host name – Defines the external domain name that would be used for publishing this SharePoint application. See here which domains could be selected.

· Replace host header – Used for advanced scenarios as will be explained in part 3 of this blog post.

· Do I need a new SSL certificate?

An IAG trunk with a SharePoint application that is published using AAM has new external domains. These domains should be covered by the trunk’s SSL certificate. See this TechNet article about which type of SSL certificates should be used.

· Can I publish SharePoint without AAM?

Yes. If there are problems with getting certificates or DNS registration for the new domain names you can still use the “Backward Compatibility” template, though you should expect some SharePoint functionality will not work.

· Can I access the new SharePoint domains directly without going through the portal?

Yes! When publishing SharePoint by using the new application template and leveraging AAM, the SharePoint domains (e.g. HRPortal.contoso.com) can be accessed directly without going first via the portal. In this case IAG will prompt the user for login and then, after successful authentication, return the user to the requested page. IAG will present the trunk’s customized version of the login pages, so no special customization is required.

· If I start a session with one of the SharePoint domains, can I continue to other applications without logging in again?

Yes! You can start a session by accessing directly one of the SharePoint servers (e.g. “https://HRPortal.contoso.com/site1”) and then follow a link to another application that is published via the same IAG trunk without logging in again. The IAG single sign-on (SSO) experience still works.

· What additional functionality is provided by the IAG SharePoint application template?

As with the other application templates, the IAG SharePoint application template allows the administrator to enable or disable the following SharePoint functionality based on the health of client endpoints:

· Uploading, checking in files, and saving files from Microsoft Office applications

· Downloading files, exporting to a spreadsheet, or editing datasheets

· Access to sensitive areas of the application

· Access from the SharePoint Web application to third-party applications

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

edgeaccessblog — Sun, 12 Oct 2008 18:47:00 GMT

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:

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. “http://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:

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.