This article will illustrate configuration of both a one-arm and two-arm topology for load balancing Exchange 2010 SP1 using a single NetScaler VPX (NS9.3: Build 52.3.nc). The specific focus is on a one-arm topology, however I’ll clearly outline what’s required if you decide to use a two-arm configuration; either way by the end of the article you’ll have a working deployment… I hope!
This guide assumes you have deployed the NetScaler VPX and configured an IP address – for information on how to do this see the NetScaler Deployment Article.
Contents
1. One-Arm or Two-Arm Topology?
5. Confirmation of USNIP Setting
6. Create, Export and Import the Exchange Certificate
6.1 Creating and Exporting the Certificate
6.2 Importing the Certificate to the NetScaler
6.3 Installing the Certificate
7.1 Configure IIS Virtual Directories
11. Configure the HTTP to HTTPS Redirect
12.2 Define and Assign the CAS Array in Exchange 2010
14. Configuring High Availability
1. One-Arm or Two-Arm Topology?
- A one-arm topology is the most simple design and is suitable for most environments where IP routing (Layer 3) switches or routers link client and server subnets.
- A two-arm topology can be used to obscure servers by sitting them ‘behind’ the NetScaler devices, form a security perspective all client traffic must pass through the NetScaler in order to reach the server. Arguably this may or may not improve security.
A one-arm topology is probably easiest to implement as you dont need to re-cable or redefine any networks in order to create the second network required by the NetScaler for a two-arm deployment. It is definately the quickest way to get a NetScaler into a production Network with minimal changes. That said, your environment may demand a two-arm topology, for example if you want to use VMACs this requires Promiscuous mode to be enabled on the vSwitch, this is not idela on a large-scale subnet that all servers share, so it’s better to define a seperate subnet for VMACs/Virtual Servers to use.
There is no need for either topology to use a public network address space on any interfaces, NAT is a perfectly reasonable alternative to what is depicted in any of the design scenarios in the Citrix eDocs.
For load balancing most Exchange 2010 environments that consist of CAS/HT and Mailbox servers either topology will work.
2. Environment Specifics
You’ll need to know the IP addresses of your CAS and HT servers for the configuration. In the environment for this guide I’m using multi-role CAS and HT servers witht he following IP addresses:
- Exch1.domlocal.net – 192.168.0.191/24
- Exch2.domlocal.net – 192.168.0.192/24
I have deployed a single NetScaler device, NS1 which is configured with IP address 192.168.0.230/24.
You’ll also need a couple of IP addresses for the Load Balanced services (clients will connect to these addresses). For the purposes of this guide I’m using:
- 192.168.0.240 – SSL and EAS
- 192.168.0.241 – RPC
- 192.168.0.245 – SMTP
Using multiple IP addresses also facilitates interesting Active/Active configurations using VMACS which I’ll cover in a later guide.
All servers and clients are a member of the domlocal.net domain, using IP’s from my chosen address space – you environment will be different so adapt scripts, commands, IP Addresses and names accordingly.
2.1 Two-Arm Differences
So here are the first differences if you decide to go with a two-arm configuration; first create an assign VLAN’s to all Network Interfaces. By default VLAN1 will be untagged on Interfaces 0/1 and LO/1 – don’t worry too much about the VLAN ID here, it can match you environment, it can also be random as it is ‘untagged’ any traffic entering the Interface or leaving it will not actually be tagged with the VLANID you select.
You need to deciede upon an address space, for the purposes of this article I’ll use 192.168.209.0/24. Importantly this is a routable subnet, both clients and servers can access this address space, unrestricted.
Browse to Network > VLANs and then select ‘Add…’ at the bottom of the window:
- Enter a new VLAN ID, in this example ‘2’
- Select the Interface that you wish to bind the VLAN to, in this example 1/1
3. Enable Basic Features
Our Exchange 2010 Load Balancing configuration will require several core features that the NetScaler supports; Load Balancing (!), Rewrite, Compression, SSL Offloading and Content Switching.
Browse to System > Settings > Enable Basic Features
Enable the required features and select ‘OK.’
4. Enable Advanced Features
We’ll be leveraging the Responder feature so we must enable this.
Browse to System > Settings > Configure Advanced Features
Ensure that the Responder feature is enabled.
5. Confirmation of USNIP Setting
This configuration requires that the “Use Subnet IP” mode is enabled. Browse to Settings > Configure Modes to verify this:
6. Export Exchange Certificate
As we’re using the SSL Offloading feature we need to import the SSL certificates that we would have used on the Exchange Client Access Servers. It may even be necessary to generate a valid certifiate.
6.1 Creating the Certificate and Exporting
Use the following code to generate an Exchange SSL certificate with the following Subject Alternate Names (SANs) – your SANs will vary:
- casarray.domlocal.net
- mail.cb-net.co.uk
- autodiscover.cb-net.co.uk
- exch1.domlocal.net
- exch2.domlocal.net
- exch1
- exch2
New-ExchangeCertificate -FriendlyName 'CAS Array' -GenerateRequest -PrivateKeyExportable $true -KeySize '2048' -SubjectName 'C=GB,S="Cambridgeshire",L="Cambridge",O="CB-Net",OU="IT",CN=casarray.domlocal.net' -DomainName 'exch1.domlocal.net','exch2.domlocal.net','casarray','casarray.domlocal.net','exch1','exch2','mail.cb-net.co.uk','domlocal.net','autodiscover.cb-net' -Server 'EXCH1'
You’ll need to either complete this request using a local Active Directory Certificate Services CA, or a third-party CA, when you have completed the request on all Exchange Servers you intend to Load Balance export the Certificate, with Private Key in PFX format ready to import to the NetSCaler device.
To complete the request open up the Exchange Management Console, browse to Server Configuration and select the server you generated the Certificate Request on. Right-click the Certificate Request that is Pending and select “Complete Pending Request…”
Enter a path to the completed certificate request (either provided by the third party or downloaded form your AD CS CA):
Completed the request by clicking ‘Complete’
Use the following Exchange Shell command to identify the thumbrint of the Certificate you wish to export
get-exchangecertificate | ft
Now export the certificate using the following commands, when prompted for credentials enter a random username (this is not used) – the password is important though!:
$cert = Export-ExchangeCertificate -Thumbprint <from previous output> –BinaryEncoded:$true -Password (Get-Credential).Password Set-Content -Path "C:ExportCert.pfx" -Value $cert.FileData -Encoding Byte
6.2 Importing the Certificate to the NetScalers
Browse to SSL and select “Import PKCS#12”
Enter a name for the certificate “Exc2010-CASArray_Cert,” browse for the PFX file (if you used the commands earlier this will be C:ExportCert.pfx) and enter the password you used when exporting it.
6.3 Install the SSL Certificate
The last step for preparing the SSL certificate for use is to Install it. Browse to SSL > Certificates and select ‘Install…’ at the bottom of the window.
- Enter a Certificate Name of Exc2010-CASArray
- Browse for the Certificate File Name
- Browse for the Certificate Private Key File Name
- Enter the password you used when you exported the Certificate form the Exchange Servers
- Enable the Notify Period, enter 14 (for 2 weeks notification)
- Click Install
7. Configure Exchange Servers
There are a few jobs that must be completed in order to successfully offload SSL.
7.1 Configure IIS Virtual Directories
When you deploy Exchange 2010 connections to Exchange related IIS content all require SSL. As we are offloading the SSL we must allow the NetScalers to connect using HTTP. The following commands, obtained from here automate this configuration:
Import-Module webadministration Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/OWA" Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/ECP" Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/OAB" Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/EWS" Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/Microsoft-Server-ActiveSync" Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/Autodiscover" iisreset /noforce
7.2 Configure RPC Ports
Run the following PowerShell commands on all CAS servers you intend to load balance using the NetScaler. This will set the RPC port to 59600 and the RPC Addressbook port to 59601:
New-Item -Path "HKLM:SYSTEMCurrentControlSetservicesMSExchangeABParameters" New-ItemProperty "HKLM:SYSTEMCurrentControlSetservicesMSExchangeABParameters" -Name "RpcTcpPort" -Value 59601 -PropertyType "String" New-Item -Path "HKLM:SYSTEMCurrentControlSetservicesMSExchangeRPCParametersSystem" New-ItemProperty "HKLM:SYSTEMCurrentControlSetservicesMSExchangeRPCParametersSystem" -Name "TCP/IP Port" -Value 59600 -PropertyType "DWord"
Restart the Exchange Server when complete, then run the following commands to ensure the server is listening on the correct ports:
- netstat -an | find “59600”
- netstat -an | find “59601”
8. Configure Service Monitors
Monitors are what the NetScaler uses to confirm services on remote servers are actually up – you wouldn’t want the NetScaler to try and use an Exchange Server that has crashed, so Monitors are used to verify remote service functionality; we need 4 Monitors for our Load Balanced Exchange 2010 environment.
Browse to Load Balancing > Monitors then click ‘Add…’ at the bottom of the window.
8.1 RPC EP-MAP
The first Monitor will be called ‘Exc2010-RPC-EPMAP‘ – this is used to verify TCP port 135 connectivity on the Exchange 2010 CAS’. This port is used to negotiate the RPC port that the client will connect with.
- Select a Type of TCP
- Enter a Destination port of 135
8.2 RPC
The next Monitor will be called “Exc2010-RPC“, this will be used to verify TCP port 59600 connectivity on the Exchange 2010 CAS’; this port is used for Outlook RPC connections:
- Select a Type of TCP
- Enter a Destination port of 59600
Address Book
The next Monitor will be “Exc2010-RPC-AddressBook” – this will monitor TCP port 59601 which is the client RPC connection to the Address Book service.
- Select a Type of TCP
- Enter a Destination port of 59601
8.3 SMTP
The final Monitor will be called “Exc2010-SMTP” – unsurprisingly this will monitor TCP port 25 on the Hub Transport servers.
- Select a Type of SMTP
Then select the ‘Special Parameters’ tab;
- Browse for the nssmtp.pl script
- Enter 127.0.0.1 as the Dispatcher IP
- Enter 3013 and the Dispatcher Port
For SSL/HTTPS service verification there are built-in NetScaler Monitors we can use rather than defining new ones.
9. Define Service Groups
Service Groups represent the Exchange 2010 features we want to Load Balance using the NetScalers. You could define individual Services rather than Service Groups, however you would have to create an individual Service per Exchange 2010 server, rather than a single Service Group that contains multiple servers. The choice is yours, but the latter seems more logical to me 🙂
Browse to Load Balancing > Service Groups.
9.1 SSL
Our first Service Group will be “Exc2010-SSL” – this will represent all HTTP (not that Client connections to the NetSCaler will be HTTPS, those from the NetScaler to the Exchange Servers they will be HTTP – this is HTTPS offloading.)
- Select a Protocol of HTTP and add “IP Based” members, one for each Exchange 2010 CAS using port 80 (not 443!)
Select the Monitors tab and ad the http-ecv monitor:
Under the Advanced tab enable the “Settings” Override Global and select the ‘Compression‘ override:
9.2 RPC
The second Service Group is named Exc2010-RPC. This is service will listen on all TCP ports due to the very nature of RPC. Select a protocol of TCP and then, as per the previous server group, add your IP Based members, with a port of *
Select the Monitors tab and add the three RPC monitors we created earlier, Exc2010-RPC, Exc2010-RPC-EPMAP and Exc2010-RPC-AddressBook:
SMTP
Our final service group is Exc2010-SMTP. Protocol is TCP, add IP Based Members with a Port of 25:
Add the Exc2010-SMTP Monitor we created earlier:
10. Define Virtual Servers
We now have all of the foundations in place for our Exchange 2010 Load Balancing, it’s now time to create the Virtual Servers to which clients will connect to.
If you are using a two-arm topology ensure you read the notes at the end of this section…
Browse to Load Balancing > Virtual Servers.
10.1 SSL
Click ‘Add…’ at the bottom to create the first Virtual Server “Exc2010-SSL”
- Protocol is SSL
- Port is 443
- IP Address is 192.168.0.240 (this is a new IP Address, as defined in the first section of this article)
Under Service Groups tick the Exc2010-RPC Service Group we created earlier:
We need to create a rewrite for clients that try to connect directly to this IP address or the root directory of this IP address (i.e. http://192.168.0.240 instead of http://192.168.0.240/owa) in order to direct the to the OWA Virtual Directory. To do this:
- Select the “Policies” then Rewrite (Request), then click Insert Policy near the bottom of this window.
- Select New Policy, give the policy a name of “Exc2010-OWA-Rewrite“
- Next to ‘Action’ click ‘New’ to define a new Rewrite Action
- Name the Rewrite Action “Exc2010-OWA“
- Select a Type of ‘REPLACE’
- Under ‘Expression to choose target text reference’ enter; HTTP.REQ.URL
- Under ‘String expression replacement text’ enter (including quote marks); “/owa” then click ‘Create’
Finally, under the Rewrite Policy Expression enter; HTTP.REQ.URL.EQ(“/”) then click ‘Create’
The Policies tab, under Rewrite (Request), should now look as follows:
Now select the Method and Persistence tab;
- Under LB Method select “Least Connection”
- Under persistence select “COOKIEINSERT”
Under SSL Settings select the SSL certificate you imported earlier:
10.2 SMTP
We’ll now create the next Virtual Server, Exc2010-SMTP. Add another virtual server named “Exc2010-SMTP”
- Protocol is TCP
- Port is 25
- IP Address is 192.168.0.245 (this is another new IP Address, as defined in the first section of this article)
Under Service Groups select the Exc2010-SMTP Service Group we created earlier:
Under Method and Persistence select the Round Robin LB Method and Persistence Type of NONE:
10.3 RPC
We’ll now create the Virtual Server for RPC connections, EXC2010-RPC. Add another virtual server named “Exc2010-RPC”
- Protocol is TCP
- Port is *
- IP Address is 192.168.0.241 (this is another new IP Address, as defined in the first section of this article)
Under Service Groups select the Exc2010-RPC Service Group we created earlier:
Under Method and Persistence select the Least Connection LB Method and SOURCEIP for Persistence:
10.4 EAS
Now for the final Virtual Server, Exc2010-EAS. This is an odd configuration tat you wont find in the NetScaler Exchange 2010 documentation, however it was put together by a colleague in order to ensure that Exchange Active Sync connections receive the correct persistence type (Exchange Persistence Types)
Add another virtual server named “Exc2010-EAS”
- Protocol is SSL
- Port is 445
- IP Address is 192.168.0.240 (this is another new IP Address, as defined in the first section of this article)
You may be wondering why we’re using port 445 as Exchange CAS/HT servers don’t listen on this port for Exchange Active Sync.
This is where the NetScalers come in. We can setup a Virtual Server on any IP, on any port, then bind it to a real service on a remote server that is on a different IP address and port. We’ll configure a redirect that points any Exchange Active Sync requests to this Virtual Server which in turn applies the correct Persistence type to the client connections and then sends all requests back to the CAS IIS instances running on port 80. Still confused? … just bear with me for now!
Under Service Groups select the Exc2010-SSL Service Group:
Under Policies select Responder, then click ‘Insert Policy” > New Policy – here we’ll create the redirect that tells clients to use the EAS Virtual Server for Active Sync data. We use a responder because Responder Rewrite that a Responder should be used to redirect a client, not a rewrite.
- Name the policy “Exc2010-EAS-Responder”
- Next to Action click New
- Name the new Responder Action “Exc2010-EAS-ResponderAction”
- Type should be set to “Respond with”
- Target should be set to: http://mail.cb-net.co.uk:445/Microsoft-Server-Active-Sync
- Tick the ‘Bypass Safety Check’ option then click Close
- Under Expression enter: HTTP.REQ.URL.ENDSWITH(“/Microsoft-Server-Active-Sync”)
- Click Create to complete the responder action.
Your completed Policy should look as follows:
Under Method and Persistence select RULE and enter the following rule text: HTTP.REQ.HEADER(“Authorization”)
Under “SSL Settings” add the certificate we used in the Exc2010-SSL Virtual Server:
10.5 Two-Arm Differences
In a two-arm configuration you’ll need to ensure you use IP addresses from your second subnet for all Virtual Servers; using the subnet I selected earlier (192.168.209.0/24) I would suggst:
- SSL / EAS – 192.168.209.240
- RPC – 192.168.209.241
- SMTP – 192.168.209.245
IP Addresses are the only variation in the configuration required for a two-arm setup.
11. Configure the HTTP to HTTPS Redirect
In order to ensure that clients that attempt to browse via HTTP are automatically rediected to HTTPS I’ve used Content Switching. The method supplied in the original Citrix deployment document is ‘OK’ however it replies upon a Virtual Server that is in a down state that has a redirect setup on it. Beacuse the Virtual Server is down the redirect is actioned. To me this looks a bit crap, so I opted to use Content Switching as detailed below:
Browse to Content Switching > Virtual Servers (note we enabled Content Switching at the beginning of this article)
Click ‘Add…’ at the bottom of the Window
- Name: Exc2010-HTTP-HTTPS
- IP Address 192.168.0.240
- Under Policies select Responder
- Select ‘Insert Policy’ at the bottom of this window
- Name the Responder Policy ‘Redirect HTTPS’
- Under expression enter: true
- Next to Action click New
- Name the Responder Action ‘Redirect HTTPS’
- Enter target as: “https://”+HTTP.REQ.HOSTNAME+HTTP.REQ.URL
- Select the ‘Bypass Safety Check’ option and click Create on both the Create Action and Create Policy windows
Your new Content Switching Virtual Server is ready to redirect!
12. Final Steps
12.1 Create DNS entries
Create the following DNS entries:
- casarray.domlocal.net – 192.168.0.241 (points to the RPC Virtual Server)
- mail.cb-net.co.uk – 192.168.0.240 (points to the SSL Virtual Server, use NAT to allow external clients connect to this for OWA)
12.1.1 Two-Arm Differences
Obvisouly you used different IP addresses for your two-arm configuration, these should be reflected in your DNS entries:
- casarray.domlocal.net – 192.168.209.241 (points to the RPC Virtual Server)
- mail.cb-net.co.uk – 192.168.209.240 (points to the SSL Virtual Server, use NAT to allow external clients connect to this for OWA)
12.2 Define the CAS Array in Exchange 2010
So you are probably wondering how you users will actually use the load balancers… thats where the Exchange 2010 Client Access Array comes in. Essentially we define a CAS Array and bind it to a mailbox database, therefore all mailboxes within the mailbox database will (via Autodiscover) use the CAS Array. If you manually configure a profile you must use the Client access Array once it has been assigned to the mailbox database.
A design consideration when deploying Client Access Array’s is that there can only be one CAS Array per AD DS site.
Use the following Exchange Shell commands to create a CAS Array named UK-CASArray in Exchange 2010, with a Fully Qualified Domain Name of casarray.domlocal.net assigned to the Active Directory Site Default-First-Site-Name (change these to suit your environment!):
New-ClientAccessArray –Name “UK-CASArray” –Fqdn “casarray.domlocal.net” –Site “Default-First-Site-Name”
Assign the new CAS array to a Mailbox Database, making sure you change the FQDN and Mailbox Database name to match your environment:
Set-MailboxDatabase DAGDB01 –RpcClientAccessServer “casarray.domlocal.net”
12.3. Save you NetScaler Configuration!
Don’t get caught-out, ensure you save the NetScaler configuration!
13. Test Functionality
Create a new mailbox in the Mailbox Database to which you assigned the CAS Array.
13.1 OWA
Test OWA functionality from a machine on the domain by browsing to http://mail.cb-net.co.uk – this should redirect to HTTPS and present the OWA login page. Test you can also login as the user you just created.
13.2 Outlook Client
Configure the Outlook Client on a domain machine, using casarray.domlocal.net as the Exchange Server and the mailbox user you just created:
14. Configuring High Availability
The NetScaler Single-Arm HA details how to configure HA for a single-arm NetScaler Deployment.