How to: Publish Exchange Server 2010 with Forefront UAG and Forefront TMG

I’ve been trying to publish Exchange Server 2013 with Forefront TMG with no avail. However, I did find a good guide on how to publish Exchange Server 2010 with TMG so I thought I would share. I can’t find the link to the Microsoft site but I had the word document opened up so I am copy-pasting the contents below so this information is easier to be found and searched. I have also included the original word file here: Publishing Exchange Server 2010 with Forefront so that you can see the original content as well as the pictures. Hope this helps!

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 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 isn’t intended to provide the only information you use for a complex organization or one with special security constraints. Instead, it’s intended only as a walkthrough to help you publish Exchange on both these platforms, using basic configuration options. If you have a large organization, it’s likely that you’ll 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	Forefront TMG	Forefront 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		þ

 

It’s 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 user’s 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 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 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 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 trunk’s 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 third-party certification authority (CA) and the certificate used internally can be from a different CA, perhaps an internal, Active Directory–integrated 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 Directory–integrated 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 Directory–integrated 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 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 Directory–integrated 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

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:

 

Set-Content   -path “C:mail_fabrikam_com” -Value (New-ExchangeCertificate   -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.

 

1. Use the resulting request file to request a Web Server certificate at the certification authority you have chosen.
2. 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.

 

1. 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.
2. Transfer the resulting .pfx file to the Forefront TMG server.
3. On the Forefront TMG server, open a blank Management Microsoft Management Console (MMC) by clicking Start, Run and typing mmc followed by Enter.
4. 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.
5. Expand the Certificates (Local Computer) node, and then click Personal.
6. Right-click the Personal container, and then select All tasks > Import.
7. 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.
8. 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.

 

 

1. 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.

 

 

 

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

1. 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 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.

1. 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.

1. 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.

 

1. 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.

 

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

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.

 

 

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

1. 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.

1. 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 member’s health. The available health check options provide server availability as follows:
   1. 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.
   2. 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.
   3. 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.

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.

 

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.

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.

1. 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.

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

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

1. 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.

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

 

 

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

1. 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 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.

 

1. 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.
2. 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 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.

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

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.

1. 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.
2. Try to access an Exchange 2010 mailbox by using the domainusername format and password.
3. 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

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 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 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:
  • 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.
  • 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:
    • 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.
    • 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.
    • 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 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 resource’s 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.

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.

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

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.

 

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

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.

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 rule in Forefront TMG. After the user’s 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 Anywhere–enabled endpoints. For example, if you were publishing Exchange 2007 and Exchange 2010 using different Outlook Anywhere host names, and a user’s 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 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.

 

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:

• 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—mail—has 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 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 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 third-party certification authority (CA) and the certificate used internally can be from a different CA, perhaps an internal, Active Directory–integrated 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 Directory–integrated 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 Directory–integrated 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 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 Directory–integrated 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

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 (New-ExchangeCertificate   -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.

 

1. Use the resulting request file to request a Web Server certificate at the CA you have chosen to use.
2. 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.

 

1. 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.
2. Transfer the resulting .pfxfile to the Forefront UAG server.
3. 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.
4. 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.
5. Expand the Certificates (Local Computer) node, and then click Personal.
6. Right-click the Personal container, and then select All tasks > Import.
7. 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.
8. 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.

 

 

1. 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.

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.

1. 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 user’s 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.

1. 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.

1. 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.

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

1. On Step 4 – Certificate, make sure the certificate that you installed earlier is selected, and then click Next.
2. 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.
3. On Step 6 – Endpoint Policies, leave the defaults for now and then click Next
4. 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.

1. On Step 8 – Configure Application, enter an Application name–Exchange 2010 OWA in our example.

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

1. 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.

1. 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 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.

 

1. 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.

1. 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.

1. 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.

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

1. Click the Save icon to save the configuration. Click the Activate icon to back-up the existing configuration and activate this new configuration.
2. 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.

 

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.

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

1. 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).

1. 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.

1. On Step 3 – Configure Application, select a descriptive name for the application

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

1. On Step 5 – Deploying an Application, select Configure a farm of application servers.

1. On Step 6 – Load-Balanced Web Servers, enter the FQDNs of the servers in the Client Access server array you are publishing.

1. On Step 7 – Configure Connectivity Verifiers, click Establish a TCP connection for the reasons described earlier.

1. On Step 8 – Authentication, select the Authorization source you have previously configured.

1. 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.

1. 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.

1. 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.
2. Click Finish on the wizard completion page.

1. 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.

1. 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

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

1. 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.
2. 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.
• 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.

 

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.

When the user takes the link to the ECP, the usual endpoint detection checks run. Then, they will be presented with the Outlook Web App–style 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.

 

 

• 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.

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.

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.

 

 

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

1. 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.

1. On Step 3 – Configure Application, name the application.

1. On Step 4 – Select Endpoint Policies, click Next.
2. On Step 5 – Deploying an Application, click Configure a farm of application servers, and then click Next.
3. 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.

1. On Step 7 – Configure Connectivity Verifiers, select Establish a TCP connection, and then click Next.
2. On Step 8 – Authentication, select the authentication server source that you previously defined, and then click Next.
3. On Step 9 – Portal Link, leave the defaults, and then click Next.
4. On Step 10 – Authorization, again leave the defaults (or change them if you choose to do this), and then click Next.
5. Finish the wizard, and you will be returned to the Forefront UAG console.
6. 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.

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.

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 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 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 decide—perhaps for pilot and testing reasons—that 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 decide—perhaps for pilot and testing reasons—that 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 change—either 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.
• 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 Anywhere–enabled endpoints. For example, if you were publishing Exchange 2007 and Exchange 2010 by using different Outlook Anywhere host names, and a user’s 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.

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)

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 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: Contosoalias requests going to one DC/GC and FabrikamAlias 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, domainalias logins sent as domainalias.

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.

Select the LDAP Server Set That You created when you set up the LDAP source, and then specify the name of the group–the 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.

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.

 

 

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.