Hi, its me again, got busy working on some other access stuff , didn’t get much time to share interesting scenarios with you guys in a while. Anyhow I am back and here is one scenario that came up few times and I think its probably causing some deployment concerns around having IOS or windows phone devices having ability to create multiple profiles on the device itself for same user when he wants to access his two separate mailboxes (Exchange Active Sync) via UAG.
The challenge is if user is having multiple profiles on his mobile device while synchronizing his inbox , it is possible that user might come across inbox of other profile that he is not supposed to view…!. Users might notice different behaviours , some times users see inbox of the second profile while phone is synchronizing using Exchange active sync , at times users have experienced that once synchronization is done they start getting view of the correct inbox but question is why this is happening ?.
This problem is down to the behaviour of session cookie handling by UAG. It depends on various factors as well for instance if there is a load balancer sitting in front of UAG , it could fiddle with session cookies. I have also seen issues when load balancer configured to do “connection pooling” causes funny behaviours , so better test Connection Pooling before enabling it when LB is siting in front of UAG.
Anyways in UAG SP2 release we fixed the session cookie behaviour to make each session unique. For this specific scenario explained above and with UAG SP2 installed you need to make a registry tweak as shown below , that will allow users having multiple profiles on the same mobile device (IOS or Windows phone ) synchronize to there respective mailbox without any session overlap problems for Exchange Active Sync.
The fix is as follows:
1. On the UAG server, please create a new DWORD registry value, as follows:
// This should cause UAG to not base its session management on the UAG session cookie (“NLSession…”), for ExchangeActiveSync.
2. Assign it a value of ‘1’
3. Activate the UAG configuration
Once this registry is in place on top of UAG SP2 the above scenario will work.