Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 6)

By /

If you would like to read the other parts of this article series please go to:

Introduction

In part 5 of this multi-part article, we started out by creating a Client Access array in each Active Directory site. Then we enabled Outlook Anywhere as well as configured the Outlook Provider settings so Outlook Anywhere clients still can connect after an *over has occurred.

In this part 6, we will continue where we left of in part 5. We will start out by configuring the internal and external URL for the CAS services on each Exchange 2010 server in both Active Directory sites. Then we will move on to creating a database availability group (DAG) and perform the basic configuration for the DAG.

Changing Internal & External Exchange 2010 CAS URLs to point to HLB

Time has come to configure the internal as well as external URLs for Exchange 2010 CAS services in each datacenter to point to each load balancer solution respectively.

So just to sum up from the previous articles in this series, “mail.exchangeonline.dk” points to the VIP address configured on the load balancer solution in the primary datacenter and “failover.exchangeonline.dk” points to the VIP address configured on the load balancer in the failover datacenter. This means that the URLs must be configured differently for each datacenter.

Outlook Web App (OWA)

Let’s begin with the URLs for Outlook Web App (OWA). For this we should use the following commands:

Primary Datacenter:

Set-OwaVirtualDirectory -Identity “EX01\OWA (Default Web Site)” -InternalURL https://mail.exchangeonline.dk/OWA -ExternalURL https://mail.exchangeonline.dk/OWA

Set-OwaVirtualDirectory -Identity “EX03\OWA (Default Web Site)” -InternalURL https://mail.exchangeonline.dk/OWA -ExternalURL https://mail.exchangeonline.dk/OWA

Failover Datacenter:

Set-OwaVirtualDirectory -Identity “EX02\OWA (Default Web Site)” -InternalURL https://failover.exchangeonline.dk/OWA -ExternalURL https://failover.exchangeonline.dk/OWA

Set-OwaVirtualDirectory -Identity “EX04\OWA (Default Web Site)” -InternalURL https://failover.exchangeonline.dk/OWA -ExternalURL https://failover.exchangeonline.dk/OWA


Figure 1:
 Configuring URLs for the OWA Virtual Directory

Exchange Control Panel (ECP)

For the Exchange Control Panel (ECP), we should use the following commands:

Primary Datacenter:

Set-EcpVirtualDirectory -Identity “EX01\ECP (Default Web Site)” -InternalURL https://mail.exchangeonline.dk/ECP  -ExternalURL https://mail.exchangeonline.dk/ECP

Set-EcpVirtualDirectory -Identity “EX03\ECP (Default Web Site)” -InternalURL https://mail.exchangeonline.dk/ECP -ExternalURL https://mail.exchangeonline.dk/ECP

Failover Datacenter:

Set-EcpVirtualDirectory -Identity “EX02\ECP (Default Web Site)” -InternalURL https://failover.exchangeonline.dk/ECP -ExternalURL https://failover.exchangeonline.dk/ECP

Set-EcpVirtualDirectory -Identity “EX04\ECP (Default Web Site)” -InternalURL https://failover.exchangeonline.dk/ECP -ExternalURL https://failover.exchangeonline.dk/ECP


Figure 2:
 Configuring URLs for the ECP Virtual Directory

Exchange ActiveSync (EAS)

For Exchange ActiveSync (EAS), we should use the following commands:

Primary Datacenter:

Set-ActivesyncVirtualDirectory -Identity EX01\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync  -ExternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync

Set-ActivesyncVirtualDirectory -Identity “EX03\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync  -ExternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync

Failover Datacenter:

Set-ActivesyncVirtualDirectory -Identity “EX02\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync  -ExternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync

Set-ActivesyncVirtualDirectory -Identity “EX04\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync  -ExternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync


Figure 3:
 Configuring URLs for the EAS Virtual Directory

Offline Address Book (OAB)

For the Offline Address Book, we should use the following commands:

Primary Datacenter:

Set-OABVirtualDirectory -Identity “EX01\oab (Default Web Site)” -InternalUrl https://mail.exchangeonline.dk/oab -ExternalURL https://mail.exchangeonline.dk/oab

Set-OABVirtualDirectory -Identity “EX03\oab (Default Web Site)” -InternalUrl https://mail.exchangeonline.dk/oab -ExternalURL https://mail.exchangeonline.dk/oab

Failover Datacenter:

Set-OABVirtualDirectory -Identity “EX02\oab (Default Web Site)” -InternalUrl https://failover.exchangeonline.dk/oab -ExternalURL https://failover.exchangeonline.dk/oab

Set-OABVirtualDirectory -Identity “EX04\oab (Default Web Site)” -InternalUrl https://failover.exchangeonline.dk/oab -ExternalURL https://failover.exchangeonline.dk/oab


Figure 4:
 Configuring URLs for the OAB Virtual Directory

Exchange Web Services (EWS)

For Exchange Web Services (EWS), we should use the following commands:

Primary Datacenter:

Set-WebServicesVirtualDirectory -Identity “EX01\EWS (Default Web Site)” -InternalUrl https://mail.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://mail.exchangeonline.dk/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identity “EX03\EWS (Default Web Site)” -InternalUrl https://mail.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://mail.exchangeonline.dk/ews/exchange.asmx

Failover Datacenter:

Set-WebServicesVirtualDirectory -Identity “EX02\EWS (Default Web Site)” -InternalUrl https://failover.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://failover.exchangeonline.dk/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identity “EX04\EWS (Default Web Site)” -InternalUrl https://failover.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://failover.exchangeonline.dk/ews/exchange.asmx


Figure 5:
 Configuring URLs for the EWS Virtual Directory

Unified Messaging (UM)

We don’t use Unified Messaging (UM) in this lab environment, but if you have other plans you would need to configure the URLs using the following commands:

Primary Datacenter:

Set-UMVirtualDirectory -Identity “EX01\unifiedmessaging (Default Web Site)” -InternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx

Set-UMVirtualDirectory -Identity “EX03\unifiedmessaging (Default Web Site)” -InternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx

Failover Datacenter:

Set-UMVirtualDirectory -Identity “EX02\unifiedmessaging (Default Web Site)” -InternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx

Set-UMVirtualDirectory -Identity “EX04\unifiedmessaging (Default Web Site)” -InternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx

Internal Autodiscover URI

Finally we need to point the Autodiscover Service Internal Uri to the FQDN of the HLB. This can be done using the following commands:

Primary Datacenter:

Set-ClientAccessServer –Identity EX01 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml

Set-ClientAccessServer –Identity EX03 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml

Failover Datacenter:

Set-ClientAccessServer –Identity EX02 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml

Set-ClientAccessServer –Identity EX04 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml


Figure 6:
 Settings the Internal Autodiscover URI

Notice that we point the Exchange 2010 servers in both datacenters at the same autodiscover URI. You could also point the AutoDiscoverInternalUri on CAS servers in the failover datacenter at “https://failover.exchangelabs.dk/autodiscover/autodiscover.xml” but by doing so you can easily up on in a situation where SCP’s aren’t 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.

Creating and Configuring Mailbox Databases

Already we’re done with the CAS side of things for now and can begin concentrating on creating the mailbox databases as well as establish and configure the database availability group (DAG).

In the lab environment used for this multi-part article, I have created 12 mailbox databases distributed across the two Exchange 2010 servers in the primary datacenter as shown in Figure 7.


Figure 7:
 Exchange 2010 Mailbox Databases

Note:
Since Outlook 2003 clients aren’t used in this environment and public folders aren’t used as data repository no public folder databases exists here. If the situation is different in the particular environment you’re dealing with, bear in mind that you cannot use DAG functionality to protect public folder data (like you could with CCR in Exchange 2007). Instead you must create at least one public folder database in each datacenter and add the respective servers holding public folder databases to the replica list for each public folder.

As you can see I’ve named the databases DAG01-MDB001, DAG01-MDB002, and so on. Not because I’m lazy but because there really no longer is a need to use complicated or fancy database names now that mailbox databases. For databases that will be part of a DAG, it’s a good best practice to use a naming standard where the database name is prepended with the name of the DAG it belongs to. In regards to the database and log folder paths it’s good to use something like E:\DAG_name\Database_name.edb and F:\Dag_name\Database_name.

Note:
When you have multiple copies of a database, you don’t necessarily need to use dedicated log file LUNs and can instead just use the same path as the one used for the .edb file (in our example “E:\DAG_name\Database_name”). This is fully supported and a good best practice as long as you don’t use a hardware-based VSS backup solution to back up your Exchange databases. Needless to say you should of course also used mount points as you otherwise quickly will run out of drive letters.

Adding the Exchange Trusted Subsystem group to Non-Exchange Servers

As those of you that have deployed either Exchange 2007 CCR based mailbox severs or Exchange 2010 Mailbox servers that participate in a DAG already should know a best practice is to use a Hub Transport server in same Active Directory site as the witness server for a CCR cluster or a DAG.

Since this environment consists of Exchange 2010 multi-role servers all part of the same DAG, we can’t use an Exchange 2010 Hub Transport server as the witness server, but instead need to use a traditional Windows Server 2008/R2 File server for this purpose. Because of this we need to add the “Exchange Trusted Subsystem” group created by Exchange 2010 setup to the local administrators group on the respective file server. This is so the right permissions are granted to Exchange. To do so, log on to the fileserver and open “Server Manager”. Expand “Configuration” > “Local Users and Groups” and then open up Properties for the Administrators group.


Figure 8:
Finding the local administrators group on the Windows Server 2008 R2 file server

Now enter the “Exchange Trusted Subsystem” in the text box as shown in Figure 9, then click OK.


Figure 9: Entering the Exchange Trusted Subsystem group

Click OK again.


Figure 10: Property page of the Administrators group

As mentioned, this step is only necessary when using a non-Exchange server as the witness server.

Note:
It is not recommended to use a domain controller as the witness server.

Creating and Configuring the Database Availability Group

Because we only have active users in one datacenter at a time (aka active/passive user distribution model), it’s sufficient with a single stretched DAG in this scenario.

To create a basic DAG, let’s launch the “New Database Availability Group” wizard. This can be done by expanding the “Organization Configuration” work center and right-clicking on “Mailbox” followed by selecting “New Database Availability Group” in the context menu. In the wizard we need to specify the name of the DAG and enter the name of the witness server. Lastly, we need to specify the path of the witness directory. I’ll name the DAG “DAG01” and use a domain-joined file server (FS01) as witness server. When done, click “New”.


Figure 11: creating the DAG

On the Completion page, we get a warning that the “Exchange Trusted Subsystem” group isn’t a member of the “Local Administrators” group on the specified witness server. You can ignore this error as we already added this group.

Click Finish to exit the wizard (Figure 12).


Figure 12:
 Database Availability Group wizard – Completion page

Configuring an Alternate Witness Server

When it comes to using a DAG stretched between two datacenters (AD sites), it’s recommended to pre-configure an alternate witness server, which in this scenario is a file server (FS02) in the failover datacenter.

To do so we need to first add the “Exchange Trusted Subsystem” group to the “Local Administrators” group using the same steps as those we went through above. Then we need to specify FS02 as the alternate witness server on the DAG object itself. To do so, open the property page for the DAG “DAG01”. Under the “General” tab we can see the primary witness server FS01 and the witness directory used on this server. Underneath, we have the option of entering the alternate witness server (Figure 13). Do so and click “Apply”. Don’t close the property page just yet.


Figure 13: Specifying the Alternate Witness Server

Assigning Static IP Addresses to the Database Availability Group

Although it’s supported to use DHCP assigned IP addresses for a DAG, I like to use static IP addresses for this so next step will be to specify a static IP address for the DAG in each datacenter (on each subnet).

Note:
If you want to use DHCP assigned IP addresses, feel free to skip this step.

To assign a static IP address click on the “IP Addresses” tab. Under the “IP Addresses” tab assign an IP address from each subnet to the DAG. Then click “OK” to exit the property page.


Figure 14: Static IP address assigned to the DAG

We now have a basic DAG created and configured.

This ends part 6 of this multi-part article.

If you would like to read the other parts of this article series please go to:

About The Author

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top