• 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 browser.
  
  
• 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 User.
  
  
• 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:
  
  
  1. In the Forefront UAG Management console, open the Advanced Trunk Configuration dialog box, and click the URL Set tab.
     
     
  2. In the URL list, scroll to InternalSite_Rule54, and in the Methods column, add the HEAD method.
     
     
  3. In the URL list, scroll to SharePoint14AAM_Rule47, and in the Methods column, add the HEAD method.
     
     
  4. On the Advanced Trunk Configuration dialog box, click OK, and then activate the configuration.
     
     
• 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 browser.
    
    
  • Checking in a new version of a document.
    
    
  However, regardless of the endpoint policy that you apply, the following actions are not blocked:
  
  
  • 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.
    
    
• 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 (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).

Note:
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.

Note:
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

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 domain *.woodgrovebank.com.
  
  

  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 Computer Store.
  
  

Note:
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.

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.

Important:
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.

Note:
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