Preface
If you have decided to integrate your Unity server with Exchange 2010 environment for unified messaging, and you have also decided to configure your Exchange 2010 server cluster to include an array of Client Access Servers (CAS) interfaced by a Network Load Balancer (NLB) appliance, then you should consider the following caveats.
Prerequisites
Make sure you have followed all of the steps outlined in the Guide:
Using Microsoft Exchange 2010 with Cisco Unity Versions 8.0, 7.0, and 5.0
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/7x/using_exch2010/usingex2010withcu7x5x.html
Use Session Persistence or Port Affinity
To communicate with the Exchange envrionment, Unity leverages Microsoft's Messaging API, MAPI. Part of that communication process involves opening a MAPI connection between the Unity server and an available Exchange CAS server. Once this communication path is established, the Exchange CAS server will use this session to field requests from the Unity server. You must configure your NLB to always relay packets from the Unity server in this session to the same CAS server until the session is terminated. This behavior is often referred to as "Session Persistence" or "Port Affinity" or "Sticky".
Verifying Configuration
If you're currently using a Unity server and Exchange 2010 server and NLB in the configuration described above already and you're experiencing problems with that communication path, verify the following.
- Check the Unity server's application event log and/or Unity diagnostic logs for instances of error code 0x80040115 or MAPI_E_NETWORK_ERROR. If this return code is being returned by the Exchange 2010 environment, you may be experiencing a problem with the NLB session persistence or port affinity.
- Use a packet sniffer to determine if MAPI from the Unity server is consistently being forwarded to the same CAS server.
What breaks the communication with MAPI is when a connection is established thru the NLB and it routes it to say CAS1, then while still using the same MAPI connection the NLB round-robins it over to another CAS server other than CAS1. Since the other CAS servers are not in the same MAPI state as CAS1 any MAPI request made from that point forward will be invalid thus causing a E-MAPI NETWORK ERROR.
