Before publishing SharePoint applications through Forefront Unified Access Gateway (UAG), make sure you are familiar with the following:
- Known issues and
limitations—Describes the known issues and limitations that you
may encounter when publishing SharePoint applications through
- Alternate access
mappings—How you can use alternate access mappings when
publishing SharePoint applications through Forefront UAG.
- Public host
names—How to set up your host names to ensure that your
alternate access mappings work correctly.
certificates—The server certificate requirements for your
- About rich clients and
MSOFBA—How to enable rich clients to bypass trunk
authentication, and how to use Microsoft Office Forms Based
Known issues and limitations
- To provide clientless access to SharePoint
sites, the domain of the SharePoint site must be in the Trusted
Sites list of Internet Explorer, and Internet Explorer must be
configured so that the Trusted sites zone does not run in protected
mode. In this configuration, end users can log on to the site using
single sign-on (SSO). If the SharePoint site is not in the Trusted
Sites list, end users cannot log on using SSO.
- The Forefront UAG Endpoint Session Cleanup
component should be running on client endpoints.
- SSO does not work when end users attempt to
open documents on a SharePoint site using a non-Internet Explorer
- You cannot change the Logoff URL on
the Authentication tab of the Advanced Trunk
Configuration to point to a SharePoint site URL.
- If you publish a SharePoint 2010 application,
after end users sign in to the SharePoint site, they cannot sign in
as a different user after clicking Sign in as Different
- When end users double-click the SharePoint
2010 application in the Forefront UAG portal toolbar or menu, they
might receive a JScript error. As a workaround, users should open
the application using the application icon that appears in the
portal, or you can publish SharePoint using AAM so that users can
access the application directly.
- When end users access a SharePoint 2010 site
from a mobile device using the Office Mobile client, to allow the
device to download documents from a SharePoint site, you must make
the following URL set changes:
- In the Forefront UAG Management console, open the Advanced
Trunk Configuration dialog box, and click the URL Set
- In the URL list, scroll to InternalSite_Rule54,
and in the Methods column, add the HEAD method.
- In the URL list, scroll to
SharePoint14AAM_Rule47, and in the Methods column,
add the HEAD method.
- On the Advanced Trunk Configuration dialog box, click
OK, and then activate the configuration.
- In the Forefront UAG Management console, open the Advanced Trunk Configuration dialog box, and click the URL Set tab.
- When end users open an Excel file on a
SharePoint site from their mobile device, the file opens correctly.
If they then go to a different SharePoint site, the first time they
try to open an Excel file it may not open as expected; end users
must click the file again to open it.
- In some circumstances, when Office clients
access Office files published via Forefront UAG with a browser
using the WebDAV user agent, client authentication might not work
as expected. In Office 2007, clients might be continuously prompted
for credentials. In Office 2010, clients may be prompted three
times for credentials before the requested file is opened.
- When you use endpoint policies to prevent
users from uploading documents to your SharePoint sites, users are
unable to do the following:
- Uploading a new document through a web
- Checking in a new version of a document.
- Creating a new document by clicking
New or New Document on the SharePoint site.
- Editing and saving a document on the
SharePoint site. For example, clicking Edit in Microsoft
Word for a previously uploaded Word document, or adding a
picture or a macro to the document and clicking Save.
- Uploading a new document through the
Microsoft Office Upload Center or SharePoint workspace.
- Uploading a new document through a web browser.
- If you allow rich clients to authenticate
directly with the SharePoint site’s authentication server or if you
allow MSOFBA, when end users attempt to access files in their
client application, the files may not open. This can occur when
they attempt to access files using the Open dialog and in
File name they enter the full path of the file (including
the file name). In this case they may receive multiple credential
requests and the file may not open. Instead, users should enter
only the path of the file they want to open, press ENTER, and then
in the file list, they should double-click the file.
Alternate access mappings
Alternate access mappings (AAM) enable SharePoint Server 2010 and SharePoint Server 2007 to map Web requests to the correct Web applications and sites, and they enable the SharePoint Server to serve the correct content back to the user. For example, in a setup where internal users access a SharePoint site at http://hr/ and remote users access the same SharePoint site at https://HRportal.woodgrovebank.com through Forefront UAG, the SharePoint Server replies to both internal and remote users with identical content. The Forefront UAG server responds with identical content, even though external users submit a protocol (HTTPS) and a host header (HRportal.woodgrovebank.com) that are different from the protocol and host header submitted by internal users. For additional information about alternate access mappings, see Plan alternate access mappings (Office SharePoint Server) (http://go.microsoft.com/fwlink/?LinkId=153460).
|Forefront UAG supports alternate access mappings in SharePoint Server 2007 and SharePoint Server 2010. Alternate access mappings are not relevant for earlier versions, such as SharePoint Portal Server (Office 2003 version). If you want to publish earlier versions, you must use the Office SharePoint Portal Server 2003 application.|
|Users can also access SharePoint sites directly, without passing through the Forefront UAG portal, by using the public host name that you assign when you add the application to the portal.|
Public host names
When you publish SharePoint Products and Technologies via Forefront UAG, each SharePoint Web application is associated with a unique public-facing host name, which is used to access the application remotely.
A SharePoint Web application that is published through the Forefront UAG trunk shares the trunk's definitions in addition to some of the trunk's functionality, such as the logon and logoff pages. This means that the application's public host name must reside under the same parent domain as the trunk's public host name; that is, the application and the trunk are subdomains of the same parent domain.
The following table shows sample public host names of Forefront UAG trunks, and the valid and non valid public host names for the SharePoint Web applications that you publish through each sample trunk.
|Forefront UAG trunk’s public host name||Trunk’s parent domain||Examples of valid public host names for SharePoint Web application||Examples of non valid public host names for SharePoint Web application|
When you select an application's public host name, you must also consider the limitations that are associated with the trunk's server certificate. For information about server certificates, see About server certificates.
During the initial configuration of an HTTPS trunk in Forefront UAG, you select the trunk's server certificate. All the public host names that are used in the trunk must be covered by this certificate, including the trunk's public host name and the public host names of all the applications that are accessed via the trunk.
The following types of certificates support multiple host names:
- Wildcard certificate—Covers all host
names that are in a given domain level; it does not cover names
that are in any of the domain's superdomains or subdomains. For
example, the certificate *.woodgrovebank.com covers the host names
uag.woodgrovebank.com and HRportal.woodgrovebank.com because they
are both on the same domain level, but it does not cover the host
name HRportal.uag.woodgrovebank.com, which is a subdomain in the
Note: Forefront UAG does not support certificates with four-level domain names; for example, sp.uag.woodgrovebank.com.
- Subject Alternative Name
certificate—Includes a primary domain and a list of other
domains that are covered by the certificate. There is no difference
between the primary and secondary domain, and there is no
limitation on the number of host names that you can use. Note,
however, that if host names are added to or removed from the trunk,
you must issue and select a new certificate for the trunk.
For information about how to import a certificate into Forefront UAG, see HOW TO: Install Imported Certificates on a Web Server in Windows Server 2003 (http://go.microsoft.com/fwlink/?LinkId=153459), and then follow the described procedures to:
- Install the Certificates.
- Import the Certificate into the Local
|Do not follow the procedure "Assign the Imported Certificate to a Web Site"; you assign the certificate to the Forefront UAG Web site when you create or edit the Forefront UAG trunk through which you publish the SharePoint Web application.|
About rich clients and MSOFBA
When publishing SharePoint applications in your portal, rich clients can authenticate directly with the SharePoint site’s authentication server, instead of authenticating to the portal and then opening the SharePoint site. This type of authentication uses basic authentication.
In addition, if end users access your published SharePoint applications by using certain rich clients you can use MSOFBA. MSOFBA is a protocol that provides forms based authentication, instead of basic authentication, when you use Office client applications.
When rich clients authenticate directly using basic authentication or MSOFBA, end users can open Office documents that are published on your SharePoint site directly from the client application, without using the Forefront UAG portal. If rich clients authenticate directly with the SharePoint site, when an end user attempts to open an Office document that is published on your SharePoint site, a credentials dialog box appears allowing the user to authenticate against the authentication server defined for your published SharePoint site. When using MSOFBA, when an end user attempts to open an Office document that is published on your SharePoint site, a login page (the portal login page) appears.
To allow rich clients to authenticate directly to your SharePoint application, on the Authentication page of the Add Application Wizard, select the Allow rich clients to bypass trunk authentication check box. To use MSOFBA, you must also select the Use Office Forms Based Authentication for Office client applications check box.
When you select these check boxes, the behavior (basic authentication or MSOFBA) is applied to all SharePoint applications that you publish in the trunk.
|If you use different authentication servers for each SharePoint application, after end users access files on one SharePoint site, they must close their Office client application before they can access files on the other SharePoint site.|
|If you configure your SharePoint applications to use MSOFBA, you should ensure that the SharePoint site is not configured to use forms-based authentication.|
Client endpoint requirements
In order to use MSOFBA for end users to authenticate to your published SharePoint application, end user computers must be running one of the following operating systems:
- Windows 7.
- Windows Vista.
- Windows XP with Service Pack 3 or
Windows XP with Service Pack 2.
Note: For computers that are running Windows XP, you must also install Internet Explorer 8.
MSOFBA is supported only with the following releases of Microsoft Office:
- Microsoft Office 2010
- Microsoft Office 2007 with Service
Note: For computers using Office 2007, you must also install the hotfix described in the following knowledge base article: You cannot use 2007 Office applications to open or edit content in a Web application that uses forms-based authentication.