Forum Discussion

KDS2014's avatar
KDS2014
Icon for Nimbostratus rankNimbostratus
Oct 06, 2016

F5 Load Balancing Exchange 2013

We are loadbalencing our Exchange 2013 behind F5-LTM. We have Exchange 2013 setup in a DAG (Database Availability Group) with 5 servers. When we place a server in maintenance mode it moves all active mailbox databases on that server to any of the other 4 servers. When this happens Outlook remains connected to the mailbox database fine. However, when we shut down the server that was placed in Maintenance mode Outlook disconnects from the mailbox database and is unable to connect back to it until “the client” close Outlook and relaunch it. According to Microsoft documentation, when the mailbox database fails over to a new server the connection should be proxied over to the new server and be fine and Outlook never loose connection except for a brief second. This does not seem to be happening and it seems as if Outlook’s connection is being maintained to the server in maintenance mode and when it goes offline “the client” does not attempt to connect to any of the other servers and continues to attempt to connect to the offline server. Wondering what can i look at on my LTM ViP or other F5 profiles that could be causing this? We do not have any persistence services or profiles created for this ViP profile.

 

8 Replies

  • First make sure you are using the iApp and the latest version. See this link for more information: https://support.f5.com/kb/en-us/solutions/public/13000/400/sol13497.html

     

    If you are, better get a support case open. Exchange is a very complex application, with multiple connections. You probably need to take some tcpdumps/ssldumps, but support guys will be able to help with that.

     

  • When I first went to implement this over a year ago, I wanted to do iApp and tried iApp, but was having some inconsistent results that even F5 support couldn’t answer. So ended up doing it manually, but in my research I have just notice one thing, under my pool profile config, under “Action on Service Down” I have “None”…..do you know if this should be “Reject” or “Reselect”?

     

  • Well...in our testing environment under my Pool profile, I made two adjustments “Action on Service Down=REJECT”, and “Slow Ramp Time=300 seconds”…..I’m currently pending my exchange team to test in the test environment, as of today they haven’t tested yet. But I came to this solution from talking to F5 tech-support F5 tech-support solution: When the server is shut down, F5 Exchange pool is currently set to: 'do nothing' and that is what it does.

     

    Please change the setting for the pool to 'reject'. Per the F5 iapp deployment guide, this is the recommended setting.

     

    Pools (Main tab > Local Traffic > Pools) Health monitor Add health monitor above.

     

    Action on Service Down Reject Slow Ramp Time 300

     

    Load Balancing Method Least Connections (member) recommended

     

    Address IP Address of Client Access server running RPC Client Access

     

    Service Port * All Services (repeat Address and Port for all members)

     

    https://www.f5.com/pdf/deployment-guides/microsoft-exchange-iapp-dg.pdf

     

    ! Then my response: Interesting.........after you pointed that out in your original e-mail I would have guess "Reselect" would be the best choice, but the recommend option is "Reject"....any idea why "Reject" is a better option?

     

    ! F5 tech-support response: In this specific case, (MS exchange 2013) I cannot explain why Microsoft choose 'reject' instead of 'reselect.' The iApp guide does not explain their thinking. But this was written in concert between Bigip and MS and is the recommended practice.

     

    In general what will happen if that pool member is down, the system will send new connections to the active pool member and for existing connections that point to the down pool member the connections are reset but no RST is sent to the client can reconnect.

     

    Reject: Specifies that, if there are no pool members available, the system resets and clears the active connections from the connection table and sends a reset (RST) or Internet Control Message Protocol (ICMP) message. If there are pool members available, the system resets and clears the active connections, but sends newly arriving connections to the available pool member and does not send RST or ICMP messages.

     

    Reselect: Specifies that the system manages established client connections by moving them to an alternative pool member when monitors mark the original pool member down.

     

    Hope this helps!!!!! KDS

     

  • The slow ramp should not have any impact with the problem you described, this option is just to make sure a new server don't get overloaded when it becomes online. Imagine you have least connection, a pool with 10 servers it one has 1000 connections, another server in that pool comes online and will get all the next 1000 connections.

     

    More information about slow ramp:

     

    https://support.f5.com/kb/en-us/solutions/public/14000/800/sol14804.html

     

    https://support.f5.com/kb/en-us/solutions/public/13000/000/sol13099.html

     

    The reject action in the other hand looks to be related with the problem you described.