Enabling Forms-based Authentication for External and Internal OWA 2010 Users in Exchange 2010 published using Forefront

TMG 2010
Introduction
Organizations that have deployed or are planning to deploy Exchange 2010 into their Active Directory forest usually want to allow remote and/or mobile users to access their mailbox from outside the corporate network using one or more Exchange protocols/services. More specially, the organization wants to allow users to access their mailbox using Outlook Anywhere (OA), Outlook Web App (OWA) and Exchange ActiveSync (EAS). However, for security reasons many of these organizations have a security policy that states any remote or mobile users must preauthenticate against a reverse proxy solution located in the perimeter network before they are permitted access to a service on the internal corporate network. There are several reverse proxy solutions that support pre-authentication for Exchange users but the most popular is without doubt Forefront Threat Management Gateway 2010 (Forefront TMG 2010). By default, when enabling pre-authentication for OWA 2010 in Forefront TMG 2010, you must change the authentication method on the Internet-facing Exchange CAS servers from forms-based authentication to integrated/basic authentication depending on the authentication delegation that you will set for the listener in Forefront TMG 2010. For users that connect to their mailbox using OWA the forms-based authentication logon page has become kind of a de-facto standard which means that the organization usually want to enable FBA for both external and internal OWA users. However, this is not the only reason. For instance, if an internal client machine is shared among multiple users that logs on to the client machine using a shared domain user account (think workforce such as clinical researchers, nurses and receptionists etc.) and then authenticate using their own account when accessing a service or application would prefer to be presented with the FBA page when accessing OWA. In this article, well take a look at how this is accomplished in an Exchange 2010 based messaging environment where Exchange is published to the Internet using Forefront TMG 2010. Will Duff (Knowledge Engineer in CSS at Microsoft) and Greg Taylor (Senior PM in Exchange CXP team at Microsoft) put together a good blog post that describes the three typical scenarios when it comes to OWA access and provide best practice recommendations for each of these scenarios. However, the steps necessary to enable FBA for external and internal users are missing both from the blog post as well as the Exchange 2010 documentation on TechNet. Because it involves a lot of steps and is somewhat complex to enable FBA for external as well as internal OWA 2010 users, I thought I would share my experience around this topic with you my fellow readers. Lets get going shall we?

Lab Environment
The lab environment Ill use to show you how to enable FBA for external and internal OWA 2010 users consists of the following:

1 x Windows Server 2008 R2 Active Directory forest (Exchangeonline.dk) 2 x datacenters/locations (primary DC and failover DC) 2 x AD sites (one in primary DC and one in failover DC) 2 x subnets in primary DC ( MAPI network: 192.168.2.0/24 & replication network: 10.10.10.0/24) 2 x subnets in failover DC ( MAPI network: 192.168.6.0/24 & replication network: 10.10.11.0/24) 4 x Exchange 2010 multi-role servers (two in primary DC and two in failover DC)

4 x Domain Controllers (two in primary DC and two in failover DC) 2 x Load balancers (one hardware based LB in primary DC and one hardware LB in failover DC) 2 x Forefront TMG 2010 stand-alone arrays (one in primary DC and one in failover DC) In addition, split-DNS for the mail.exchangeonline.dk and failover.exchangeonline.dk namespaces has been, so that its the same FQDN that is used to access Exchange services from the external and internal network. Its also worth mentioning that the two TMG stand-alone arrays are domain-joined. Finally it should be noted that the same SAN certificate is used for all Exchange servers in the forest, which means the Set-OutlookProvider cmdlet has been used to specify the principal name for EXPR. The topology for the lab environment is depicted in the following diagram:

Figure 1: Topology Diagram of the lab environment

Changing the Authentication Method for OWA & ECP Virtual Directories
Okay so the first thing we want to do is to change the authentication method for the OWA and ECP virtual directory on each of the 4 Exchange 2010 multi-role servers in the environment. As explained, this is necessary in order to configure pre-authentication for OWA and ECP on the Forefront TMG arrays. The reason for this is because you cannot have FBA enabled for both the Exchange 2010 listener on the Forefront TMG arrays and on the Exchange 2010 multi-role servers since this would result in double-authentication. To change the authentication methods, launch the Exchange 2010 Management Console (EMC), and expand the Server Configuration work center node. Select the first Exchange 2010 multi-role server in the result pane followed by opening the property page for the owa (Default Web Site) virtual directory.

Figure 2: Opening the property page for the OWA virtual directory Check the authentication method from FBA to Integrated and/or Basic authentication as shown in Figure 3. Then click OK to apply the changes. Youll receive a warning stating that you also must change the authentication method for the ECP virtual directory. Note: Whether you should enable basic and/or integrated authentication depends on what type of authentication delegation you plan on configuring on the Forefront TMG 2010 arrays. The authentication method set on the Forefront TMG 2010 arrays must match the authentication set on the Exchange 2010 multi-role servers.

Adding an Additional IP Address to Each Exchange 2010 Server

Figure 3: Changing Authentication method for the OWA virtual directory Now click the Exchange Control Panel tab and open the property page for the ecp (Default Web site) virtual directory. Again, change the authentication method from FBA to Integrated Windows and Basic authentication as shown in Figure 4 and click OK to apply the changes.

Figure 4: Changing Authentication method for the ECP virtual directory Now do an IIS reset by opening the command prompt and type IISRESET followed by pressing Enter. Repeat the above steps for the remaining 3 multi-role servers. With the authentication settings changed, internal users will now be automatically logged into OWA using the credentials that were used to log on to the client machine (if FQDN used to access OWA is in the browsers local intranet zone as shown in Figure 5).

Figure 5: FQDN used to access OWA added to the local intranet zone If the FQDN is not in the local intranet zone or the user is logged on to the client machine using a non-mailbox enabled user account, she will be prompted for credential as shown in Figure 6.

Figure 6: OWA FQDN not added to the local intranet zone or integrated authentication disabled As mentioned in the introductory, in some scenarios the above behavior isnt very desirable and the organization instead want all external as well as internal users to be presented with the FBA logon page.

How Do I Enable FBA for External and Internal OWA 2010 Users?
Okay so how can we enable FBA for external and internal OWA 2010 users? Well, there are several ways to accomplish this:

Have internal users pointed to the internal interface of the Forefront TMG and utilize the forms-based authentication logon page offered by Forefront TMG. Deploy Forefront UAG instead of Forefront TMG. Forefront UAG allows you to have FBA enabled on both the Exchange 2010 Client Access Servers and on the Forefront UAG solution itself. Publish Exchange 2010 to the Internet using Forefront TMG but do not configure pre-authentication. This way the users need to go through the Forefront TMG solution, but will authenticate directly against the Exchange 2010 Client Access servers. Configure an additional OWA and ECP virtual directory on the Exchange 2010 Client Access Servers. In this article, Ill show you the last option which if you ask me is the most elegant one. For large corporate enterprises, I dont like to route traffic out to the Forefront TMG array in the perimeter network and back onto the Exchange multi-role servers after the user has authenticated. Forefront UAG is definitely an option, but theres a chance Forefront UAG doesnt match in with the overall expectations set by the corporate enterprise. Having users authenticated directly against the Exchange 2010 Client Access servers kind of defeats the purpose of publishing Exchange 2010 using Forefront TMG 2010. Of the primary benefits of publishing Exchange using Forefront TMG is the fact that users can be pre-authenticated before they are permitted access to the Exchange 2010 Client Access servers on the internal corporate network. This is actually a requirement I often see when involved in customer engagements. The first step in order to enable FBA for external and internal OWA users is to add an additional IP address to each of the four Exchange 2010 multi-role servers. In the following, Ill show you how to add an additional IP address to the first Exchange 2010 multi-role server. Important: You need to use a unique (different) IP address for each Exchange 2010 server. Open Network Connections then open the property page for the PROD network interface. In Figure 7, you also see a REPLICATION interface since these servers participate in a DAG.

Figure 7: Opening the property page for the PROD interface Now take properties for Internet Protocol Version 4 (TCP/IPv4).

Figure 8: Opening the property page for TCP/IPv4 Click Advanced.

Figure 9: Clicking Advanced under the General tab On the IP Settings tab under IP Addresses, click Add and then enter an IP address that isnt used on the network. Then click Add and OK.

Figure 10: Adding an additional IP address to the PROD interface

Creating an Additional Web Site in IIS

To create an additional web site on each Exchange 2010 multi-role server, open the Internet Information Services (IIS) Manager. Now expand Server > Sites and the Default Web Site. As can be seen in Figure 1, among other Exchange 2010 specific virtual directories, we have the ecp and owa virtual directories listed under the Default Web Site.

Figure 1: OWA and ECP virtual directories under the Default Web Site Lets click Bindings under Edit Site in the work pane. Select https and click Edit. Notice that IP Address is set to All unassigned. This should not be changed for the Default Web Site since this can break remote PowerShell.

Figure 2: IP address field for the Default Web Site set to All Unassigned Okay lets create the new web site. To do so, right-click on Sites and select Add Web Site in the context menu (Figure 3).

Figure 3: Adding a new Web Site in the Internet Information Services (IIS) Manager Enter a meaningful site name such as OWA-ECP-FBA and specify a physical path such as c:\inetpub\owa-ecp-fba. Now under Binding, select HTTPS and then specify the additional IP address we added to the server in part 1 of this multi-part article. Finally, select the Exchange 2010 UC/SAN Certificate used for the Default Web Site in the SSL certificate drop-down menu.

Figure 4: Configuring the new Web Site When done with the above, click OK to create the new web site.

Figure 5: New Web Site listed in the Internet Information Services (IIS) Manager

With the new web site created, we can move over to the Exchange 2010 side of things and create and configure the required OWA and ECP virtual directories. Note: The above steps should be performed on all four Exchange 2010 multi-role servers.

Creating the ECP and OWA Virtual Directories

To create a OWA virtual directory underneath the new web site, open the Exchange Management Shell (EMS) and type the following command: New-OwaVirtualDirectory Name owa WebSiteName OWA-ECP-FBA

Figure 6: Creating a new OWA virtual directory underneath the new web site Now lets list all the OWA virtual directories on the Exchange 2010 multi-role server. In order to do so, type the following command: Get-OwaVirtualDirectory Server EX03

Figure 7: We now have two OWA virtual directories listed With the OWA virtual directory created, we can move on and create the ECP virtual directory. This is done with a slighty different command and set of parameters: New-EcpVirtualDirectory Server EX03 WebSiteName OWA-ECP-FBA

Figure 8: Creating a new ECP virtual directory underneath the new web site

Now lets list all the ECP virtual directories on the Exchange 2010 multi-role server. In order to do so, type the following command: Get-EcpVirtualDirectory Server EX03

Figure 9: We now have two ECP virtual directories listed Note: The above steps should be performed on all four Exchange 2010 multi-role servers. The new OWA and ECP virtual directories can now be seen under the additional web site in the IIS Manager as shown in Figure 10.

Figure 10: New OWA and ECP virtual directories under the additional Web Site in IIS Manager

Configuring the new OWA and ECP Virtual Directories

Okay, now we need to configure the proper URLs and authentication method for the OWA and ECP virtual directories that we just created under the additional web site. We can of course do so using the EMS which would be the easierst and quickest way to do it if you have multiple Exchange 2010 servers to deal with, but in this article well do so using the EMC.

So launch the EMC on one of the servers, then expand the Server Configuration work center, and click on Client Access. Select the first server in the result pane, then open the property page for the OWA-ECP-FBA virtual directory. As can be seen, both the internal and external URLs fields will be blank by default (Figure 11).

Figure 11: Internal and External URL for the new OWA virtual directory are blank Since we want internal users to access OWA and ECP using the same namespace (mail.exchangeonline.dk) as the one external users going through Forefront TMG 2010 will use, we will enter https://mail.exchangeonline.dk/owa in the internal URL field as shown in Figure 12.

Figure 12: Configuring the Internal URL for the new OWA virtual directory Click the Authentication tab, and then change the authentication type from Basic authentication to forms-based authentication as shown in Figure 13. Click Apply then OK to exit the property page for the new OWA virtual directory.

Figure 13: Changing the authentication settings for the new OWA virtual directory Now click on the Exchange Control Panel tab and open the property page for the ecp (OWA-ECP-FBA) virtual directory.

Figure 14: Opening the property page for the new ECP virtual directory Under the General tab specify https://mail.exchangeonline.dk/ecp in the Internal URL field (Figure 15).

Fixing Broken Exchange Services

Back in part 2 of this multi-part article, we re-configured the load balancer in each datacenter so that the HTTPS virtual service was pointed to the IP address assigned with the new web site. In this specific environment, theres only a single HTTPS virtual service configured on each load balancer and traffic to all Exchange services that are accessed via HTTPS goes through this single HTTPS virtual service. Because HTTPS virtual service now points to the new web site created back in part 2, all requests to HTTPS based Exchange services are directed to the new web site. Since the new web site only hosts an OWA and ECP virtual directory (and a couple of OWA specific virtual directory for legacy coexistence purposes), we have broken internal access to autodiscover, Exchange Web Services, Offline Address Book, Out of Office and Exchange ActiveSync as the virtual directories for these services exists underneath the Default Web Site. So how do we fix this mess? Well, this is actually pretty simple. We can introduce a new namespace for these services in each datacenter. In this article, well add a two new FQDNs (services-1.exchangeonline.dk and services-2.exchangeonline.dk) to the existing SAN certificate. When the new SAN certificate has been reissued, we can install it on the four Exchange 2010 multi-role servers and

assign it to the respective services. Since we use reverse SSL/SSL bridging, we should also remember to import this certificate on the load balancers. Not that the current HTTPS virtual service will need the two new FQDNs, but merely for the sake of using the same version of the certificate all way round.

Figure 1: SAN List on New Certificate When the new certificate has been installed, we needed to create an extra HTTPS virtual service on the load balancers and then change the URL for the above mentioned Exchange services to point to the IP address associated with this virtual service. First, we create the new virtual service. As you already know I use Load Master load balancers from Kemp Technologies in this multipart article. One cool feature in the Load Master UI is the possibility of duplicating an existing virtual service. So well open the property page of the existing HTTPS virtual service and click Duplicate VIP in the upper right corner as shown in Figure 2.

Figure 2: Duplicating an existing virtual service After having clicked on the Duplicate VIP button, well need to enter the IP address (VIP) that should be associated with the new virtual service. Well use IP address 192.168.2.192 on the load balancer in the primary datacenter and 192.168.6.192 on the load balancer in the failover datacenter. When the IP address has been entered, click Duplicate VIP (Figure 3).

Figure 3: Specifying the IP address that should be used with the new virtual service Were now presented with the property page for the new virtual service. Since we have duplicated an existing virtual service, the new service will (except for the service nickname) have the exact same basic settings as the source virtual service and these can be changed as needed.

Figure 4: Basic properties for the new virtual service Scrolling down to the next section reveals that the certificate installed on the source virtual service hasnt been copied over. Since this is an HTTPS virtual service, we need to click Add New and import the SAN certificate.

Figure 5: Adding the SAN ceritficate to the new HTTPS virtual service When certificate has been installed make sure that both SSL Acceleration Enabled and Reencrypt is ticked (Figure 6).

Figure 6: SSL Acceleration and Reencryption enabled Now, lets drill further down on the virtual service property page. More specifically down to the Real Servers for this Virtual Service section. As shown in Figure 7, the new virtual service point to the IP address assigned with the new web site we created back in part 2.

Figure 7: Virtual Service points to the IP address assigned with the new web site Delete both entries then click Add New and add the IP address assigned with the Default Web Site. In this case for the primary datacenter, this is 192.168.2.221 on EX01 and 192.168.2.222 on EX02. In the failover datacenter, its 192.168.6.221 and 192.168.6.222.

Figure 8: Adding the correct target IP addressed for the new HTTPS virtual service Okay, were now done with the load balancer side of things. Next step is to add records for the new namespace to the internal DNS.

Creating Records in Internal DNS for the New Namespaces

With the new HTTPS virtual service created and configured, time has come to create two new DNS records in the internal DNS. One named services-1.exchangeonline.dk which will point to the new virtual service on the load balancer in the primary datacenter and one named services-2.exchangeonline.dk that points to the new virtula service on the load balancer in the failover datacenter. Remember that these should be A-records and have a time to live (TTL) of 5 minutes in case you need to perform a datacenter switchover.

Figure 9: Creating DNS records for the new namespaces in internal DNS After having created the DNS recrods, you should now get a reply when pinging services-1.exchangeonline.dk and services2.exchangeonline.dk as shown in Figure 10.

Figure 10: Pinging the new DNS records created in internal DNS Alrighty, we can now move on and change the internal URLs for the respective Exchange services that should go through the new HTTPS virtual service.

Changing the Internal URL for the Broken Exchange Services

Now that we have a HTTPS virtual service that doesnt point to the additional web site we created back in part 2, we need to change the URL/URI for the Exchange services that needs to hit the Default Web Site.

Internal Autodiscover URI

Currently the Internal Autodiscover URI points to https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml in both datacenters. Note: The AutoDiscoverInternalUri on CAS servers in the failover datacenter could also have pointed at https://failover.exchangelabs.dk/autodiscover/autodiscover.xml but by doing so you can easily end up in a situation where SCPs arent reachable during a site failover. Also, cross-site traffic caused by autodiscover has a minor impact on the WAN link since autodiscover requests consists of small XML based text files. Said in another way, its a good best practice to point CAS servers in each datacenter to the same internal autodiscover URI. To have the internal autodiscover URI updated to point to services-1.exchangeonline.dk, issue the following command on all four Exchange 2010 multi-role servers: Set-ClientAccessServer Identity EX01 -AutoDiscoverServiceInternalUri:https://mail.exchangeonline.dk/Autodiscover/Autodiscover.xml

Figure 11: Updating the Internal Autodiscover URI

Exchange Web Services (EWS)

To update the internal URL for the Exchange Web Services (EWS) virtual directory, we should use the following commands: Primary Datacenter: Set-WebServicesVirtualDirectory -Identity 1.exchangeonline.dk/ews/exchange.asmx Set-WebServicesVirtualDirectory -Identity 1.exchangeonline.dk/ews/exchange.asmx Failover Datacenter: Set-WebServicesVirtualDirectory -Identity 2.exchangeonline.dk/ews/exchange.asmx Set-WebServicesVirtualDirectory -Identity 2.exchangeonline.dk/ews/exchange.asmx "EX02\EWS (Default Web Site)" -InternalUrl https:// services"EX01\EWS (Default Web Site)" -InternalUrl https://services-

"EX03\EWS

(Default

Web

Site)"

-InternalUrl

https://services-

"EX04\EWS

(Default

Web

Site)"

-InternalUrl

https://services-

Figure 12: Updating the Exchange Web Services virtual directory

Offline Address Book (OAB)

To update the internal URL for the Offline Address Book virtual directory, we should use the following commands: Primary Datacenter: Set-OABVirtualDirectory -Identity "EX01\oab (Default Web Site)" -InternalUrl https://services-1.exchangeonline.dk/oab Set-OABVirtualDirectory -Identity "EX03\oab (Default Web Site)" -InternalUrl https://services-1.exchangeonline.dk/oab Failover Datacenter: Set-OABVirtualDirectory -Identity "EX02\oab (Default Web Site)" -InternalUrl https://services-2.exchangeonline.dk/oab Set-OABVirtualDirectory -Identity "EX04\oab (Default Web Site)" -InternalUrl https://services-2.exchangeonline.dk/oab

Figure 13: Updating the Exchange Web Services virtual directory

Exchange ActiveSync (EAS)

To update the internal URL for the Exchange ActiveSync (EAS) virtual directory, we should use the following commands:

Primary Datacenter: Set-ActivesyncVirtualDirectory -Identity EX01\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://services1.exchangeonline.dk/Microsoft-Server-Activesync Set-ActivesyncVirtualDirectory -Identity "EX03\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://services1.exchangeonline.dk/Microsoft-Server-Activesync Failover Datacenter: Set-ActivesyncVirtualDirectory -Identity "EX02\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://services2.exchangeonline.dk/Microsoft-Server-Activesync Set-ActivesyncVirtualDirectory -Identity "EX04\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://services2.exchangeonline.dk/Microsoft-Server-Activesync

Figure 14: Updating the Exchange ActiveSync virtual directory After having updating the internal URLs for the above virtual directories, its recommeende to launch an Outlook 2007/2010 client and verify that you can access OOF settings, download the OAB and view free/busy information for other users in the Exchange organization.

Figure 15: Accessing OOF Settings

If you still experience issues, you may also want to launch Test E-Mail AutoConfiguration in Outlook (by holding down CTRL and right-clicking on the Outlook icon in the System tray) and perform and autodiscover test to see whether each service points to the correct URL.

Figure 16: Testing service URL using Test E-mail AutoConfiguration

Offering Windows integrated & Basic Authentication for internal OWA/ECP Users
With the introduction of the additional HTTPS virtual service, you will also be able to offer internal OWA and ECP users Windows integrated and/or Basic authentication. You just need to point them to the new namespace. In order to make the experience as good as possible, this could for instance be accomplished by adding the respective links to the Intranet or by pushing the OWA links to the desktop using a group policy. Also, remember that in order to get an SSO experience, the new namespace must be added to the trusted zone in the Internet browsers used on each workstation.

Figure 15: Configuring the Internal URL for the new OWA virtual directory Note: The URL we specify in the Internal URL field is the URL that will be populated in the backstage center for internal Outlook 2010 clients connecting via RPC. Click on the Authentication tab and then change the authnetication method to forms-based authentication so that the authentication method match the one set for the new OWA virtual directory. Finally click Apply then OK to exit the property page for the new ECP virtual directory.

Figure 16: Changing the authentication settings for the new ECP virtual directory Repeat the above steps for all four multi-role servers, but remember that the URL for the two servers in the failover datacenter should have https://failover.exchangeonline.dk/owa specified in the internal URL for the new OWA virtual directory and https://failover.exchangeonline.dk/ecp specified in the internal URL for the new ECP virtual directory. We have now configured the new OWA and ECP virtual directories and can move on to changing the target IP addresses for the respective HTTP virtual service on the load balancers.

Changing Target Server IP Addresses on Load Balancer

Since we want to present all internal OWA and ECP users with a FBA logon page when accessing OWA/ECP via the mail.exchangeonline.dk namespace, we now need to change the HTTPS virtual service associated with OWA/ECP on the load balancer solution in each datacenter as it currently points to the IP address associated with the Default Web Site and hence presents the users with integrated Windows or Basic authentication when accessing OWA/ECP. In Figure 17 and Figure 18, we can see the current configuration for the load balancers.

Figure 17: Current configuration for the load balancer in the primary datacenter

Figure 18: Current configuration for the load balancer in the failover datacenter For the load balancer in the primary datacenter, we want to change the Exchange HTTPS virtual service to point to the 192.168.2.224 and 192.168.2.225 IP addresses that are associated with the new web site we created in IIS and for the Exchange HTTPS virtual service on the load balancer we want to point them to 192.168.6.224 and 192.168.6.225.

Figure 19: Current target IP addresses

Figure 20: New Target IP Addresses for the Exchange HTTPS Virtual Service on the load balancer in the primary DC

Verifying OWA 2010 Access for Internal Users

With the changes made on the load balancers, lets now try to access OWA from an internal client using https://mail.exchangeonline.dk/owa and https://failover.exchangeonline.dk/owa URLs. When doing so, we should now get the FBA logon page shown in Figure 21.

Figure 21: OWA 2010 FBA Logon Page Verify that you can logon to a mailbox using username, UPN or domain\user depending on which format you selected when you configured forms-based authentication.

Figure 22: OWA 2010 Also try to access the ECP page from within OWA 2010 in order to verify that ECP works as expected.

Figure 23: Accessing ECP via OWA 2010

Recap of the Exchange 2010 OWA/ECP Behaviour

So currently Exchange 2010 users accessing OWA or ECP from an internal client can do so via the https://mail.exchangeonline.dk/owa and https://mail.exchangeonline.dk/ecp and will be presented with the FBA logon page as shown in Figure 1.

Figure 1: OWA FBA Logon Page presented to Internal Users This was our primary goal. But we also let users that wish to do so connect to OWA via https://services-1.exchangeonline.dk/owa and ECP via https://services-1.exchangeonline.dk/ecp. When internal users use these URLs they will be automatically logged into OWA using the credentials that were used to log on to the client machine (if FQDN used to access OWA/ECP is in the browsers local intranet zone as shown in Figure 2).

Figure 2: Outlook Web App 2010 URLs added to the Local intranet site in Internet Explorer If the URLs are not in the browsers local intranet zone, the user will be asked to enter his username and password as shown in Figure 3.

Figure 3: Accessing OWA 2010 using Basic authentication

Forefront TMG 2010 Solution

With the internal configuration completed, its time to focus on the Forefront TMG 2010 side of things. But before we do so, let me quickly describe the Forefront TMG 2010 solution used in this multi-part article. We have a total of four Forefront TMG 2010 servers. Two in each datacenter. In both datacenters, the two Forefront TMG 2010 servers have been configured in a stand-alone array. In case we need to perform a datacenter switchover from the primary datacenter to the failover datacenter, we need to update external DNS to point to the Forefront TMG 2010 stand-alone array in the failover datacenter. Because of this we will create identical web publishing rules on both TMG 2010 stand-alone arrays. Only difference is well use the mail.exchangeonline.dk namespace on the TGM stand-alone array in the primary datacenter and the failover.exchangeonline.dk namespace on the TMG 2010 stand-alone array in the failover datacenter. In addition, the web publishing rules will of course point to the local Exchange 2010 multi-role servers (Figure 4) or the load balancer solution (Figure 5). Well discuss the pros and cons of each approach later in this multi-part article.

Figure 4: Pointing Forefront TMG Web Publishing rules at the Exchange 2010 Multi-role Servers

Figure 5: Pointing Forefront TMG Web Publishing rules at the Load Balancer Solution

Importing the New SAN Certificate to Forefront TMG 2010

The first thing we need to do is to import the new SAN certificate to the personal store on all four Forefront TMG 2010 servers (remember you need to include the private key in order for TMG to inspect the HTTPS packets). To import the certificate on the TMG 2010 servers, copy the exported SAN certificate from one of the Exchange 2010 servers to TMG 2010 and then import it into the personal store (computer account) using the Certificates MMC snap-in. This is done by first opening an empty MMC by clicking Start > Run and typing MMC.exe. In the empty MMC console, click File > Add/Remove Snap-in (Figure 6).

Figure 6: Clicking Add/Remove Snap-in in Empty MMC console Now select Certificates under Available snap-ins and click the Add button (Figure 7).

Figure 7: Selecting the Certificates snap-in Now make sure to select Computer account then click Next (Figure 8).

Figure 8: Selecting Computer account Select Local computer and click Finish (Figure 9) and OK.

Figure 9: Selecting Local computer Expand Certificates and right-click on Personal. In the context menu, select All Tasks > Import as shown inFigure 10.

Figure 10: Clicking Import in the context menu On the certificate import wizard welcome page, click Next (Figure 11).

Figure 11: Welcome to the Certicate Import Wizard On the File to import page, click Browse (Figure 12).

Figure 12: File to Import

Now navigate to the folder containing the certificate you wish to import and then click on the cetificate followed by click Open (Figure 13).

Figure 13: Pointing at the certificate that needs to be imported Enter the password that has been used to protect the certifcate and click Next (Figure 14).

Figure 14: Entering the password that has been used to protect the certificate Make sure Place all certificates in the following store is selected and then click Next.

Figure 15: Certificate Store Now click Finish to exit the certificate import wizard (Figure 16).

Figure 16: Completing the Import Certificate Wizard As can be seen in Figure 17, we now have imported the certificate we need for the Forefront TMG 2010 web publishing rules.

Figure 17: SAN Certificate now imported to the person computer account store Bear in mind that even though we now have imported the required certificate, it doesnt mean we have the necessary intermediate certificate. So please make sure the certificate chain isnt broken. If you use certificates from Digicert, you can use a nice little utility to check this and even repair any issues it may find (Figure 18).

Figure 18: Digicert Certificate Utility The above steps should be completed on all four Forefront TMG 2010 servers.

Should I Publish the Exchange 2010 Servers or the Load Balancer?

The time has come to create the OWA/ECP web publishing rule. But first we need to decide whether we want to publish our load balancer solution or the Exchange 2010 multi-role servers. For midsize to large enterprise customers, I ususally recommend publishing the Exchange 2010 servers directly and thereby take advantage of the Forefront TMG 2010 web farm load balancing functioanality. This provides the best distribution of incoming client access traffic. You see, if you chose to publish the load balancer, the client access requests that are proxied from Forefront TMG to the load balancer would all appear to come from the same source IP address and hence the same client. This means that the load balancer would send all client requests coming from Forefront TMG to the same Exchange 2010 server. This is default behaviour and controlled under the To tab of a web publishing rule as shown in Figure 19.

Figure 19: Requests appear to come from the Forefront TMG computer As can be seen you have the option to change the Proxy request to published site from Requests appear to come from the Forefront TMG computer to Requests appear to come from the original client, but for this to work you would need to set the Forefront TMG server as the default gateway on the Exchange 2010 servers, which is far from ideal in most enterprise environments (especially when using DSR with your load balancer solution). If youre fine with not having external client requests that come in via Forefront TMG distributed across the Exchange 2010 servers, then go ahead and publish the load blaancer VIP. One advantage of doing so is that all client traffic follows the same common path. Which makes it easier to troubleshoot client access connectivity issues. However, if youre a midsized to large enterprise, then I recommend you publish the Exchange 2010 servers directly using the web farm load balancing functioanlity in Forefront TMG 2010. This is the approach we will follow in this article. Important: If you choose to publish the load balancer please bear in mind that tou need to publish the virtual service that points to the IP address associated with the Default Web Site in IIS not the new web site we created.