Enabling Transparency for Exchange 2010

New post

tony.mitchell

August 08, 2014 11:54

Hi,

We currently have 2 LM-3600 appliances in our main data centre which are (amongst other things), are being used for Exchange 2010 (CAS Load Balancing, SSL Offloading and ESP for OWA, ECP, EAS etc...). We are using a one-armed configuration for Exchange, and there are no clients on the same subnet. Currently, transparency is disabled on all Exchange 2010 virtual services.

Although everything works from an Exchange point of view, we have Exinda network optimisation devices on the LAN/WAN edge of each of our sites. These devices inspect traffic at L7 and attempt to classify the traffic so that it can be optimised. However, the Exinda units have always struggled to identify Exchange 2010 traffic as MAPI, and therefore can't optimise the traffic. Although I suspect the Exinda software is largely to blame for this, Exinda support don't appear to be willing to offer a positive solution.

So, in order to achieve our goal of optimising MAPI traffic, it seems we should enable transparency for Exchange 2010. However, I have a few questions on the subject...

(1) As we're using the Exchange 2010 template from Kemp, would we only need to apply transparency on the Exchange 2010 MAPI service, or would we need to enable transparency on all services (MAPI, SMTP, HTTPS Offloaded with ESP)?

(2) With transparency enabled, the default gateway of the server needs to point to the LoadMaster. Given that we (as IT administrators) still need to maintain the server through RDP, how do others normally achieve this (separate NIC on a management VLAN is my first thought)?

(3) Since Exchange 2010 is now live, is there any way to do this without downtime?

(4) Have I forgotten anything! 

Thanks in advance for your help
Tony

Date Votes

1 comment

derkiely August 11, 2014 18:19

Hi Tony,

In the MAPI header there is a field that contains the IP address of the Exchange Server that a user is connected to. If you look at a MAP Response header in a tcpdump (can capture on the LoadMaster) you will see that there is a field called Floor 5 with an IP address of the CAS server that the user is connected to.

I suspect that this field is used by WAN Optimizers such as Exinda to create a listener so that they can optimse MAPI/RPC traffic. When using a HLB the Optimizer will not receive any traffic from the IP that they are listening on because the traffic is coming from the Virtual Service IP or the IP of the HLB hence the Optimizer will not identify the traffic.

Changing to L7 Transparency will not resolve this issue as the source IP of the traffic outbound when it reaches the optimzer will still not match the IP in the MAPI header. L7 Transparency will only change the source IP of the packet as it goes towards the server. This makes sense as you want your clients replying to the IP address of the Virtual Service on the HLB so that the traffic flows via the HLB all the time.

I would suggest that you check this information with Exinda to verify that this is what they are doing. If this is the case then the only options would be to change what Exinda is looking at (best method) or try Direct Server Return (DSR) for your MAPI Virtual Service (gotcha on this is you need to use a different IP address for L4 DSR Virtual Service which will be your CAS array).

Regards
Derek