Forefront Unified Access Gateway (UAG) supports many rich client applications by default. To use these applications, you must configure the user agent so that Forefront UAG can recognize the rich client when it attempts to connect to the application server. There are two main scenarios in which you might want to customize or add a user agent:

This topic describes how to add or modify user agents for rich client applications.

To customize user agents for rich client applications

  1. On the Forefront UAG server, locate the file ...\Microsoft Forefront Unified Access Gateway\von\Conf\WizardDefaults\AgentDefaultParam.ini.

    By default, this file contains the predefined definitions for SharePoint 2010 and SharePoint 2007 applications.

  2. To add a new user agent declaration, create an entry in the file based on the following, and modify it as required:

      Copy Code
    [Agent2]
    Id=SP1
    EnabledAppTypes=SharePoint2007AAM,SharePoint14AAM
    NumOfHeaders=1
    RichClientsCheck=1
    HeaderName1=User-Agent
    HeaderValue1=MSFrontPage
    CompMethod=VALUE_CONTAINS
    AuthScheme=Basic
    ErrorType=HTMLErrorPage
    SupportMsOfba=1
    
    • Id—Enter a unique ID for the application.

    • EnabledAppTypes—This value maps the defined application types to the agent definition. This value must contain the application types defined in the WizardDefaultParam.ini file that is located in the same folder as the AgentDefaultParam.ini file.

    • NumOfHeaders—Enter the number of headers to be included.

    • RichClientsCheck—Enter ‘1’ to check if the check box was selected.

    • HeaderName1—Enter the header name, which determines the agent to be used for authentication. The header name can be any HTTP header, for example, a user agent or a URL. For each of the headers that you will use (defined in NumOfHeaders), add another HeaderNameX parameter.

    • HeaderValue1—Enter the header value for the user agent. The header value can be either a string specifying the user agent, or a URL. For each of the headers that you will use (defined in NumOfHeaders), add another HeaderValueX parameter.

    • CompMethod—Enter the method by which the agent is compared with the header name. There are three possible values: NAME_EXISTS | VALUE_EQUALS | VALUE_CONTAINS.

    • AuthScheme—Enter the method by which this agent will be authenticated. The possible values are:

      • Negotiate Kerberos, NTLM—Both Kerberos and NTLM blobs created for 401 negotiate responses are accepted. Pure NTLM (not negotiate) is also accepted.

      • Negotiate Kerberos—Only Kerberos tickets are accepted as part of the negotiation steps (401 negotiate).

      • Negotiate NTLM—Only NTLM tickets are accepted as part of the negotiation steps (401 negotiate). Pure NTLM (not negotiate) is also accepted.

      • Basic—Using this scheme, an HTTP 401 response is sent, and a dialog box opens in which end users can enter their credentials.

      • Anonymous—An HTTP 401 response is not sent. End users are immediately treated as authenticated and are rerouted to the login page.

    • ErrorType—This parameter determines the error handling to be used. Enter either:

      • HTMLErrorPage—An HTTP 200 OK page is sent as a response to the client containing an HTML page with the error message.

      • HTTPErrorCode—An HTTP error code (such as 500, 404 etc.) is sent as response. This is used for non-browser traffic, for example, for OutlookAnywhere and or ActiveSync clients.

    • SupportMsOfba—Enter 1 if this user agent can be used with Microsoft Office Forms Based Authentication (MSOFBA); enter 0 if it cannot be used with MSOFBA.

      Important:
      If you publish Exchange and SharePoint applications on the same trunk, you must set this parameter to 0 for the following user agents:
      • Microsoft Office/12.0

      • Microsoft Office/14.0

      • Microsoft Office Outlook