Forum Discussion
"Drain stopping" an Exchange 2010 CAS array w/o user getting prompts.
Greetings,
My team has established an Exchange 2010 load balanced presence using the template in our F5 3600 LTM HA Pair. Everything is working as we would expect, except for the ability to remove a CAS server from the load balancing pool without causing prompts to end users in Outlook.
When we have taken a CAS node offline using the "Forced Offline" function, like we used to do in Exchange 2007 with no issue but there was no CAS array, users are prompted with reconnecting with Exchange pop-ups in Outlook. When we tried the "Disabled" function, we waited 24 hours and there were still active sessions to the "Disabled" CAS node.
Right now we can't take a CAS offline in the middle of the day without causing Outlook connectivity pop-ups, so we are stuck with doing them in the middle of the night which is not ideal.
FYI - our MAPI VIP is using the EX2010_rpc_persist_profile which has the timeout setting of 28800 to match the default 8 hour timeout Outlook and Exchange negotiate. The profile has inherited the other settings of Hash Algorithm: Default, Mask: None, Map Proxies: Enabled.
The BigIP OS version is BIG-IP 10.2.3 Build 123.0 Hotfix HF1.
Thanks for any assistance!
- mikeshimkus_111Historic F5 AccountHi Dan, with MAPI, afaik there's no way to avoid users getting auth prompts when reconnecting to a different pool member. We have logic built into the persistence profiles to persist all connections from the same client to the same node because otherwise you would see non-stop auth prompts within the Outlook client.
- Dan_Sheehan_841
Nimbostratus
Wow... thank you for the VERY quick reply and for your help.
Thank you for clarifying that the MAPI sessions have to stay with the current node until it ends correctly, otherwise the client will get a prompt when reconnecting to a CAS member.
With persistence profile timeout setting of 8 hours, shouldn't all connections to the CAS member be removed 8 hours after putting the node into a Disabled state? We would be fine with an 8 hour delay, but even 24 hours after disabling a node we still saw connections to it which made no sense to us.
Or should be using the "Force Offline" versus "Disabled", and if so should the "Force Offline" cause users to get a prompt as long as we wait 8 hours after selecting it?
What is the side effect of deleting the persistence records? I.E. Will it cause any Outlook MAPI prompts?
Thanks again for your help!
- mikeshimkus_111Historic F5 AccountThe persistence profile timeout determines how long BIG-IP will persist new connections to that node. Any existing connections will not be removed until they are terminated by the client. So if you have someone who's left Outlook open, they are going to remain connected to the same node even though their persistence record has expired.
- Venezz_242243
Nimbostratus
Forcing the node offline will not kill the existing connections either, but it does prevent new connections from going to that node, persistence be damned. Again, your client left open will not disconnect. Sorry for the harsh words but this is just bullshit! If you force the node offline it WILL kill ALL existing connections. Of course an Outlook 2010/2013 is able to switch the connection to other cas servers. but first ALL connections are deleted. Every user gets the message "Outlook disconnected". As an F5 technician you should stop telling about things that are not true. TY
- Dan_Sheehan_841
Nimbostratus
FYI - I found this detail in our documentation of how we configured things differently from the default template settings:
The CAS Array F5 VIPs in each datacenter will be modified to use the RPC persistence profile timeout of 8 hours instead of the F5 default 3 minutes, and the TCP protocol idle timeout (for both WAN and LAN optimized profiles) of 1 hour instead of the F5 default 5 minutes. These changes are necessary to support proper BlackBerry operations and overall MAPI client communications to the CAS Arrays.
If I understand you correctly, neither the "Disabled" or the "Forced Offline" will cause the MAPI sessions to time out after 8 hours, and that essentially as long as the client and server keep the channel open the session will stay active (which explains why we saw sessions 24 hours after we disabled a CAS).
Subsequently there is no effective way to drainstop a CAS from the MAPI CAS Array within the defined timeout period, and that essentially we have to break the client connections to the back end either by deleting them or outright rebooting the server.
If that's all correct, then that sucks as we can't take action in the middle of the day that might cause connection prompts to users as the help desk will get calls.
I appreciate your continued advice and responses.
- perrdiddy_12035
Nimbostratus
Dan: - John_Matlock_42
Nimbostratus
It is my understanding the the CAS Array isn't going to cause issues, as one of the benefits of the CAS array is to allow a CAS to die and the RPC endpoint will move to another CAS without disrupting services.
Setting your node to disabled should allow (over time) connections to "drain". Unfortunately, if you've got long timeouts on your peristance profile it's possible that extremely active/chatty clients may stay connected "forever". The whole point of persistence profiles it to keep connections from drifting between nodes, so it's kind of a catch 22. Our policy is to not perform CAS maintenances during the day, but we're a 24/7 shop so that's a little more realistic for us.
John
- Dan_Sheehan_841
Nimbostratus
@perrdiddy - I have not been able to find a succesful way to "drainstop" our CASs so that we can perform maintenance on them without users noticing. I have all but given up hope.
- John_Matlock_42
Nimbostratus
Agreed, this is one of the reasons they made the architectural changes they did in Exchange 2013-- sessionless/stateless CASs solve a lot of issues. They've also substantially decreased the impact of moving databases between DAG members.
- Dan_Sheehan_841
Nimbostratus
Thanks John, that's probably the best answer I have received todate on why the persistence is never clearing and why we can't "drain stop" the CASs efectively.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com