White Paper

Publishing Exchange Server 2010 with Forefront UAG and

Forefront TMG
Standard Publishing Scenarios
Greg Taylor, Senior Program Manager, Exchange Server
Date: November 2010

Contents
Executive Summary................................................................................................ 1
Choosing Between Forefront TMG or Forefront UAG................................................3
Basic Forefront TMG and/or Forefront UAG Concepts..............................................4
Common to both Forefront TMG and Forefront UAG.............................................4
Forefront TMG Concepts....................................................................................... 5
Forefront UAG Concepts....................................................................................... 6
Exchange Publishing Scenarios...............................................................................8
Publishing Outlook Web App, Outlook Anywhere, and Exchange ActiveSync
Using Forefront TMG............................................................................................. 8
Publishing Outlook Web App, Outlook Anywhere, and Exchange ActiveSync
Using Forefront UAG........................................................................................... 42
Appendix.................................................................................................................. 80
Using Alternative Authorization and Access Providers.......................................80
Additional Information........................................................................................... 86
Legal Notice.......................................................................................................... 86

Executive Summary
By allowing remote access to Microsoft Exchange to users who are based outside
the safety of the corporate network, an organization enables its employees to take
full advantage of the technology their company provides. Remote access lets
employees use many devices to communicate with their peers and customers from
any place and at any time.
Allowing access to corporate resources from any location, perhaps using devices
that are not controlled by the organization, presents additional risk to the security of
the data and services being accessed. Therefore it's critical to take measures to
ensure that the data is being accessed securely, which means implementing
2

technologies such as certificates, firewalls, enforcing pre-authentication, and device

or endpoint validation. The key concept to understand is that applying security to
any solution is a multi-layered task that includes identifying the threats, reducing
the attack surface area, removing unnecessary access points, and enforcing
authentication. The casual attacker will usually give up after a few failed attempts
to access a resource.
When you publish Exchange, Microsoft offers two software-based options: Microsoft
Forefront Threat Management Gateway 2010 (Forefront TMG) and Microsoft
Forefront Unified Access Gateway 2010 (Forefront UAG). Both options offer
publishing wizards and security features to provide secure access to Exchange when
it's accessed from outside the safety of the corporate network.
There are other ways to publish Exchange besides using Forefront TMG or Forefront
UAG. This technical guide isnt intended to provide the only information you use for
a complex organization or one with special security constraints. Instead, its
intended only as a walkthrough to help you publish Exchange on both these
platforms, using basic configuration options. If you have a large organization, its
likely that youll need additional applications or have to factor in additional security
considerations. Such applications and security considerations are beyond the scope
of this document.
This white paper provides detailed information about publishing Microsoft Exchange
Server 2010 using Forefront TMG or Forefront UAG, including how to choose
between them for different scenarios, and provides specific steps you can take to
configure Forefront TMG and Forefront UAG to publish Exchange 2010.
Document Reviewers:
Jim Harrison
Michel Biton
Ross Smith IV
Fernando Cima
Ramon Infante

Choosing Between Forefront TMG or Forefront UAG

Your first decision when planning to publish Exchange using Forefront TMG or
Forefront UAG is to determine which of the two products best fits the needs of the
deployment.
Both Forefront TMG and Forefront UAG can securely publish Exchange to the
Internet, but each offers some features or supports scenarios that the other does
not. So, the first step in choosing which product to use is deciding what features you
need or think you may need.
Some deployments may actually use both Forefront TMG and Forefront UAG to
satisfy specific requirements. For example, you might use Forefront UAG to provide
a unified portal experience for your inbound Web-based client access, use Forefront
TMG to protect Internet access for your internal users, and use Forefront TMG to
provide certificate-based authentication to your mobile device-enabled workforce.
Exchange Related Deployment Scenario or Feature

Forefro
nt TMG

Forefron
t UAG

Publish Microsoft Office Outlook Web App and the

Exchange Control Panel (ECP) using forms-based
authentication
Publish Outlook Anywhere using Basic or NTLM
authentication
Publish Microsoft Exchange ActiveSync using Basic
authentication
Provide load balancing for HTTP-based protocol
accessing from the Internet
Support two-factor authentication for Outlook Web
App

Support two-factor authentication for Exchange

ActiveSync
Provide certificate-based authentication for Exchange
ActiveSync, Outlook Web App, and ECP
Perform mail hygiene for Exchange with installation of
the Edge Transport server role and Microsoft
Forefront Protection 2010 for Exchange Server
Protect and filter Internet access for internal users
from malware and other Web-based threats
Provide support for scaled up Outlook Anywhere
deployments by using multiple source IP addresses
Check a client computer accessing Outlook Web App
for presence of approved antivirus software, updates,
etc.
Thoroughly clean up the client following an Outlook

Web App session with settings configurable by the

admin

Its recommended that you review the information at the Forefront Threat
Management Gateway 2010: Home Page and the Forefront Unified Access Gateway
2010: Home Page.

Basic Forefront TMG and/or Forefront UAG Concepts

It's important to understand some key concepts and terminology used in Forefront
TMG and Forefront UAG.
Common to both Forefront TMG and Forefront UAG
These concepts or terms are used in both Forefront TMG and Forefront UAG and may
also be used in other products or scenarios.
Farm
A farm is a collection of published servers, such as all the Client Access servers in
one Active Directory site. Even if a deployment currently contains just one Client
Access server, it's usually a good idea to plan and build a farm of one server. Adding
servers to an existing farm in a publishing rule in Forefront TMG is much easier than
converting publishing rules to publish a farm of servers. Forefront UAG treats all
published servers as a farm and makes the additional or removal of servers simple.
Kerberos Constrained Delegation
Kerberos constrained delegation (KCD) is a Windows extension to the MIT-created
authentication protocol, Kerberos V5. In an Exchange publishing scenario, KCD and
protocol transition allows Forefront TMG or Forefront UAG to take user credentials in
Basic, NTLM, Negotiate, or Kerberos certificate or form, then request or translate
that into a Kerberos service ticket on the users behalf from Active Directory, and
then present the service ticket to the Client Access server in order to access the
users mailbox. This service ticket is only for the destination service required and,
therefore, constrained. There are many detailed documents available describing
how KCD and protocol transition function. For more information, see the Protocol
Transition with Constrained Delegation Technical Supplement.
Domain Joining Forefront TMG/Forefront UAG or Leaving in a Workgroup
In most organizations, the decision whether to domain join the server hosting
Forefront TMG/Forefront UAG to your production domain may be one of the more
contentious parts of the deployment.
For Forefront UAG deployments, the guidance is clear. Because Forefront UAG is not
a firewall, it should be placed behind some other device that acts as a firewall on
5

the corporate network. Also, it's recommended that Forefront UAG be domain joined
to make authentication simple and flexible. Forefront TMG is installed on the
Forefront UAG computer during installation, but that's done only to protect the host
system and for the underlying functionality it provides to Forefront UAG.
Forefront TMG deployments are more complex to discuss because Forefront TMG is
considered a firewall and can protect the network edge. Domain joining Forefront
TMG offers many advantages: it allows certificate based authentication to be used
at Forefront TMG, using Kerberos Constrained Delegation to communicate to
Exchange; it allows easy use of Active Directory groups and user objects in
publishing rules to restrict access; and it provides other benefits. For an impartial
view on whether to domain join Forefront TMG, see Debunking the Myth that the ISA
Firewall Should Not be a Domain Member. For more information about identifying
your infrastructure design requirements, see Domain and workgroup requirements.
Even if Forefront TMG is not domain joined, it can use Active Directory as an
authorization and authentication source through the LDAP or RADIUS protocols.
Some additional configuration is required, and those steps are contained in the
appendix of this guide.
The simple scenario walkthroughs discussed within this article assume Forefront
TMG and Forefront UAG are domain joined to the production forest that contains the
Exchange resources being accessed.
Forefront TMG Concepts
These concepts or terms are specific to Forefront TMG.
Listener
A listener is an object in Forefront TMG that ties together several other objects:

At least one IP address, transport and port.

A certificate.
An authentication method. Common examples are Basic, Windows Integrated,
RSA SecurID, and forms-based authentication.

Listeners do have other configuration options such as cookie management, but from
an Exchange publishing standpoint, the listener determines where the public DNS
records that relate to Exchange services should point, the certificate used for
Secure Sockets Layer (SSL) for those connections, and the authentication choices
the user will have. For example, forms-based authentication for Outlook Web App
and Basic authentication for Outlook Anywhere and Exchange ActiveSync.
Publishing Rule
A publishing rule ties a listener, where the connection is accepted, and how it's
authenticated, to the conditions that determine access limitations. In addition, the
6

rule specifies the destination requests that pass the conditions of the rule should be
sent to.
Forefront TMG has many options in each publishing rule that specify whether
Forefront TMG will actually apply that specific rule and whether the request meets
the conditions of the rule. Examples of rules and conditions are as follows:

The paths requested by the client For example, /owa or /autodiscover. A

request for /oaw is not processed by the rule meant for use by Outlook Web
App.
The schedule during which the rule is available The rule can be set to
only respond and process requests at certain hours of the day.
The permission of the user to access the rule Forefront TMG can allow
or deny access based on the user object itself or groups that user is a
member of.

Having such control over each rule lets an administrator apply very fine-grained
conditions to their publishing of Exchange through Forefront TMG. For example, you
can use separate rules for different user groups. This enables you to serve specific
users from different Exchange farms, for example, during a migration process, as
described later in this white paper.
Authentication Delegation
Authentication Delegation is configured on a publishing rule and specifies how
Forefront TMG will authenticate to the server it's publishing. The method specified
by the Authentication Delegation dialog on the publishing rule must match an
authentication method allowed by the Client Access server that Forefront TMG is
publishing.
For example, if TMG is configured to use Basic authentication delegation to an
Exchange server, the corresponding virtual directories on Exchange (/owa, /rpc etc)
must have Basic authentication enabled on them.
Forefront TMG can delegate authentication using a different method than the client
used to authenticate to Forefront TMG. For example, an Outlook Web App client
authenticates to Forefront TMG using forms-based authentication. However,
Forefront TMG can delegate credentials to Exchange by using Basic or NTLM
authentication, or even KCD. For more information, see About authentication in Web
publishing.
Forefront TMG also offers two options: to allow the user to authenticate directly to
the Web server itself (No delegation, but client may authenticate directly) or
to completely prevent delegation (No delegation, and client cannot
authenticate directly). The first of these choices, No delegation, but client may
authenticate directly, allows the client to authenticate directly to the client access
7

server. This can be useful in a certificate-based authentication scenario, where

Forefront TMG is not domain joined, or if you want to use a custom, forms-based
authentication solution on the Client Access server and not enforce any
authentication at Forefront TMG.
Forefront UAG Concepts
These concepts or terms are specific to Forefront UAG.
Trunk
A Forefront UAG portal trunk is a transfer channel that allows clients, or endpoints,
to connect to the trunks portal home page or applications over HTTP or HTTPS.
Portal
A portal is a Web site created by Forefront UAG to provide access to applications
published in a trunk. As soon as the user authenticates to the portal, they can
seamlessly access all applications in the portal without having to re-authenticate.
This is known as single sign-on (SSO).
Endpoint
An endpoint is a Forefront UAG term for a client computer or application. Personal
computers, a Web browsers, and mobile devices are all endpoints to Forefront UAG.

Exchange Publishing Scenarios

This section shows the steps that are required to configure Exchange, Forefront
TMG, or Forefront UAG to meet simple publishing scenarios. These scenarios are
intended as guidance only, and additional steps may be required for your specific
deployment.
Publishing Outlook Web App, Outlook Anywhere, and Exchange ActiveSync
Using Forefront TMG
In this walkthrough we will configure Forefront TMG to publish Exchange Server
2010 to the Internet. We will use forms-based authentication at Forefront TMG for
Outlook Web App and Basic authentication for Outlook Anywhere and Exchange
ActiveSync. Both are pre-authenticated at Forefront TMG. Forefront TMG will publish
a farm of Client Access servers in one Active Directory site. The following diagram
outlines the topology.

Server and software prerequisites

The following are prerequisites for the configuration and should already be
configured:

Exchange 2010 deployed into one (or more) Active Directory sites.
Forefront TMG 2010 installed onto a Windows Server 2008 (SP2 or R2)
domain-joined computer that has two network interfaces: one facing the
internal network and one facing the public network. The Forefront TMG
installation wizards make installing and configuring Forefront TMG for basic
access simple. It's good practice to name each network adapter in the
Forefront TMG server according to the network it's connected to, for example
internal and external. This makes configuring them in Forefront TMG much
easier. In this walkthrough Forefront TMG has been joined to the same

domain as a Client Access server to enable Active Directory to provide

authentication and authorization without any additional configuration.
Certificate Prerequisites
In order to help secure traffic crossing the Internet SSL, certificates are used on the
server that publishes Exchange. For detailed information on how to plan certificates,
see White Paper: Exchange 2007 Client Access and SSL. For the purposes of this
walkthrough, it's assumed the planning exercise has resulted in the following
configuration:

Split DNS is configured. That is, the same domain name exists both inside
and outside the company network in DNS. The domain name used for this
walkthrough is fabrikam.com.
A host record, or mail, has been created to enable Exchange to be published
to the Internet, mail.fabrikam.com. All clients use this name to reach Outlook
Web App, Outlook Anywhere, and Exchange ActiveSync.
The certificate lists the mail.fabrikam.com name as the first name on the
certificate, also known as the principal name, or the Common Name. This is
important when the certificate is used to provide Outlook Anywhere.
A host record, AutoDiscover, has been created in external DNS to allow
Outlook Anywhere and Exchange ActiveSync clients from outside the network
to reach the Autodiscover service. For more information, see White Paper:
Exchange 2007 Autodiscover Service.
The certificate includes autodiscover.fabrikam.com as a Subject Alternative
Name (SAN) attribute on the certificate.

You should be aware that the certificate used on Forefront TMG can be from a thirdparty certification authority (CA) and the certificate used internally can be from a
different CA, perhaps an internal, Active Directoryintegrated certification authority.
However for this walkthrough, although the certificate used on Forefront TMG will be
from an internal authority, the certificate is not the same certificate as the one from
the CA. The certificate will only contain the names required by Forefront TMG to
publish Exchange. Creating a certificate with just the names required by Forefront
TMG avoids publishing a certificate with unnecessary FQDNs to the Internet.
Whatever choices are made about the issuer of the certificates, the Forefront TMG
server must trust the CA that issued the certificates that are used by the Client
Access server. If the certificates the Client Access server uses are from an internal
Active Directoryintegrated CA, and Forefront TMG is a domain member, the choice
is usually automatic. If Forefront TMG is not a domain member, or if the certificates
were not issued from an Active Directoryintegrated CA, then the certificate chain
must be installed on the Forefront TMG local computer's Trusted Roots Store.
It's also very important that the client that is trying to access Exchange through
Forefront TMG trust the CA that issued the certificate used by Forefront TMG. Notice
10

that it's not necessary that the client trust the CA that issued the certificate
installed on the Client Access server, only the certificate installed on Forefront TMG.
If the SSL tunnel ends on Forefront TMG (as it must for Web publishing), the client
must trust the CA that issued the certificate installed in that Forefront TMG Web
listener. If the Forefront TMG server then re-encrypts that traffic to Client Access
servers inside another SSL tunnel, the Forefront TMG server must then trust the CA
that issued the certificate installed on the Client Access server. In each case, one
computer is the client, the computer requesting access to resources, and the other
is the server, the computer that has the resources. The client must always trust the
CA that issued the certificate used by the server in an SSL conversation.
If you are using an internal CA to generate certificates, you might have to install
that root certificate on your client computer or mobile device in order to enable it to
connect to Forefront TMG. If the computer is a member of the domain where the
Active Directoryintegrated CA was installed, this is usually automatic. If not, the
client computer may have to browse to the Certificate Services Web site, if there is
one, or copy it from a computer that has the root certificate so that it can be
trusted.
It's easy to check whether a computer or device trusts the certificate installed on
the server by using a browser to connect to a published service on that server. If a
certificate warning pop-up window appears with just the first of the three checks
performed failing, the certificate is untrusted.

If you are working in Outlook Web App, you can just click Yes as shown in the
screenshot to continue. Outlook Anywhere and Exchange ActiveSync clients do not
usually provide this option and so will not connect. If you see this warning, you
should resolve it before you try to continue.
Configuration Steps

11

There are multiple steps required to configure Forefront TMG to publish Exchange
2010. The following steps are included in this walkthrough document:

Creating and installing the SSL certificate onto the Forefront TMG server
Creating a listener
Creating a Web farm
Creating publishing rules
Creating DNS records
Configuring authentication on the Client Access server
Testing the configuration

Creating and Installing the SSL Certificate on the Forefront TMG Server
Forefront TMG requires a certificate be used to secure communications with clients.
The client configuration requires that the certificate be created by using these
names, mail.fabrikam.com and autodiscover.fabrikam.com. The certificate request
can be generated anywhere and then imported to Forefront TMG, in this
walkthrough we use the certificate wizard in Exchange to generate the certificate on
a Client Access server inside the network, then export it to a file, copy it to Forefront
TMG, and then install it to the local computer certificate store on Forefront TMG. The
Exchange certificate wizard in Exchange makes it very easy to put the correct
names on the certificate. The wizard can be used to generate certificate requests
for either internal or third-party CAs.
This walkthrough will generate the certificate on the Client Access server.
Creating the Certificate Request
1. Using either the Exchange Management Shell or Exchange Management
Console, create a certificate request for a certificate with the names
mail.fabrikam.com and autodiscover.fabrikam.com.

Using the Exchange Management Shell:

12

Set-Content -path "C:\mail_fabrikam_com" -Value (NewExchangeCertificate -GenerateRequest -KeySize 2048 -SubjectName

"c=US, s=Washington, l=Redmond, o=Fabrikam, ou=IT,
cn=mail.fabrikam.com" -DomainName mail.fabrikam.com,
autodiscover.fabrikam.com -PrivateKeyExportable $True)
NOTE: You must use PrivateKeyExportable to allow the certificate to be
exported from the Client Access server and imported to another computer.
Safe handling of certificates that contain private key material, such as those
generated by using this process, is necessary to ensure they are not misused.
2. Use the resulting request file to request a Web Server certificate at the
certification authority you have chosen.
3. When you receive the resulting file from the CA, right-click the pending
certificate request in the Exchange Management Console (EMC) and select
Complete Pending Request. Or, you can use the Import-ExchangeCertificate
cmdlet, specifying the file the CA provided to complete the request.
NOTE: It's important at this point not to assign this certificate to any
Exchange services because this certificate will be used on Forefront TMG, not
on the Client Access server.
4. Right-click the certificate in EMC or use the Export-ExchangeCertificate
cmdlet to export the certificate to a .pfx file, specifying a password as
required.
5. Transfer the resulting .pfx file to the Forefront TMG server.
6. On the Forefront TMG server, open a blank Management Microsoft
Management Console (MMC) by clicking Start, Run and typing mmc followed
by Enter.
7. Click File, Add/Remove Snap-in, and then add the Certificates Snap-in.
When you are prompted for the choice of management location, select
Computer account, click Finish, and then click OK.
8. Expand the Certificates (Local Computer) node, and then click Personal.
9. Right-click the Personal container, and then select All tasks > Import.
10.Use the Wizard to locate and import the file that you transferred from the
Client Access server. You may have to change the file type that the Wizard is
searching for from *.cer to *.pfx.
11.As soon as the certificate is imported, double-click the certificate to make
sure that it opens, is trusted to the root, and that the certificate shows you
have the private key for the certificate.

13

12.Now you can choose to remove the certificate from Client Access server if you
no longer need it. Leaving a certificate there, with its private key, when it
isn't used by Exchange, won't do any harm. But if that certificate is
accidentally assigned to services or is taken and used elsewhere, it could
cause problems.
Creating a Listener
In these steps we will configure a single Web listener on the Forefront TMG server
and bind the certificate we created to that listener. A listener is a Forefront TMG
object that associates a combination of an IP address (the external-facing network
adapter of Forefront TMG), a port (TCP 443 for https), a certificate
(mail.fabrikam.com), and an authentication provider (Active Directory for this
domain-joined Forefront TMG computer).
1. Open the Forefront TMG management console. On the Firewall Policy node,
on the right side of the console, click the Toolbox tab.

14

2. Right-click the Web Listener network object, and then select New Web
Listener.
3. Provide a name that describes the object that you are creating, for example
Exchange Listener, and then click Next.
4. Take the default option to make sure clients connect using HTTPS, and then
click Next.

5. On the Web Listener IP Addresses page, click to select the External network,
as Forefront TMG will be listening to requests from clients on the external
interface. If you want to point all internal clients to Forefront TMG and provide
a common experience for both internal and external clients, you could do so
15

here by selecting the Internal network object also and making sure that DNS
is configured appropriately. When you select an object, the Select IP
Addresses button becomes available. This enables you to scope the listener
to one specific IP address, or to a group of IP addresses if your Forefront TMG
server has multiple external or internal IP addresses.

6. On the Listener SSL Certificates page of the wizard, click the Select
Certificate button to display the certificate picker and select the certificate
you installed earlier. If the certificate is not listed, or the Validity is not
shown as Valid, check the certificate import steps that you completed earlier.

16

7. On the Authentication Settings page of the wizard, click the drop-down

arrow and select HTML Form Authentication. This provides forms-based
authentication to Outlook Web App but also provides Basic authentication to
Outlook Anywhere and Exchange ActiveSync.

8. On the Single Sign On Settings page, enter fabrikam.com, and then click
Next. Although not strictly necessary for the topology and scenario that this
walkthrough provides, this check box and field are very important for
migration from Microsoft Exchange Server 2003 and Exchange 2007 to
Exchange 2010, as discussed later in this document, because this setting
allows Forefront TMG to do the single sign-on (SSO) redirection for Exchange
2003 and Exchange 2007 users when they try to log on to Exchange 2010.
9.

10.Click Next, and then click Finish to complete the Web Listener wizard.

17

Creating a Web Farm

In these steps we will create a Web farm. That is, we will specify the server or
servers that Forefront TMG is publishing, Exchange 2010 Client Access servers in
our walkthrough. This involves specifying the servers by name and specifying the
method Forefront TMG uses to ensure they are available for use (health checking).
You should configure a farm and a farm-publishing rule even if you only deploy one
Client Access server at first. If you then deploy additional Client Access servers, you
can add them to the farm and avoid any policy reconfiguration.
You can create the farm as a part of the publishing rule wizard. Some application
specific settings are applied automatically when you do this, but as they are
separate objects and can be configured independently, this walkthrough will create
each one separately.
1. Open the Forefront TMG management console. On the Firewall Policy node,
on the right side of the console, click the Toolbox tab.

2. Right-click the Server Farms object, select New Server Farm, and then
give the farm a meaningful name, CAS 2010 Farm in this example.

18

3. Click Next, and then click Add to add servers to the farm. Now one
advantage of Forefront TMG being a domain member is clear. You can search
Active Directory for the Client Access servers and easily populate the field
without having to know the IP addresses of the servers themselves.

4. At the Server Farm Connectivity Monitoring screen the default selection

is to send an HTTP GET request to the Client Access server to check whether
Internet Information Services (IIS) is responding. This default option allows
Forefront TMG to issue HTTP requests to the farm members; providing a more
accurate picture of the farm members health. The available health check
options provide server availability as follows:
a. Send an HTTP/HTTPS request: Forefront TMG will create a connection
on the port defined in the publishing rule Bridging tab and issue an
HTTP GET request. A response from the server that is not part of the
server error set as defined in RFC-2616 (5xx response codes) or any
4xx response other than 401 or 407 will be interpreted as a success
state. Notice that connectivity verifiers cannot authenticate to the
servers, although the lack of authentication does not affect the verifier.
Being prompted for authentication shows that the server is responding.
19

b. Send a Ping request: Forefront TMG will send ICMP Echo Requests to
the farm members to determine their availability. If Forefront TMG
receives a response to this request, the server is considered available.
c. Establish a TCP connection: Forefront TMG will create a connection to
the farm member on the port specified. If this process is successful,
Forefront TMG will tear down the session and consider the server to be
available.
The default choice presented when you run this wizard on its own won't
enable the verifier to work correctly when publishing Exchange. The default,
an HTTP GET request to the root of the Web server (HTTP://*/), will result in an
HTTP 403 Forbidden response because SSL is required to access the resource.
This results in the server being marked as down.
When the Web Farm wizard is invoked as part of a publishing rule wizard for
Exchange, Forefront TMG sets the verifier to use HTTPS GET to a path of
/OWA/ (HTTPS://*/OWA/). This results in a 401 Unauthorized response and
marks the server as available.
Therefore, if you create the Web farm on its own, as this walkthrough does,
and not as part of an Exchange Publishing wizard, you should modify the
default settings as shown here, although you may choose to substitute /OWA/
for /RPC/ or /Microsoft-Server-ActiveSync/ if you are only publishing one
specific protocol.

20

This setting results in the connectivity verifier making an HTTPS GET request
to each member of the farm, specifically directed at the /owa virtual directory.
It's not necessary that a certificate with the FQDN being tested (the FQDN of
each server in the farm) be installed on the Client Access server.
The following table summarizes the tests and their relative test functionality.
Test
Netwo
rk
Serve
r
Servic
e

PIN
G

TC
P

HTTP
/S

Understanding that Forefront TMG can test for the health of a specific
application endpoint, such as /OWA/ or /RPC/, might lead you to configure
farms with application-specific verification URLs for each application you are
publishing. These farms and verifiers can contain the same servers. So you
might configure a farm with two Client Access servers for OWA, testing the
/OWA/ path, and a farm with the same Client Access server for Outlook
Anywhere, testing the /RPC/ path.
When you have configured the verifiers you need, click Finish to complete
the New Server Farm wizard and apply the changes to Forefront TMG.
Creating Publishing Rules
A publishing rule ties together the listener, the farm, the users who can access the
resource, what paths are valid in the URL, and more. You can create both the
listener and the farm when the publishing rule is created. However, these tasks are
split out here to make them distinct from one another so that they can each be
independently configured.
21

It's also important to understand that the Exchange Web publishing rule wizard will
be run three times: for Outlook Web App, Outlook Anywhere, and Exchange
ActiveSync. However, all three will use the same listener and farm. Then, Forefront
TMG can correctly set up the paths each use and the load balancing each will use
(cookie for Outlook Web App, IP based for Outlook Anywhere and Exchange
ActiveSync). You should not modify one rule to accommodate all three clients. You
should create three separate rules to make sure that the configuration is optimal.
You should also know that publishing rules for Exchange that are created without
using the Exchange Publishing wizard are unsupported.
1. In the Forefront TMG console, right-click the Firewall Policy node, click New,
click Exchange Web Client Access Publishing Rule, and then give it a
meaningful name. For this step-by-step example, we will configure the
Outlook Web App publishing rule.

2. Click Next. From the drop-down list select the version of Exchange we are
publishing, select the Outlook Web Access (Outlook Web App) check box, and
then click Next.

22

3. On the Publishing Type page, click Publish a server farm of load balanced
Web servers, and then click Next.

4. On the Server Connection Security page, leave the default option, Use SSL,
and then click Next.

23

5. On the Internal Publishing Details page, enter the name internal users use to
access Outlook Web App. Because split DNS has been configured, this is
mail.fabrikam.com, it's important that Forefront TMG be able to resolve the
name in this field, but not that it resolves to a load balancer, although it
typically will if a load balancer is used inside the organization. If Forefront
TMG can resolve this to just one host, the publishing rule will work correctly,
and correctly balance the load between the Client Access servers configured
in the farm. If the name cannot be resolved in DNS by Forefront TMG, the rule
will still work. However, this usually results in many event log errors and
some decrease in performance.

24

6. On the Specify Server Farm page of the wizard, click the drop-down list, and
then select the farm created earlier.
7. On the Public Name Details page, enter the name external users will use to
access Outlook Web App. Again, mail.fabrikam.com.

8. On the Select Web Listener page, click the drop-down list, and then select the
listener you configured earlier.

9. The Authentication Delegation page is frequently one of the more confusing

pages of the wizard for those who are not Forefront TMG experts. This page
asks whether Forefront TMG should authenticate to the Client Access server
on behalf of the user or let the user authenticate directly, and then, if
Forefront TMG does delegate credentials, what authentication method
25

Forefront TMG should use when presenting the credentials to the Client
Access server. For a simple Outlook Web App, Outlook Anywhere, or Exchange
ActiveSync deployment, the most likely choices are Basic or NTLM. This
means that the corresponding virtual directory on the target Client Access
server must also support that form of authentication. If Forefront TMG is
configured to use Basic authentication then the Outlook Web App virtual
directory on the target Client Access server must also have Basic
authentication enabled.
Forefront TMG cannot delegate credentials correctly to a Client Access server
if the Client Access server has forms-based authentication configured.
Therefore, if the default setting of FBA authentication is enabled on the Client
Access server, delegation will fail, the user will see forms-based
authentication generated by the Client Access server, and then have to enter
their credentials again. Making sure that the correct authentication scheme is
configured on the Client Access server is covered later this section.

NOTE: If the goal of the deployment is to have FBA for both internal and
external users, you have the following options:
Point internal users to the internal interface of Forefront TMG and use
Forefront TMG FBA.
Leave FBA enabled on the Client Access server. On the Authentication
Delegation page of the wizard in Forefront TMG, select the No
delegation, but client may authenticate directly option. This means
that Forefront TMG is not performing forms-based authentication at all.
Add an additional IP address and an additional Outlook Web App Web
site to the Client Access server, and then use DNS to ensure users
inside and outside the network connect to the correct Web site.
26

10.On the User Sets page of the wizard, the default, All Authenticated Users, is
sufficient if you want to enable all users who successfully authenticate to
access the resource. However, if you use Active Directory groups, for
example, to limit access, you can select those groups on this page.
11.Finish the wizard, and apply the changes to Forefront TMG.
Complete the same wizard again for Exchange ActiveSync, using the same
parameters as for Outlook Web App.
Complete the wizard again for Outlook Anywhere, selecting the box to Publish
additional folders on the Exchange Server for Outlook 2007 client, and then
selecting Basic authentication for the delegation method. But, when the rule is
complete and before you apply the changes to Forefront TMG, open the properties
dialog for the rule that you just created.

As shown, add autodiscover.fabrikam.com to the list of names on the Public Name

tab of the rule properties. The AutoDiscover path is used to provide the
Autodiscover service to both Outlook Anywhere and Exchange ActiveSync clients.
By default, the Autodiscover path is contained in the Outlook Anywhere rule.
If you want to use Exchange ActiveSync but not Outlook Anywhere and also want to
provide Autodiscover service functionality to those Exchange ActiveSync clients,
you can do one of the following:

Add the /Autodiscover/* path of the Exchange ActiveSync rule that you have
created, and then add the Autodiscover namespace to the Public Names tab
27

of the rule as shown. This puts both Exchange ActiveSync and the
Autodiscover service on the same publishing rule.
Run the Outlook Anywhere publishing wizard and, when complete, remove
the /rpc/*, /oab/*, and other paths that are not required. Again, make sure
that the Public names tab of the rule is correct.

Apply these settings to Forefront TMG.

Creating DNS Records
In external DNS create two A records for mail and the Autodiscover service in the
fabrikam.com DNS zone, pointing at the external IP address of the listener you
configured earlier.
Configuring Authentication on the Client Access Server
As mentioned earlier, Forefront TMG will be delegating credentials to the Client
Access server by using Basic authentication. So, the owa and ECP virtual directories,
which use FBA by default, must be configured to support Basic authentication.
You can use the EMC to open the owa and ECP virtual directories and set the
authentication to Basic. Then run iisreset on each Client Access server you have
changed.

Enable Outlook Anywhere on each published Client Access server, selecting Basic
authentication as the Client authentication method. After all changes are made, run
iisreset on each Client Access server configured, and then verify that event ID
3006 has been logged and shows the appropriate registry keys are set.

28

If this is the first time Outlook Anywhere has been enabled, several more steps are
required to ensure that users outside Forefront TMG can fully use Outlook. Also, one
more step is required so that Exchange ActiveSync can use the Autodiscover
service. You should run these on each server in the Active Directory site you are
publishing, replacing the server host name as appropriate.
a) Set the external URL for the offline address book (OAB) virtual directory. It is
assumed that the OAB is already enabled for Web-publishing. If it's not, see
Configure Offline Address Book Distribution Properties.
Set-OABVirtualDirectory RED-CAS-1\* -ExternalURL
https://mail.fabrikam.com/OAB

b) Set the external URL for the Exchange Web Services virtual directory to
https://mail.fabrikam.com/EWS/Exchange.asmx.
Set-WebServicesVirtualDirectory RED-CAS-1\* -ExternalURL
https://mail.fabrikam.com/EWS/Exchange.asmx

c) Set the external URL for the Exchange ActiveSync virtual directory to allow
the Autodiscover service to provide devices with the correct value.
Set-ActivesyncVirtualDirectory red-cas-1\* -externalurl
https://mail.fabrikam.com/Microsoft-Server-Activesync

d) Set the authentication property for the OAB and Exchange Web Services
virtual directories to include Basic as an option if you are using Basic
delegation on the publishing rule.
Set-OabVirtualDirectory red-cas-1\* -BasicAuthentication:$true
Set-WebServicesVirtualDirectory RED-CAS-1\* -BasicAuthentication:$true

29

Testing the Configuration

Testing Outlook Web App
The first test determines whether a user connected to the Internet can log on to an
Exchange 2010 mailbox using Outlook Web App through Forefront TMG.
1. Open a browser and browse to the URL Outlook Web App is published to, in
this example, https://mail.fabrikam.com/OWA.

2. The Outlook Web App sign-in page is displayed. At the foot of the page, the
words Secured by Microsoft Forefront Threat Management Gateway 2010 are
displayed, indicating this form was generated by Forefront TMG.
3. Try to access an Exchange 2010 mailbox by using the domain\username
format and password.
4. If the attempt was successful, the mailbox will be displayed.
Testing Exchange ActiveSync
The next test determines whether a mobile device is able to synchronize to an
Exchange mailbox.
1. Configure a mobile device to automatically configure a profile, or manually
set the server as mail.fabrikam.com and ensure the device can successfully
synchronize with a mailbox.
Testing Outlook Anywhere and the Autodiscover service

30

1. Using a computer outside the corporate network, open Outlook and configure
a new profile. The wizard takes advantage of the Autodiscover service, and
will try to connect to autodiscover.fabrikam.com (assuming the SMTP address
of your test user account ends with @fabrikam.com).
2. If you receive 3 check marks in the Add New Account wizard, you have
successfully configured Outlook Anywhere and proven that the Autodiscover
service is correctly configured.

Troubleshooting
There are many common configuration errors made when publishing Exchange, use
this list to validate and confirm your settings.

Certificates The most common reason one or more of these clients is

unable to log on, or Forefront TMG is unable to publish, is a certificate error.
Check the following:
Trust Does the client trust the issuer of the certificate on Forefront TMG?
And does Forefront TMG trust the issuer of the certificate on the Client
Access server?
Name Mismatch You may receive a pop-up window because the name
on the certificate does not match the name the client was expecting to
see. First make sure all ExternalURL settings are correct and those names
are present on the certificate. Then try to resolve the problem by reissuing
the certificate with the correct names and test again.
Expiration Dates f the certificates have expired, the client will not
accept their use. Check the expiration dates and reissue the certificates, if
it's necessary.

Matching Authentication Schemes If Forefront TMG is configured for

Basic Delegation then the appropriate virtual directories on the Client Access
server should be configured to support Basic authentication. Similarly, if
31

NTLM delegation was set at Forefront TMG, Windows Integrated

authentication must be enabled on the Client Access server.

DNS Are the records for mail and Autodiscover in the correct zone, and do
they have the correct IP address? The IP should resolve to the external
network adapter of Forefront TMG and, more specifically, to the IP address of
the listener configured on the Exchange publishing rules.

Use the Test Email AutoConfiguration tool in Outlook Confirm that the
Autodiscover service can be contacted and that the URLs returned by
Autodiscover are correct. To use the tool, hold down the CTRL key, and then
right-click the Outlook icon on the taskbar.

Use the Exchange Remote Connectivity Analyzer tool If the

environment is Internet-facing, see Microsoft Exchange Remote Connectivity
Analyzer to test the configuration from the Internet.

Eliminate single server issues If you are publishing a farm of Client

Access servers, reduce the farm size to just one Client Access server and test
again. This makes troubleshooting much easier because it's easy to
determine which servers are involved in the connection attempt.

Additional Configuration Steps for Exchange 2010 and/or Outlook 2010

Users
If you are not publishing Outlook Web App in your environment but do allow the
publishing of Outlook Anywhere (and possibly Exchange ActiveSync) and are using
Outlook 2010, you will have to make some adjustments to the configuration to allow
32

an Outlook 2010 user to be able to access the Exchange Control Panel (ECP).
Exchange 2010 users require access to the ECP for certain configuration settings,
such as voice mail and message tracking information. The ECP is accessed by using
a Web browser and is invoked by a link in the Microsoft Office Backstage area of
Outlook 2010 or within the properties of a message.
In Forefront TMG there are several choices, depending on the existing configuration.
You can create a new listener and publishing rule for the ECP and then modify it. Or
you can modify the existing listener and publishing rule you have configured for
publishing Outlook Anywhere. In this scenario, it's likely that the existing listener will
not be enabled for forms-based authentication because Outlook Anywhere supports
only Basic or NTLM authentication at this time.
The choice between these depends on several factors, but some recommendations
are as follows:

If Outlook Anywhere is already configured for Basic authentication you can

either:
o Enable forms-based authentication on the same listener. The ECP will
then use FBA, and Outlook Anywhere will continue to use Basic
authentication. This requires you to enable Basic authentication on
the /ECP virtual directory of all published Client Access servers.
o Leave Basic only enabled and accept a Basic authentication prompt
when the user accesses the ECP. This requires you to enable Basic
authentication on the /ECP virtual directory of all published Client
Access servers.
If Outlook Anywhere is configured for NTLM you can either:
o Continue to use NTLM authentication and KCD to the Client Access
server. This requires you to enable Windows Integrated authentication
on the /ECP virtual directory of all published Client Access servers.
o Add Basic authentication to the listener and expect users to see a
Basic authentication pop-up window. This requires you to enable Basic
authentication on the /ECP virtual directory of all published Client
Access servers.
o Add an additional Web listener to Forefront TMG, configure FBA, and
then publish the ECP using your choice of delegation protocol.

In addition to the choice you make on authentication, you may also have to consider
some additional factors:

If you want to use Basic, NTLM or KCD delegation to the Client Access server,
you have to disable forms-based authentication on the /ECP virtual directory
on the Client Access server. If you want to offer FBA for internal users at the
same time, you can either ensure their DNS requests for the ECP service
resolve to Forefront TMG (if you are using a forms-based listener) or add a
secondary Web site which requires an additional IP address. Either step will
33

enable you to use different authentication methods. For detailed instructions,

see New-EcpVirtualDirectory.
If you do not want to allow any user to access Outlook Web App, but do want
allow all users to access the ECP, you can disable Outlook Web App access
per user with the Set-CASMailbox cmdlet.
If you want to allow Outlook Web App access for internal users, but don't
want to allow Outlook Web App access from outside the corporate network,
then you must restrict the resources you publish to allow only those
resources required by the ECP to be accessed. This is because the ECP uses
the Outlook Web App authentication model and therefore uses some Outlook
Web App resources to function.

To make sure only the ECP can be accessed but not Outlook Web App, the following
paths must be allowed by Forefront TMG:

/ecp/*
/owa/auth/logon.aspx
/owa/auth/logoff.aspx
/owa/logoff.owa
/owa/auth.owa
/owa/languageselection.aspx
/owa/lang.owa*
/owa/14*

These paths are in addition to the following paths, which are required by Outlook
Anywhere 2010:

/rpc/*
/OAB/*
/ews/*
/AutoDiscover/*

These are configured on the publishing rule configured similar to that shown here.

34

As soon as configured, whether the listener uses forms-based authentication, Basic

or NTLM, the ECP should be able to be accessed. It's always important to remember
that the delegation type chosen on the publishing rule matches the method enabled
on the Client Access server as described elsewhere in this guide.
Migration Considerations
If you are migrating from an earlier version of Exchange and are following the
standard Exchange migration guidance at Upgrade to Exchange 2010 and using an
additional legacy namespace, some changes are required in Forefront TMG to
ensure a smooth migration.
The exact configuration required will depend on the clients and protocols that are
used. Outlook Web App, for example, has a built in Single Sign On (SSO) capability
when it's deployed alongside Microsoft Exchange Server 2007 in the same Active
Directory site or when an Outlook Web App request for a 2003 mailbox is received.
Accessing a mailbox hosted on Exchange 2003 or Exchange 2007 using Exchange
ActiveSync or Outlook Anywhere can be performed through an Exchange 2010
Client Access server. However, in some scenarios, you may choose to provide
access through an Exchange 2007 Client Access server to users who have
mailboxes on Exchange 2007.
Two basic approaches can be used when Forefront TMG is being used to publish
Exchange. You can either configure Forefront TMG to direct traffic to the appropriate
version of Exchange for the user requesting access. Or you can rely on Exchange to
either provide access directly to a down level version of Exchange or redirect the
user to an appropriate URL.

35

In either case, the standard approach is to move the existing namespace to

Exchange 2010, and use the newly created legacy namespace to access earlier
versions of Exchange.
Using Forefront TMG Publishing Rules to Direct Traffic
Forefront TMG can be configured to automatically route client requests to the
correct version of Exchange instead of using the built-in Exchange SSO logic at all.
Using this approach, which relies on configuring groups in Active Directory and
associating those groups with specific publishing rules, is very effective. However it
relies on group membership being kept up to date, which can be hard during a
migration, and is affected by Active Directory replication latency. Because Forefront
TMG is responsible for authentication to determine which publishing rules will be
applied, ideally, Forefront TMG should be either configured as a domain member or
to use LDAP authentication against Active Directory.
Using Native Exchange SSO Redirection Combined with Forefront TMG
Listener SSO
You can rely on Exchange to redirect the user to the correct endpoint.
There are several steps required to configure this scenario:

Ensure the certificates have the correct names.

Create a Web farm for the legacy version of Exchange.
Create a publishing rule for the legacy version of Exchange.
Configure Exchange to provide the redirection URLs.
Ensure SSO is enabled on the listener.

In this scenario, forms-based authentication is still being performed on Forefront

TMG. So forms-based authentication must be disabled on Exchange 2003, Exchange
2007, and Exchange 2010, and either Basic or Windows Integrated authentication
enabled, depending on the publishing rule delegation settings.
It's important to understand that using Forefront TMG in combination with Exchange
to perform the SSO requires that both host names be under the same common root,
for example, mail.fabrikam.com and legacy.fabrikam.com. It isn't possible to
configure Forefront TMG SSO between mail.fabrikam.com and legacy.contoso.com.
This is the scenario covered during this walkthrough.
Ensure Certificates Have the Correct Names
The first step in enabling SSO when you use Forefront TMG is to ensure that the
certificate you are using on the Forefront TMG listener has all the names you need
to support the scenario. In this example, we will add legacy.fabrikam.com to the

36

certificate and use that FQDN to redirect users who have mailboxes on Exchange
2003 or Exchange 2007 to access their mailbox.

Create a Web Farm to Publish the Legacy Servers

As soon as the certificate is in place on Forefront TMG, adjust the properties on the
listener to use the new certificate instead of the previous one, and then create a
Web farm. Follow the steps that were described earlier, but use the legacy
Exchange 2003 front-end servers or Exchange 2007 Client Access servers as the
targets.

37

At this point, also make sure that the certificate on the Exchange 2003 front-end
servers or Exchange 2007 Client Access servers are valid and have the correct
name (legacy.fabrikam.com). It's common and simplifies the deployment to use the
same certificate as used on the Exchange 2010 Client Access servers in your
organization.
Outlook Web App Migration
On Forefront TMG, create a Publishing rule for the legacy version of Exchange, using
legacy.fabrikam.com as the public name clients use to connect, choosing the same
listener as used for Exchange 2010, but making sure that you use the Legacy Farm
you created in the previous step. Again, make sure that the delegation you select is
configured on the /Exchange virtual directory on the Exchange 2003 servers in the
farm and on the /owa virtual directory on the Exchange 2007 Client Access server if
you are redirecting to Exchange 2007.

38

On Forefront TMG, make sure that SSO is enabled for the .fabrikam.com domain.
This is the default.

Configure Exchange 2010 to Provide the Redirection URLs

Next, if you are migrating from Exchange 2003 to Exchange 2010, on all the
Exchange 2010 Client Access servers being published, set the Exchange 2003 URL
property on the owa virtual directory to match the value of the legacy FQDN and
URL you are using, in this case, https://legacy.fabrikam.com/exchange.
Set-OwaVirtualDirectory RED-CAS-1\* -Exchange2003URL
https://legacy.fabrikam.com/exchange

39

If you are migrating from Exchange 2007 to Exchange 2010, make sure that the
externalurl parameter on the Exchange 2007 Client Access server owa virtual
directory is set correctly.
Set-OwaVirtualDirectory RED-CAS-2007\* -ExternalURL https://legacy.fabrikam.com/owa

If you are migrating from mixed Exchange 2003 / Exchange 2007 to Exchange 2010,
you should first make sure that all Exchange 2003 access is through the Exchange
2007 Client Access servers. This is the norm when migrating from Exchange 2003 to
Exchange 2007. In this scenario, and when both the previous commands are
executed, Exchange 2003 users will be redirected to the /exchange virtual directory
on the Exchange 2007 Client Access server and Exchange 2007 users will be
redirected to the /owa virtual directory on the Exchange 2007 Client Access server.
This allows all three versions of Exchange to be accessed through a single URL,
https://mail.fabrikam.com/owa.
Note: If a user tries to browse to https://mail.fabrikam.com/exchange, as
would be the case if they were an Exchange 2003 user who had bookmarked
a page they had used earlier, they will be automatically redirected to
https://mail.fabrikam.com/owa and provided with a form to log on with.
Ensure DNS is Correct and Test the Configuration
Ensure the A record for legacy.fabrikam.com in external DNS resolves to the same IP
address as mail.fabrikam.com.
Test the Exchange 2003 configuration by going to https://mail.fabrikam.com/owa,
and logging in to an Exchange 2003 mailbox. You should be silently redirected to
https://legacy.fabrikam.com/Exchange and automatically logged in without any
prompts for credentials.

40

Test the 2007 configuration by going to https://mail.fabrikam.com/owa, and logging

on to an Exchange 2007 mailbox. You should be silently redirected to
https://legacy.fabrikam.com/owa and automatically logged in without any additional
prompts for credentials.
Exchange ActiveSync Migration
Two options exist for providing access to users who have mailboxes on Exchange
2003 or Exchange 2007 and whose mailboxes have not yet been migrated to
Exchange 2010.
First, do nothing and allow the Exchange 2010 Client Access server to proxy the
request internally to Exchange 2007 for Exchange 2007 users, or directly access the
mailbox for Exchange 2003 users. In this case, all access is through Exchange 2010.
It's important to plan your migration so that sufficient Exchange 2010 Client Access
servers exist to provide access to all users as soon as you deploy them.
Or, you can decide to publish more than one version of Exchange and rely on
Exchange to redirect clients between versions as required. However, the latter
approach only works for:

Users who have mailboxes on Exchange 2007.

Devices that are running Windows Mobile 6.1 or a later version.

Devices that support the HTTP 451 redirect mechanism used by Exchange
ActiveSync to inform the device which endpoint it should be using.

If your deployment is fairly small or is between Exchange 2003 and Exchange 2010,
or if you cannot make sure that all devices support the HTTP 451 redirect, it's
recommended that you provide access to all versions of Exchange through an
Exchange 2010 Client Access server.
However, if you want to publish the Exchange 2007 and Exchange 2010 servers
separately in the same Active Directory site, you have to create a new Publishing
Rule in Forefront TMG for Exchange ActiveSync, using the legacy.fabrikam.com host
name together with a farm of Exchange 2007 Client Access servers as the target for
the rule. Then you can use a command, such as the following, to correctly set the
external URL for the Exchange 2007 Client Access server to the legacy value.
Set-ActiveSyncVirtualDirectory CAS-2007-01\* -externalurl
https://legacy.fabrikam.com/microsoft-server-activesync

As soon as this command is complete, any user who uses a device on Exchange
2007 and connects through an Exchange 2010 Client Access server should receive
an HTTP 451 response from the server that includes the new URL. The device should
reconfigure itself, and the user will reconnect using the newly created publishing
41

rule in Forefront TMG. After the users mailbox is migrated to Exchange2010, the
Exchange 2007 Client Access server will issue another HTTP451 response, and the
device will again reconfigure itself.
For these reasons you must make sure that the legacy namespace is not removed
before all devices are updated. Otherwise the device won't be able to reach the
legacy endpoint in order to receive the redirection.
Outlook Anywhere Migration
Migrating clients who connect by using Outlook Anywhere direct to Exchange 2003
or Exchange 2007 is fairly straightforward. Just as with Exchange ActiveSync, your
approach depends on the version of clients you want to support and your ability to
provision all your Exchange 2010 servers at the beginning of the migration.
The recommended scenario is to move the existing Outlook Anywhere endpoint
your clients use to Exchange 2010 and allow the Exchange 2010 Client Access
server to proxy connections back to legacy versions of Exchange when it's
necessary. Exchange 2003, Exchange 2007 and Exchange 2010 Outlook Anywhere
users can access their mailboxes by using Exchange 2010 Client Access server, so
the simplest approach is to publish just Exchange 2010 as the Outlook Anywhere
endpoint. Then, the configuration of the client doesn't have to change either at the
beginning of the deployment, when Exchange 2010 Client Access server is
introduced, or later, when their mailbox is moved to an Exchange 2010 mailbox
server.
If you decide you must have separate namespaces for Outlook Anywhere, you have
several things to consider:

Users with mailboxes on Exchange 2010 cannot use Outlook Anywhere via an
Exchange 2003 front-end server or a an Exchange 2007 Client Access server,
as neither of these versions of Exchange understand the RPC Client Access
Service component in Exchange 2010, so they do not consider the endpoint
the client is trying to reach as valid.
Outlook 2003 does not use the Autodiscover service to update or change any
configuration settings, so if a mailbox is moved between versions of
Exchange and different Outlook Anywhere endpoints are used, the client
profile may break and prevent access.
Outlook 2007 clients sometimes don't correctly update the Outlook Anywhere
settings following a move between two Outlook Anywhereenabled endpoints.
For example, if you were publishing Exchange 2007 and Exchange 2010 using
different Outlook Anywhere host names, and a users mailbox were moved
between Exchange 2007 and Exchange 2010, the client may not correctly
update the host name used by Outlook Anywhere.

42

The standard recommendation of moving the existing namespace to Exchange 2010

and allowing the Exchange 2010 Client Access server to provide access to all legacy
versions of Exchange means very little user impact, and minimal client
configuration changes.
One common reason for using two namespaces for Outlook Anywhere may be to
allow a pilot deployment of Exchange 2010 alongside an existing Exchange2003 or
Exchange 2007 deployment.
If this is the reason for the additional namespace, it's recommended that you create
a new namespace for Exchange 2010 and manually configure pilot users to use
those settings if necessary, creating a new publishing rule just for Exchange 2010
Outlook Anywhere. Additionally, it's recommended that you consider deploying
Exchange 2010 in a separate Active Directory site for the pilot phase of the project.
This will completely avoid the possibility of the Exchange 2007 Autodiscover service
returning Exchange 2010 URLs to Outlook clients.
Supporting this configuration in Forefront TMG just requires additional publishing
rules, with additional Web farms for each version of Exchange, the steps for which
are discussed earlier in this walkthrough.

43

Publishing Outlook Web App, Outlook Anywhere, and Exchange ActiveSync

Using Forefront UAG
In this walkthrough we will be configuring Forefront UAG to publish Exchange Server
2010 to the Internet. We will again be using forms-based authentication at Forefront
UAG for Outlook Web App, Basic authentication for Outlook Anywhere and Exchange
ActiveSync, both authenticated at Forefront UAG. Forefront UAG will be publishing a
farm of Client Access servers in one Active Directory site. The following diagram
outlines the topology.

Server and Software Prerequisites

The following prerequisites for the configuration should already have been
configured:

Exchange 2010 deployed in one (or more) Active Directory sites.

Forefront UAG 2010 installed on a Windows Server R2 domain-joined
computer with two network interfaces: one facing the internal network, and
one facing the public network. The Forefront UAG installation wizards make
installing Forefront UAG simple. It's good practice to name each network
adapter in the Forefront UAG server according to the network it's connected
to, for example internal and external, This makes configuring them in
Forefront UAG much easier.

Certificate Prerequisites
Just like when you configure Forefront TMG, certificates are used on the server
publishing Exchange. For detailed instructions about how to plan certificates, see
the TechNet Library, including White Paper: Exchange 2007 Client Access and SSL.
For the purposes of this walkthrough, it's assumed the planning exercise has
resulted in the following configuration:

44

Split DNS is configured, that is the same domain name exists both inside and
outside the company network in DNS. The domain name used for this
walkthrough is fabrikam.com.
A host recordmailhas been created to enable Exchange to be published to
the Internet. Mail.fabrikam.com will be the name all clients use to reach
Outlook Web App, Outlook Anywhere and Exchange ActiveSync.
The certificate lists the mail.fabrikam.com name as the first name on the
certificate, also known as the principal name, or the Common Name. This is
important when the certificate will be used to provide Outlook Anywhere.
A host recordAutoDiscoverhas been created in external DNS to allow
Outlook Anywhere and Exchange ActiveSync clients from outside the network
to reach the Autodiscover service. For more information, see White Paper:
Exchange 2007 Autodiscover Service.
The certificate will include autodiscover.fabrikam.com as a SAN attribute on
the certificate.

You should be aware that the certificate used on Forefront UAG can be from a thirdparty certification authority (CA) and the certificate used internally can be from a
different CA, perhaps an internal, Active Directoryintegrated certification authority.
However for this walkthrough, although the certificate used on Forefront UAG will be
from an internal certification authority, the certificate isn't the same certificate as
that used on the Client Access server. The certificate will only contain the names
required by Forefront UAG to publish Exchange. Creating a certificate with just the
names required by Forefront UAG avoids publishing a certificate with unnecessary
FQDNs to the Internet.
Whatever choices are made about the issuer of the certificates, the Forefront UAG
server must trust the certification authority that issued the certificates that are used
by the Client Access server it's publishing. If the certificates that the Client Access
servers are using are from an internal Active Directoryintegrated certification
authority, and Forefront UAG is a domain member, this will usually be automatic. If
Forefront UAG is not a domain member, or if the certificates were not issued from an
Active Directoryintegrated CA, then the certificate chain must be installed into the
Forefront UAG local computer trusted root certificate store.
It's also very important that the client that is trying to access Exchange through
Forefront UAG trust the CA that issued the certificate used by Forefront UAG. Notice
that it's not necessary that the client trust the CA that issued the certificate
installed on the Client Access server, only the certificate installed on Forefront UAG.
If the SSL tunnel ends on Forefront UAG (as it must for Web publishing), the client
must trust the CA that issued the certificate installed in that Forefront UAG trunk. If
the Forefront UAG server then re-encrypts that traffic to Client Access servers inside
another SSL tunnel, the Forefront UAG server must then trust the CA that issued the
certificate installed on the Client Access server. In each case, one computer is the
client, the computer requesting access to resources, and the other is the server, the
45

computer that has the resources. The client must always trust the CA that issued
the certificate used by the server in an SSL conversation.
If you are using an internal CA to generate certificates then you might have to
install that root certificate onto your client computer or mobile device in order to
allow it to connect to Forefront UAG. If the computer is a member of the domain
where the Active Directoryintegrated CA was installed, this is usually automatic. If
not, the client computer may have to browse to the Certificate Services Web site if
there is one, or copy it from a computer that has the root certificate so that it can
be trusted.
It's easy to check whether a computer or device trusts the certificate installed on
the server. Just use a browser to connect to a published service on that server. If a
certificate warning appears with just the first of the three checks performed shown
as failing, the certificate is untrusted.

If you are working in Outlook Web App, you can just click Yes as shown in the
screenshot to continue. Outlook Anywhere and Exchange ActiveSync clients do not
usually provide this option and so will not connect. If you see this warning, you
should resolve it before you try to continue.
Configuration Steps
There are multiple steps required to configure Forefront UAG to publish Exchange
2010. The following steps are included in this walkthrough document:

Creating and installing the SSL certificate onto the Forefront UAG server
Deciding to use a portal to access Outlook Web App
Creating a portal trunk and publishing the first application
Publishing additional applications
Testing the configuration

46

Creating and Installing the SSL Certificate on the Forefront UAG Server
Forefront UAG requires a certificate be used to secure communications with clients.
The client configuration requires that the certificate be created that uses the names
mail.fabrikam.com and autodiscover.fabrikam.com. The certificate request can be
generated anywhere and then imported to Forefront UAG, in this walkthrough we
use the certificate wizard in Exchange to generate the certificate on a Client Access
server inside the network, then export it to a file, copy it to Forefront UAG, and then
install it to the local computer certificate store on Forefront UAG. The Exchange
certificate wizard in Exchange makes it very easy to put the names on the
certificate correctly. The wizard can be used to generate certificate requests for
either internal or third-party CAs.
Creating the Certificate Request
1. By using either the Exchange Management Shell or the Exchange Management
Console, you can create a certificate request for a certificate with the names
mail.fabrikam.com and autodiscover.fabrikam.com.

Using the Exchange Management Shell:

Set-Content -path "C:\mail_fabrikam_com" -Value (NewExchangeCertificate -GenerateRequest -KeySize 2048 -SubjectName
"c=US, s=Washington, l=Redmond, o=Fabrikam, ou=IT,
cn=mail.fabrikam.com" -DomainName mail.fabrikam.com,
autodiscover.fabrikam.com -PrivateKeyExportable $True)
NOTE: The use of PrivateKeyExportable is essential to allow the certificate
to be exported from the Client Access server and imported to another
computer. Safe handling of certificates that contain private key material, such
as those generated by using this process, is important to ensure they are not
misused.

47

2. Use the resulting request file to request a Web Server certificate at the CA you
have chosen to use.
3. When you receive the resulting file from the CA, right-click the pending
certificate request in the EMC, and then select Complete Pending Request. Or,
you can use the Import-ExchangeCertificate cmdlet, specifying the file that the
CA provided to complete the request.
NOTE: At this point, it's important not to assign this certificate to any
Exchange services because this certificate will be used on Forefront UAG, not
on the Client Access server.
4. Right-click the certificate in the EMC or use the Export-ExchangeCertificate
cmdlet to export the certificate to a .pfx file, specifying a password as required.
5. Transfer the resulting .pfxfile to the Forefront UAG server.
6. On the Forefront UAG server, open a blank MMC by clicking Start and then Run.
In the Open box, type mmc, and then click OK.
7. Click File, Add/Remove Snap-in and add the Certificates Snap-in, When You
Are Prompted for the choice of management location, select Computer
account, click Finish and then OK.
8. Expand the Certificates (Local Computer) node, and then click Personal.
9. Right-click the Personal container, and then select All tasks > Import.
10.Use the Wizard to locate and import the file that you transferred from the Client
Access server. You may have to change the file type the Wizard searches for
from *.cer to *.pfx.
11.As soon as the certificate is imported, double-click the certificate to ensure that
it opens, is trusted to the root, and shows that you have the private key for the
certificate.

48

12.Now you can choose to remove the certificate from the Client Access server if
you no longer need it. Leaving a certificate there, with its private key, when it
isn't used by Exchange, won't do any harm. But, if that certificate is accidentally
assigned to services or taken and used elsewhere, it could cause problems.
Deciding to Use a Portal
Forefront UAG offers two ways to publish a Web-based application such as Outlook
Web App to the Internet, either directly, where the user experience resembles that
in Forefront TMG or when the user connects directly to the Client Access server, or
by using the Forefront UAG portal application, where the user logs on to the
Forefront UAG portal, and then clicks an additional button to open Outlook Web App.
The decision whether to use a portal or not depends on your plans for Forefront UAG
and whether you plan to publish additional applications using Forefront UAG. If you
only intend to publish Outlook Web App you may choose not to use a portal, and
just present users with forms-based authentication at Forefront UAG and their
mailbox once they authenticate. If you decide that you may decide to publish
additional applications through Forefront UAG, such as SharePoint, creating a portal
will enable the user to log on once to the portal and then open other applications
within that portal, therefore taking advantage of the SSO capabilities built into
Forefront UAG.

49

This walkthrough will detail the direct publishing option, where no portal is first
accessed. Only Outlook Web App is visibly affected when a portal is used, both
Outlook Anywhere and Exchange ActiveSync always use Basic or NTLM (Outlook
Anywhere only) authentication to Forefront UAG and bypass the portal.
Configuring Authentication and Authorization Servers
The first step is telling Forefront UAG which servers to use for authentication and
authorization.
1. Open the Forefront UAG management console, click the Admin menu, and
then select Authentication and Authorization Servers.
2. In the resulting dialog box, click Add.

3. Leave the default choice of Active Directory selected, enter a value for the
Server name field that represents the authentication source, click Use local
Active Directory forest authentication, and enter the base DN in Active
Directory where Forefront UAG will look for user objects. To include an entire
domain, use something similar to DC=FABRIKAM,DC=COM, and then select
the Include subfolders check box. Finally enter the details of a user account
that has access to Active Directory. It's recommended that this users
password be set to not expire and that this account be treated as a special
security case, not subject to the usual password expiration policies.
50

4. As soon as it is complete, click OK and, assuming you received no errors,

close the Authentication and Authorization Servers dialog box.
Creating a Trunk and Publishing Your First Application
The next task in Forefront UAG to complete is creating a trunk and publishing an
application. We will publish Outlook Web App only during this walkthrough.
1. In the Forefront UAG management console, right-click HTTPS connections
and select New Trunk
2. Click Next at the first page of the Create Trunk Wizard
3. Select Portal Trunk as the trunk type and check the box stating that you will
be publishing Exchange applications via the portal. The wording for this check
box suggests we will be using a portal to access Exchange. However,
configuring Forefront UAG using this wizard will result in an Outlook Web App
user directly accessing Outlook Web App without first logging in to a portal.

51

4. Enter a name for your trunk. You cannot use spaces or any non-alphanumeric
characters. Enter the public host name of the portal, mail.fabrikam.com in our
example, and make sure that the IP address the trunk will listen to requests
on is correct, that is, the external network interface of Forefront UAG.

5. Click Next, and on Step 3 Authentication, click Add and select the entry
that you created earlier.

52

6. On Step 4 Certificate, make sure the certificate that you installed earlier
is selected, and then click Next.
7. On Step 5 Endpoint Security, if you have already deployed Network
Access Protection (NAP) policies on your network, you may select them here
or else leave the default of Use Forefront UAG access policies, and then
click Next. Be aware that Endpoint Security policies only apply to Web
browser clients and not to clients like Outlook Anywhere or Exchange
ActiveSync.
8. On Step 6 Endpoint Policies, leave the defaults for now and then click
Next
9. On Step 7 Select Exchange Services, select Exchange Server 2010, and
check the box next to Outlook Web Access only. It's recommended that you
do not select all the check boxes to select all the Exchange services. The
load-balancing method configured when publishing a farm in this manner is
not optimal for Exchange. Therefore, it's recommended that you publish
Outlook Web App first and return to the wizard for Outlook Anywhere and
Exchange ActiveSync following that.

53

10.On Step 8 Configure Application, enter an Application nameExchange

2010 OWA in our example.

11.On Step 9 Select Endpoint Policies, leave the default options, and then
click Next.
12.On Step 10 Deploying an Application, click Configure a Farm of
application servers, and then click Next.

54

13.On Step 11 Load-Balanced Web Servers, enter the FQDNs of the Client
Access servers you will be publishing, and then change the Balance request
by setting by clicking Cookie-based affinity. (When you run the wizard for
Outlook Anywhere and Exchange ActiveSync, click IP-based affinity.). In the
Paths field, you should review and remove paths you do not require.

14.On Step 12 Configure Connectivity Verifiers, choose the type of verifier

you wish to use. For the purposes of this walkthrough, and for simplicity, we
have chosen to use Establish a TCP session, which simply tests to see if
the server responds to requests on TCP 443, and marks the server as active if
it does. Forefront UAG uses the underlying Forefront TMG health monitoring
features, so all configuration choices you make here are visible in the
55

Forefront TMG management console, in the Monitoring, Connectivity

Verifiers section of the console. As Forefront TMG is used for connectivity
verification, much of the detail provided earlier in this document in the
Forefront TMG web farm section applies, with the notable difference that
Forefront UAG does not create Web Farm objects in TMG. Refer to the earlier
section for additional information and information about configuration
choices.

15.Click Next, and on Step 13 Authentication, click Add to add the

authorization servers that you previously configured to the list. The lower
option buttons determine how Forefront UAG will authenticate to the Client
Access server. The default 401 request means Forefront UAG will use Basic
authentication to the Client Access server. Therefore the Client Access server
must have Basic enabled on the /owa virtual directory.

56

16.On Step 14 Portal Link, the default settings will create icons in the portal
for Outlook Web App access, if a portal is used. Also, if the lower check box is
selected, the portal will open Outlook Web app in a new window when it is
accessed. Click Next.

17.On Step 15 Exchange Application Authorization, you can leave the

default, which enables all authenticated users to access Exchange. This only
means that they can try to access Outlook Web App. Any Outlook Web App
policies you created in Exchange still apply, including OWAEnabled set to
false. Or, you can restrict who can access Outlook Web App at Forefront UAG
by selecting from a list of groups or even restrict access down to the user
level by adding individual users to this list.

57

18.Click Finish on the final page of the wizard to return to the management
console.

19.Click the Save icon to save the configuration. Click the Activate icon to
back-up the existing configuration and activate this new configuration.
20.If you chose 401 request on Step 13, use the EMC to open the properties of
the owa and ECP virtual directories for each Client Access server being
published, set the authentication to Basic, and then run iisreset on each
Client Access server you have changed.
58

Now you can test client access to Outlook Web App works from a client connected to
same network as the external interface of Forefront UAG
When a client first browses to the URL you are publishing,
https://mail.fabrikam.com/owa in our example, the first action is for Forefront UAG
to download to the client the Endpoint Component Manager. This allows Forefront
UAG to perform inspection of the client computer to make sure it meets the policies
specified for the portal. The user should accept the default options the different
dialog boxes present and, when complete, they will see the Outlook Web App sign-in
page.

59

After Outlook Web App is working, we can add Outlook Anywhere and Exchange
ActiveSync to the configuration. If you cannot open Outlook Web App now, review

60

the troubleshooting steps later in this document, then return to complete the
Outlook Anywhere and Exchange ActiveSync configuration.
1. Open the Forefront UAG management console, and navigate to the properties
of the trunk you previously created.

2. In the Application section of the page, click Add to open the Welcome to the
Add Application Wizard dialog box, and then click Next. In Web list, click
Microsoft Exchange Server (all versions).

61

3. On Step 2 Select Exchange Services, in the Exchange versions list,

click Microsoft Exchange Server 2010, and then select the Outlook
Anywhere (RPC over HTTP) and Exchange ActiveSync check boxes. If
you view the configuration later and decide you want more control over
individual settings for Outlook Anywhere and Exchange ActiveSync, you can
run this wizard once for each protocol. We keep them together in this
walkthrough because, most of the time, when Outlook Anywhere and
Exchange ActiveSync use the same authentication scheme, the settings for
both are compatible.

4. On Step 3 Configure Application, select a descriptive name for the

application

62

5. On Step 4 Select Endpoint Policies, leave the defaults for now, and then
click Next.

6. On Step 5 Deploying an Application, select Configure a farm of

application servers.

7. On Step 6 Load-Balanced Web Servers, enter the FQDNs of the servers

in the Client Access server array you are publishing.

63

8. On Step 7 Configure Connectivity Verifiers, click Establish a TCP

connection for the reasons described earlier.

9. On Step 8 Authentication, select the Authorization source you have

previously configured.

64

10.Accept the warning message, which effectively states that Outlook Anywhere
and Exchange ActiveSync clients cannot use forms-based authentication or
the portal and so will use Basic or NTLM authentication.

11.On Step 9 Outlook Anywhere, notice that the default Public Host Name
values have been completed. Click Use Basic authentication to change the
default Outlook Anywhere Authentication option for both services so that
Forefront UAG can delegate credentials to the Client Access server correctly.

65

12.On the Authorization page of the wizard, either leave the default of allowing
all users to connect or click to restrict the service to specific groups or users.
Again, as with Outlook Web App, any options set within Exchange by using
the Set-CASMailbox cmdlet will still apply.
13.Click Finish on the wizard completion page.

14.Viewing the management console, you will now see the additional application
entries the wizard has created. Autodiscover and EWS have been put into
rules separate from Outlook Anywhere and EAS.

When you have activated the configuration, the next step is to configure
Exchange to correctly allow Basic authentication to be used against the
different virtual directories required for Outlook Anywhere and Exchange
ActiveSync.
66

15.Enable Outlook Anywhere on each published Client Access server, clicking

Basic authentication as the Client authentication method. After all
changes are made, iisreset has been run, and event ID 3006 is logged
showing that the appropriate registry keys have been set.

If this is the first time Outlook Anywhere has been enabled, several more
steps are required to ensure users outside Forefront UAG can fully use
Outlook. Also, one more step is required so that Exchange ActiveSync can use
the Autodiscover service. You should run these on each server in the Active
Directory site you are publishing, replacing the server host name as
appropriate.
a) Set the external URL for the offline address book (OAB) virtual directory. It
is assumed that the OAB is already enabled for Web-publishing. If it's not,
see Configure Offline Address Book Distribution Properties.
Set-OABVirtualDirectory RED-CAS-1\* -ExternalURL
https://mail.fabrikam.com/OAB

b) Set the external URL for the Exchange Web Services (EWS) virtual
directory to https://mail.fabrikam.com/EWS/Exchange.asmx.
Set-WebServicesVirtualDirectory RED-CAS-1\* -ExternalURL
https://mail.fabrikam.com/EWS/Exchange.asmx

c) Set the external URL for the Exchange ActiveSync virtual directory to allow
the Autodiscover service to provide devices with the correct value.
Set-ActivesyncVirtualDirectory red-cas-1\* -externalurl
https://mail.fabrikam.com/Microsoft-Server-Activesync

67

d) Set the authentication property for the OAB and EWS virtual directories to
include Basic as an option if you are using Basic authentication.
Set-OabVirtualDirectory red-cas-1\* -BasicAuthentication:$true
Set-WebServicesVirtualDirectory RED-CAS-1\* -BasicAuthentication:$true

16.At this point that you should test this configuration to make sure it works as
expected. From an Outlook 2007 or Outlook 2010 client on the external
network, first make sure that an A record for autodiscover.fabrikam.com
exists in DNS, then make sure that Outlook Anywhere is enabled on the Client
Access server in the site you are publishing and that all relevant URLs are
correct, and then try to create a new Outlook profile. It's very important to
ensure that the Autodiscover service works correctly for an Outlook client
because the Autodiscover service provides Outlook with the location of the
different Web services it requires for usual operation, such as Out of Office
settings and offline address book downloads.
17.If Outlook Anywhere works, try to connect by using a mobile device, either
with the Autodiscover service configuring the profile or manually, by entering
the server name (mail.fabrikam.com in this example).
Additional Configuration Steps for Exchange 2010 and/or Outlook 2010
Users
If you are not publishing Outlook Web App in your environment but do allow the
publishing of Outlook Anywhere (and possibly Exchange ActiveSync) and are using
Outlook 2010, you will have to make some adjustments to the configuration to allow
an Outlook 2010 user to be able to access the Exchange Control Panel (ECP).
Exchange 2010 users require access to the ECP for certain configuration settings,
such as voice mail and message tracking information. The ECP is accessed by using
a Web browser and is invoked by a link in the Microsoft Office Backstage area of
Outlook 2010 or within the properties of a message.
In Forefront UAG, the recommendation is to publish a new application to the portal
in the trunk by using Outlook Web App as the application, and then to modify that
configuration to allow the ECP to be accessed. This approach is used to ensure that
the URL-analysis logic built in to Forefront UAG is correctly configured.
You should also consider the following factors:

If you want to use Basic, NTLM or KCD to authenticate to the Client Access
server this requires you to disable forms-based authentication on the /ECP
virtual directory on the Client Access server. If you want to offer FBA for
internal users at the same time, you can either make sure their DNS requests
for the ECP service resolve to Forefront UAG or add a secondary Web site.
This allows you to use different authentication methods on each and requires
an additional IP address. For more information, see New-EcpVirtualDirectory.
68

If you do not want to allow any user to access Outlook Web App, but do want
allow all users to access the ECP, you can disable Outlook Web App access
per user by using the Set-CasMailbox cmdlet.
If you want to allow Outlook Web App access for internal users, but not allow
Outlook Web App access from outside the corporate network, you must
restrict the resources that you publish to allow access to only those resources
that are required by the ECP. This is because the ECP uses the Outlook Web
App authentication model and uses some Outlook Web App resources to
function.

To ensure only that the ECP can be accessed via a Forefront UAG application rule,
but not Outlook Web App, run the Add Application wizard, selecting Exchange
Server 2010 as the generic application and Outlook Web App as the specific
application to publish.
On Step 6 Load-Balanced Web Servers, edit the Paths list to ensure that only
the following paths are allowed by Forefront UAG to allow access to the ECP but not
Outlook Web App:

/ecp/
/owa/auth/logon.aspx
/owa/auth/logoff.aspx
/owa/logoff.owa
/owa/auth.owa
/owa/languageselection.aspx
/owa/lang.owa*
/owa/14*

Remove any other paths added by the wizard, such as /owa, /exchange.

69

One additional step may be required if the trunk is only used for Outlook Anywhere
publishing. Changing the setting for the initial internal application that is used by
the trunk will make sure that the ECP is opened when the user logs on, not a portal
containing one application, the ECP. To do this, in the Initial Internal Application
list, click the Application Name you previously created, ECP 2010 in the example
shown.

70

When the user takes the link to the ECP, the usual endpoint detection checks run.
Then, they will be presented with the Outlook Web Appstyle sign-in form. When
they log in, the ECP should be displayed.
Troubleshooting Forefront UAG
There are many common configuration errors made when publishing Exchange. Use
this list to validate and confirm your settings.

Certificates The most common reason one or more of these clients is

unable to log on, or Forefront UAG is unable to publish is because of a
certificate error. Check the following:
Trust Does the client trust the issuer of the certificate on Forefront
UAG? And does Forefront UAG trust the issuer of the certificate on the
Client Access server? If you receive a certificate warning message
because the certificate is not trusted, resolve the problem by make
sure the client possesses the relevant root certificate and test again.
Name Mismatch If you receive a warning message because the
name on the certificate does not match the name the client was
expecting to see, resolve the problem by reissuing the certificate with
the correct names and test again.
Expiration Dates If the certificates have expired, the client will not
accept their use. Check the expiration dates and reissue the
certificates if necessary.
Matching Authentication Schemes If Forefront UAG is configured for
Basic (or 401 in Forefront UAG terminology), the appropriate virtual
directories on the Client Access server should be configured to support Basic
authentication.
DNS Are the A records for mail and autodiscover in the correct zone? And do
they have the correct IP address? The IP should resolve to the external
network adapter of Forefront TMG and, more specifically, to the IP address of
the listener configured on the Exchange publishing rules.
The Test Email AutoConfiguration tool Use this Outlook tool to confirm
that the Autodiscover service can be contacted and that the URLs it returns
are correct. To use the tool, hold down the CTRL key, and then right-click the Outlook
icon on the taskbar.

71

Use the Exchange Remote Connectivity Analyzer tool If the

environment is Internet facing, see Microsoft Exchange Remote Connectivity
Analyzer to test the configuration from the Internet.
Eliminate single server issues If you are publishing a farm of Client
Access servers, reduce the farm size to just one Client Access server and test
again. This makes troubleshooting much easier because it's easy to
determine which servers are involved in the connection attempt.
Use the Forefront UAG Web Monitor tool You can use this tool to view
the state of each member of the farm and look for errors messages in the
event log.
Check whether Forefront UAG is blocking URLs or content within
URLs If you see a message similar to you have tried to access a restricted
URL, try the following approaches to narrow the problem down:
Use the Forefront UAG Web Monitor Look for events that relates
to the problem and that indicate the rule or filter that is blocking the
content by using the Forefront UAG Web Monitor
(http://localhost:50002 on the Forefront UAG server).
Bypass URL set-checking for a particular application This will
narrow down the source of the issue. You can disable URL set-checking
per application by clicking Evaluate with enforcement on the Web
Settings tab of the application being published.

Migration Considerations
If you are migrating from an earlier version of Exchange and are following the
standard Exchange migration guidance at Upgrade to Exchange 2010 are using an
additional legacy namespace, some changes are required in Forefront UAG to
ensure a smooth migration.

72

The exact configuration that is required will depend on the clients and protocols in
use. Outlook Web App for example has a built in Single Sign On (SSO) capability
when you deploy it alongside Exchange 2007 in the same Active Directory site, or
when an Outlook Web App request for a 2003 mailbox is received. Accessing a
mailbox hosted on Exchange 2003 or Exchange 2007 using Exchange ActiveSync or
Outlook Anywhere can be performed through an Exchange 2010 Client Access
server, although in some scenarios, you may choose to provide access through an
Exchange 2007 Client Access server to users who have mailboxes on Exchange
2007.
It's fairly simple in Forefront UAG to support the Exchange SSO functionality for
Outlook Web App within the context of one trunk. However, it's not possible to
publish multiple versions of Exchange ActiveSync or Outlook Anywhere through one
trunk. Therefore, it's recommended that you provide access to legacy clients using
Outlook Anywhere or Exchange ActiveSync through Exchange 2010.
It's important to understand that at a basic level, the standard approach is to move
the existing external namespace to point to Exchange 2010, and use the newly
created legacy namespace to access earlier versions of Outlook Web App. All
access to Exchange ActiveSync and Outlook Anywhere will be through the existing
namespace, and Exchange 2010.
Using Native Exchange SSO Redirection
There are several steps required to configure this scenario:
1. Ensure that the certificates have the correct names.
2. Create a new application for publishing the legacy version of Exchange.
3. Configure Exchange to provide the redirection URLs.
In this scenario, forms-based authentication is still being performed on Forefront
UAG. Therefore, forms-based authentication on both Exchange 2003/Exchange 2007
and Exchange 2010 must be disabled, and either Basic or Windows Integrated must
be enabled, depending on the delegation settings, or Forefront UAG must be
configured to delegate forms-based authentication as discussed earlier in this
document.
It's important to understand that using the built in Forefront UAG method of SSO
requires both versions of Exchange be published on the same trunk.
Ensure Certificates Have the Correct Names
The first step in enabling SSO when using Forefront UAG is to ensure that the
certificate you are using on the Forefront UAG trunk has all the names you must
have to support the scenario. In this example, we will add legacy.fabrikam.com to
the certificate, and use that FQDN to redirect users who have mailboxes on
Exchange 2003 or Exchange 2007 to access their mailbox.
73

Add a New Application to Publish the Legacy Version of Exchange

In order to enable the legacy version of Exchange to be accessed through Forefront
UAG, it must be added to the portal, with the new host name and must be
configured to publish the legacy Exchange Client Access server or front-end servers.
1. In the Applications section of the trunk you previously created, click Add to
add the new application, and then click Next at the Welcome screen.

74

2. In the Web list, click Microsoft Exchange Server (all versions).

3. On Step 2 Select Exchange Services, in the Exchange version list,

click Microsoft Exchange Server 2007, whether you are publishing
Exchange 2007or Exchange 2003. If you select Exchange 2003, you will not
be able to select a different host name (legacy) later in the wizard. Notice
how the ability to select multiple Exchange services is unavailable when
publishing legacy versions of Exchange.

4. On Step 3 Configure Application, name the application.

75

5. On Step 4 Select Endpoint Policies, click Next.

6. On Step 5 Deploying an Application, click Configure a farm of
application servers, and then click Next.
7. On Step 6 Load-Balanced Web Servers, enter the FQDNs of the
Exchange 2003 or Exchange 2007 servers that you are publishing. In the
Public host name box, change the default value to legacy (or the name
you are using for the legacy version of Exchange when accessed from outside
the network.

8. On Step 7 Configure Connectivity Verifiers, select Establish a TCP

connection, and then click Next.
9. On Step 8 Authentication, select the authentication server source that
you previously defined, and then click Next.
10.On Step 9 Portal Link, leave the defaults, and then click Next.
11.On Step 10 Authorization, again leave the defaults (or change them if
you choose to do this), and then click Next.
76

12.Finish the wizard, and you will be returned to the Forefront UAG console.
13.Click the Activate Configuration button and prompt to back up the
configuration when it is requested.
Configure Exchange 2010 to Provide the Redirection URLs
Next, if you are migrating from Exchange 2003 to Exchange 2010, on all the
Exchange 2010 Client Access servers being published, set the Exchange2003 URL
property on the owa virtual directory to match the value of the legacy URL you are
using, In this case, https://legacy.fabrikam.com/exchange.
Set-OWAVirtualDirectory RED-CAS-1\* -Exchange2003URL
https://legacy.fabrikam.com/exchange

If you are migrating from Exchange 2007 to Exchange2010, make sure that the
externalurl parameter on the Exchange 2007 Client Access server OWA virtual
directory is set correctly.
Set-OWAVirtualDirectory RED-CAS-2007\* -ExternalURL https://legacy.fabrikam.com/owa

If you are migrating from a mixed Exchange 2003 and Exchange 2007 environment
to Exchange 2010, you should first make sure that all Exchange 2003 access is
through the Exchange 2007 Client Access servers. This is the norm when you
migrate from Exchange 2003 to Exchange 2007. In this scenario, and when both the
previous commands are executed, Exchange 2003 users will be redirected to the
/exchange virtual directory on the Exchange 2007 Client Access server and
Exchange 2007 users will be redirected to the /owa virtual directory on the
Exchange 2007 Client Access server. This allows all three versions of Exchange to
be accessed through a single URL, https://mail.fabrikam.com/owa.
Note: If a user tries to browse to https://mail.fabrikam.com/exchange, as
would be the case for an Exchange 2003 user who had bookmarked the page
they previously used, they will be automatically redirected to
https://mail.fabrikam.com/owa and provided with a form they can use to log
in.
Configure Authentication
On all the Exchange 2003 and Exchange 2007 front-end or Client Access servers
being published by the new application, you should disable forms-based
authentication and enable Basic authentication to enable Forefront UAG to delegate
credentials correctly.
On Exchange 2003, you disable forms-based authentication by navigating to the
Administrative Group, Servers, Servername, Protocols, HTTP, Exchange Virtual
Server object, then selecting properties and clearing the check box. Basic
authentication is enabled by default, so no changes other than running iisreset are
necessary.
77

On Exchange 2007 Client Access servers, you can disable forms-based

authentication and enable Basic authentication by changing the properties of the
four relevant virtual directories, either in the Exchange Management Console or the
Exchange Management Shell.

The change from FBA to Basic authentication must be completed on the owa,
Exchange, Exchweb, and Public virtual directories. After making these changes you
must run iisreset.
Ensure DNS is Correct and Test the Configuration
Ensure that the A record for legacy.fabrikam.com in external DNS resolves to the
same IP address as mail.fabrikam.com.
Test the 2007 configuration by navigating to https://mail.fabrikam.com/owa and
logging on to an Exchange 2007 mailbox. You should be silently redirected to
https://legacy.fabrikam.com/owa and automatically logged on without additional
prompts for credentials although you will likely be prompted to accept the new
FQDN of the portal as trusted.

78

Test the Exchange 2003 configuration by navigating to

https://mail.fabrikam.com/exchange or https://mail.fabrikam.com/owa, and then
logging on to an Exchange 2003 mailbox. You should be silently redirected to
https://legacy.fabrikam.com/Exchange and automatically logged in without prompts
for credentials.

If you access Exchange 2003 through an Exchange 2007 Client Access server and,
when you log on to Exchange 2003, are redirected and logged on but see issues
with the images within the session, as shown, you should take one additional step.

In the Forefront UAG management console, open the OWA 2003/7 application and
navigate to the Web Settings tab. Check the box for Evaluate without enforcement,
under the Verify URLs check box, then click OK and apply the configuration to
79

Forefront UAG. You should then be able to access Exchange 2003 mailboxes through
Exchange 2007 without any issues.

This issue occurs because the built-in URL filtering mechanism Forefront UAG uses
for OWA 2007 does not correctly apply when an Exchange 2003 mailbox is accessed
through an Exchange 2007 Client Access server.
Exchange ActiveSync Migration
As previously discussed, when publishing Exchange using Forefront UAG and
migrating from legacy versions of Exchange to Exchange 2010, it's generally
80

recommended that you provide all access to Exchange ActiveSync clients through
Exchange 2010. It's not possible to publish more than one application providing
Exchange ActiveSync within the same trunk.
However, you may decideperhaps for pilot and testing reasonsthat you do have
to publish multiple versions of Exchange ActiveSync through Forefront UAG at the
same time. Of course, you can do this if you create a new trunk, with a new IP
address, certificate, and so on, and configure the application appropriately. Just
follow the steps described earlier in this walkthrough to create a new trunk and
publish a new application.
Outlook Anywhere Migration
As previously discussed, when publishing Exchange by using Forefront UAG and
migrating from legacy versions of Exchange to Exchange 2010, it's generally
recommended that you provide all access to Outlook Anywhere clients through
Exchange 2010. It's not possible to publish more than one application providing
Outlook Anywhere within the same trunk.
However, you may decideperhaps for pilot and testing reasonsthat you do have
to publish multiple versions of Outlook Anywhere through Forefront UAG at the
same time. Of course, you can do this if you create a new trunk, with a new IP
address, certificate, and so on, and configure the application appropriately. Just
follow the steps described earlier in this walkthrough to create a new trunk and
publish a new application.
Remember that the recommended scenario for the migration itself is to just move
the existing Outlook Anywhere endpoint that your clients use to Exchange 2010,
and allow Exchange 2010 Client Access servers to proxy connections back to legacy
versions of Exchange when needed. Exchange 2003, Exchange 2007, and Exchange
2010 users can access their mailboxes by using Exchange 2010 Client Access
servers. Therefore, the simplest approach is to publish just Exchange 2010 as the
Outlook Anywhere endpoint because the configuration of the client does not have to
changeeither at the beginning of the deployment when the Exchange 2010 Client
Access server is introduced or when their mailbox is moved to an Exchange 2010
mailbox server.
If you decide, for whatever reason, you have to have separate namespaces for
Outlook Anywhere, consider the following:

Users who have mailboxes on Exchange Server 2010 cannot use Outlook
Anywhere through an Exchange 2003 front-end server or an Exchange 2007
Client Access server, because neither of these versions of Exchange
understand the RPC Client Access Service component in Exchange 2010, and.
So, they do not consider the endpoint the client is trying to reach as valid.

81

Outlook 2003 does not use the Autodiscover service to update or change any
configuration settings. So, if a mailbox is moved between versions of
Exchange and different Outlook Anywhere endpoints are used, the client
profile will break and prevent access.
Outlook 2007 clients sometimes cannot correctly update the Outlook
Anywhere settings following a move between two Outlook Anywhereenabled
endpoints. For example, if you were publishing Exchange 2007 and Exchange
2010 by using different Outlook Anywhere host names, and a users mailbox
were moved between Exchange 2007 and Exchange 2010, the client may not
correctly update the host name used by Outlook Anywhere.

The standard recommendation of moving the existing namespace to Exchange 2010

and allowing Exchange 2010 Client Access servers to access all legacy versions of
Exchange means very little user impact and minimal client configuration changes.

82

Appendix
Using Alternative Authorization and Access Providers
If you decide not to join Forefront TMG/Forefront UAG to your Active Directory but
you still want to pre-authenticate users, you have to choose some other form of
authorization source to enable Forefront TMG/Forefront UAG to determine whether
the user should be able to access the resource.
It's recommended that you join Forefront UAG to the Active Directory and place it
behind another firewall. Therefore, using Active Directory domain membership and
authentication is recommended.
Forefront TMG and Forefront UAG offer multiple choices when you are choosing an
authorization source. But from an Exchange perspective, because of to the way
Exchange is highly integrated into Active Directory, using Active Directory as the
final authorization source is essential. There are different ways to enable Forefront
TMG/Forefront UAG to access Active Directory, directly through Active Directory
membership, through LDAP and through Radius. But it should also be noted that
when Forefront TMG and Forefront UAG are not domain joined, some scenarios,
most notably certificate-based authentication and the use of KCD, are not possible.
This guide covers using Forefront TMG and LDAP to access Active Directory. If you
want to use Radius, RSA Secure ID, or Radius OTP on Forefront TMG, or else use one
of the other methods available in Forefront UAG, please refer to the appropriate
online documentation.
LDAP Authentication
If you decide not to join Forefront TMG or Forefront UAG to your Active Directory,
using LDAP authentication is fairly easy to configure and enables Forefront
TMG/Forefront UAG not only to allow or deny access based on username/passwords,
but also to take advantage of Active Directory groups in publishing/access rules.
Using Radius as an authentication source does not allow group memberships to be
used in publishing rule restrictions.
Configuring Active Directory as an LDAP source in Forefront TMG
Configuring Forefront TMG to use LDAP authentication is performed on a per listener
basis. Each listener you configure has settings for the Client Authentication Method
(the settings a client uses to authenticate to Forefront TMG) and an Authentication
Validation Method (How Forefront TMG will validate the credentials)

83

In the example shown, the client will authenticate to the listener using a form, or
Basic authentication if the client does not support it, as with Exchange ActiveSync
or Outlook Anywhere, then Active Directory will use LDAP against Active Directory to
validate the credentials.
Clicking the Configure Validation Servers lets you configure the LDAP and Radius
Servers Forefront TMG will use.

The LDAP Server Set dialog lets you specify a group of domain controllers to use for
authentication. Solely for reasons of security, it's recommended that you use LDAPs,
which requires the domain controller to have a certificate with its own FQDN
specified on an installed certificate. The Forefront TMG wizards state this is a
84

requirement for password changes. This was true for earlier versions of Exchange,
but is no longer the case as the Client Access server itself handles the password
changes from inside the Outlook Web App application.

The Login Expression settings refer to the way Forefront TMG will match log on
attempts to LDAP Server Sets. For example, if you were publishing two Exchange
organizations using Forefront TMG, which is possible when using LDAP
authentication, you could send the authorization request a user makes to two
different DCs, based on the domain they specified when they tried to log on:
Contoso\alias requests going to one DC/GC and Fabrikam\Alias going to another. You
can also do the same with UPN logins, using an expression such as
*@fabrikam.com.
If you have a single Active Directory and are using LDAP, we recommend that you
set the Login Expression to *. This means that the logon will be sent in the format in
which it's received by Forefront TMG, that is, UPN logins are sent as UPNs,
domain\alias logins sent as domain\alias.

85

As soon as they are configured, authentication should work exactly as if Forefront

TMG were using Active Directory directly as a domain member.
Using Groups in Publishing Rules
Using a group from Active Directory to restrict who can access a publishing rule is
easy to do. From the Users tab of the publishing rule, click Add, New, and then give
your group a meaningful name.

Click Add, and then select LDAP.

86

Select the LDAP Server Set That You created when you set up the LDAP source, and
then specify the name of the groupthe exact display name as shown in Active
Directory. If you do not match the name exactly you will receive an error at the next
step.

Click OK and provide credentials to access Active Directory. The group will be
validated and populate the dialog list.

87

Click Next and Finish, and the new group is complete. Then select the group, click
Add, and changes to the rule are complete.

Remove any unnecessary groups from the list and apply the changes to Forefront
TMG.

88

Additional Information
For more information about Exchange Server, see the following resources:

Microsoft Exchange Server 2010

Exchange Server 2010: Exchange 210 Help
Unified Communications Certificate Partners for Exchange Server and for
Communications Server

For more information about Forefront UAG, see the following resources:

Forefront Unified Access Gateway 2010

Forefront Unified Access Gateway (UAG)

For more information about Forefront TMG, see the following resources:

Forefront Threat Management Gateway 2010

Forefront Threat Management Gateway (TMG) 2010

Legal Notice
This document is provided as-is. Information and views expressed in this
document, including URL and other Internet Web site references, may change
without notice. You bear the risk of using it.
Some examples depicted herein are provided for illustration only and are fictitious.
No real association or connection is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual
property in any Microsoft product. You may copy and use this document for your
internal, reference purposes.
2010 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Mobile, Windows Server, Active Directory,
ActiveSync, Forefront, Outlook, and SharePoint are trademarks of the Microsoft
group of companies.
All other trademarks are property of their respective owners.

89