If you would like to read the other parts of this article series please go to:
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 1)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 2)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 3)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 5)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 6)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 7)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 8)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 9)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 10)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 11)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 12)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 13)
Introduction
In part 3 of this multi-part article, we prepared the Active Directory forest for Exchange 2010 and installed the Exchange 2010 roles on the four servers in our setup. In addition, we prepared the namespaces required for this scenario.
In this part 4, we will continue where we left of in part 3. We will start out by installing a trusted SAN/UC certificate on the Exchange 2010 servers followed by configuring static RPC ports for the RPC Client Access service and the Exchange Address Book service.
Installing a Trusted Certificate on the Exchange 2010 Servers
In order for clients (such as Outlook Anywhere, Outlook Web App and Exchange ActiveSync) to be able to connect properly and without certificate warnings, we need to install a trusted UC/SAN certificate (alternatively a wildcard certificate), that includes the necessary FQDNs. As I showed you back in part 3, the FQDNs we need on the certificate in this specific scenario are:
- Mail.exchangeonline.dk (principal/common name)
- Failover.exchangeonline.dk
- Autodiscover.exchangeonline.dk
Note that the namepace we use for Outlook MAPI connections don’t have to be included in the certificate since MAPI connections doesn’t use SSL unless we’re speaking Outlook Anywhere where MAPI is encapsulated in HTTPS packets.
Creating the Certificate Request
In this article we’ll use the Exchange 2010 New Certificate wizard to create the certificate request. So let’s launch the Exchange Management Console followed by selecting the “Server Configuration” work center. Now right-click on one of the Exchange 2010 servers and select “New Exchange Certificate”. The new Exchange Certificate wizard launches. Enter a meaningful name for the certificate and then click “Next”.
Figure 1: New Exchange Certificate wizard – Introduction page
If you plan on using a wildcard certificate, this is where you enable and configure this. In this article we will use a UC/SAN certificate, so click “Next”.
Figure 2: New Exchange Certificate wizard – Domain Scope page
We have now reached the interesting page. This is where we need to enter the FQDNs (domains), that should be included in the certificate. Since we use a split DNS model, we only have to enter “mail.exchangeonline.dk” and “failover.exchangeonline.dk” in the OWA fields.
Figure 3: New Exchange Certificate wizard – Exchange Configuration page
And same FQDNs should be entered under Exchange ActiveSync.
Figure 4: New Exchange Certificate wizard – Exchange Configuration page (cont.)
Under Client Access server (Web services, Outlook Anywhere, and Autodiscover), the same FQDNs as used above should be entered. Finally under Autodiscover, we enter “autodiscover.exchangeonline.dk”. Since we don’t use POP3 or IMAP4, we won’t configure these services.
Click “Next”.
Figure 5: New Exchange Certificate wizard – Exchange Configuration page (cont.)
Enter the relevant organization and location information. Also make sure you specify where the cert.req file should be saved and then click “Next”.
Figure 6: New Exchange Certificate wizard – Organization and Location page
On the “Certificate Domains” page, we need to make sure “mail.exchangeonline.dk” is set as the common name. We can then click “Next”.
Figure 7: New Exchange Certificate wizard – Certificate Domains page
On the “Certification Configuration” page, click “New” to generate the request.
Figure 8: New Exchange Certificate wizard – Certificate Configuration page
Click “Finish” to exit the wizard.
Figure 9: New Exchange Certificate wizard – Completion page
We can now see there’s a pending certificate request (Figure 10).
Figure 10: Pending Certificate Request
Next step is to have the certificate request processed by a certificate provider, so you can have a certificate issued. This process differs from provider to provider and is therefore out of scope.
When you have the certificate, you need to right-click on the pending certificate request in the EMC, and then select “Complete Pending Request” in the context menu.
In the “Complete Pending Request” wizard, point to the certificate and click “Complete”.
Figure 11: Complete Pending Certificate Request
On the “Completion” page, click “Finish”.
Figure 12: Completing the Pending Certificate Request
We now need to export the certificate with its private key so that we can import it on the other 3 Exchange 2010 servers. To do so right-click on the certificate in the EMC, and select “Export Exchange Certificate”. On the “Introduction” page select where it should to exported to and then specify a password. Then click “Export”.
Figure 13: Exporting the Exchange Certificate
One of the cool things about the Exchange Certificate wizard is that we can multi-import it to Exchange 2010 servers in one step. To do so right-click on an Exchange 2010 server under “Server Configuration” in the EMC, then select Import Exchange Certificate”. We can now add all 3 remaining servers to the “Select Servers” list as shown in Figure 14 followed by clicking “Next”.
Figure 14: Importing the Exchange Certificate
Now we need to specify for which services we want to enable the certificate. In this specific setup, “Internet Information Services (IIS) is the important one. So we should at least select this one. In regards to SMTP, it’s not required to use a trusted certificate for this service.
Click “Next”.
Figure 15: Assigning Services to Certificate
On the “Import Exchange Certificate” page, click “Import”.
Figure 16: Import Exchange certificate
On the “Assign Services” page, click “Assign”.
Figure 17: Assign Services
The certificate has now been assigned to the relevant services on three of the Exchange 2010 servers, but we still haven’t assigned it to anything on the Exchange server on which we generate and completed the certificate request. So now you need to right-click on this specific server and select assign services. In the wizard assign it to the same services as you did on the other three.
The certificate has now been installed properly. Some of you may be wondering how we can use the same certificate for both datacenters particularly in regards to Outlook Anywhere. We will touch this topic in the next part of this articles series.
Configuring the Load Balancers
It’s time to configure the load balancers. In this specific scenario, we have a load balancer pair (KEMP LoadMaster devices that I wrote about in the past) in each datacenter. Each pair is configured as an active/passive cluster. So in case the active node is down for planned or unplanned reasons the active node will take over automatically.
A total of four virtual services has been configured on each load LB:
- TCP Endpoint Mapper (TCP/135) This is the RPC endpoint mapper service which is requred in order for RPC based Exchange clients (Outlook MAPI) to find the right port number to connect to.
- Exchange HTTPS (TCP/443) This is a consolidated virtual service used for all Exchange 2010 clients and services communicating with the Exchange 2010 Client Access servers over SSL (TCP/443). That is Outlook Web App (OWA), Exchange Control Panel (ECP), Outlook Anywhere (OA), Offline Address Book (OAB), Exchange ActiveSync (EAS), Exchange Web Services (EWS) and the Autodiscover service. When using layer 7, it’s a good idea to use a consolidated virtual service since you otherwise needs to use different FQDNs for the miscellaneous clients and services that communicate with Exchange 2010 CAS over SSL.
- RPC Client Access Service (TCP/60000) This is the virtual service associated with the RPC Client access service that Outlook MAPI clients connect to in Exchange 2010. It’s best practice to use static RPC ports when the Exchange 2010 solution includes a load balancer solution. In this setup, the static port used for the RPC CA service is port “60000”. Microsoft recommends you use a unique port between 59531 and 60554.
- Exchange Address Book (TCP/60001) This is the virtual service associated with the Exchange Address Book service which is used by Outlook MAPI clients for directory access. As mentioned it’s best practice to use static RPC ports when the Exchange 2010 solution includes a load balancer solution. In this setup, the static port used for the Address Book service is port “60001”. Microsoft recommends you use a unique port between 59531 and 60554.
In the following two figures you can see the virtual services configured on each LB pair:
Figure 18: Virtual Services on Load Balancer in Primary Datacenter
Figure 19: Virtual Services on Load Balancer in Failover Datacenter
Going into the configuration details for each virtual service is outside the scope of this article. Instead refer to my previous article series on this topic, but it’s important to note that a different VIP address is used on each LB pair.
Configuring Static RPC Ports
Often there are firewall restrictions in place between the Outlook client network and the Exchange 2010 messaging infrastructure network, which requires that static RPC ports are set on each Client Access Server in a Client Access array. In addition using static RPC ports can reduce the memory footprint on the load balancer devices.
By default Windows Server 2008 and 2008 R2 are configured with a dynamic RPC range of 49152-65535 for outbound connections. Earlier versions of Windows Server by default used port 1025-65535 (for more details about this change see Microsoft KB article. Also, when the Exchange 2010 Client Access server role is installed on Windows Server 2008 or 2008 R2, the dynamic RPC port range is changed to 6005-59530 and the highest usable port number is set to 60554.
Exchange 2010 RPC Client Access Service
By default the RPC Client Access service on an Exchange 2010 Client Access server uses the TCP End Point Mapper port (TCP/135) and the dynamic RPC port range (6005-59530) for outgoing connections, every time an Outlook clients establish a connection to Exchange.
To set a static port for the RPC Client Access service on an Exchange 2010 Client Access server, you need to open the registry on the respective server and navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC
Here, you need to create a new key named ParametersSystem, and under this key create a REG_DWORD named TCP/IP Port. The Value for the DWORD should be the port number you want to use.
Figure 20: Configuring static ports for the RPC Client Access service
Note:
Microsoft recommends you set this to a unique value between 59531 and 60554 and use the same value on all CAS in any one AD site.
When you’ve configured the port, it’s required to restart the Microsoft Exchange RPC Client Access service in order for the changes to be applied.
Exchange 2010 Address Book Service
By default the Exchange Address Book service on an Exchange 2010 Client Access server uses the TCP End Point Mapper (TCP/135) and the dynamic RPC port range (6005-59530) for outgoing connections, every time an Outlook client establish a connection to Exchange.
With Exchange 2010 SP1, you no longer use the “Microsoft.exchange.addressbook.service.exe.config” file to assign a static RPC port to the Exchange Address Book Service. Instead this configuration setting is controlled using the registry. To set a static RPC port for the Exchange Address Book Service, create a new REG_SZ registry key named “RpcTcpPort” under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters
Figure 21: Configuring static port for the Exchange Address Book Service in Exchange 2010 SP1
Important:
When upgrading from Exchange 2010 RTM to SP1, you need to set this key manually after the upgrade.
Note:
Microsoft recommends setting this to a unique value between 59531 and 60554 and using the same value on all Exchange 2010 Client Access servers in any one AD site.
When you’ve configured the port, it’s required to restart the Microsoft Exchange Address Book service in order for the changes to be applied.
Exchange 2010 Public Folder connections
Since we’re using Exchange 2010 multi-role servers in this setup, we do not need to configure a static port for public folder connections. However if we had dedicated Client Access and Mailbox servers, we would need to use the same steps as those used for setting a static port for the RPC CA service above.
This ends part 4 of this multi-part article. Part 5 will be published soon.
If you would like to read the other parts of this article series please go to:
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 1)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 2)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 3)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 5)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 6)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 7)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 8)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 9)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 10)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 11)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 12)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 13)
