cancel
Showing results for 
Search instead for 
Did you mean: 

iApp with 11.4.1 and Exchange 2010

Patrick_Brown_7
Nimbostratus
Nimbostratus

Hey All,

 

I'm working with my messaging team on an Exchange 2007 to 2010 migration. We have built two 2010 multi-role servers. Each server is MBX, CAS, and Transport. I have an F5 LTM up front with 11.4.1 code. Both Exchange servers are in a vlan behind the LTM and have their default gateway set to the F5 inside VLAN. I deployed the app with the latest iApp for Exch 2010 and 2013.

 

Here is the problem. End users sometimes get prompted for logon by Outlook when we reboot one of the Exchange servers. We don't thing this is normal. Shouldn't the F5 maintain connection state until the application monitor deems the node is down and then direct the user to the other node?

 

Thanks,

 

Patrick

 

8 REPLIES 8

What_Lies_Bene1
Cirrostratus
Cirrostratus
How long does a reboot take?

MVA
Nimbostratus
Nimbostratus

The default pool configuration on 11.3/2010 iApp is "reject" for "action on service down" - I'm not sure what 11.4.1/2010/2013 iApp code. This specifies how the LTM responds when a pool member goes offline. From the help:

 

"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."

 

I read this as behaving as you describe, reboot an exchange server the client will get disconnected. What we do to avoid this disconnec, when possible, is a day prior we disable the exchange nodes needing maintenance. Over time the connections close themselves and when it's maintenance time we can see the connections are near 0. Understand there are time when you don't have time for this stop-drain process. - Mel

 

Thanks Mel. I looked at my RPC pool. "Action on service down" is set to reject. --Patrick

MVA_60288
Altocumulus
Altocumulus

The default pool configuration on 11.3/2010 iApp is "reject" for "action on service down" - I'm not sure what 11.4.1/2010/2013 iApp code. This specifies how the LTM responds when a pool member goes offline. From the help:

 

"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."

 

I read this as behaving as you describe, reboot an exchange server the client will get disconnected. What we do to avoid this disconnec, when possible, is a day prior we disable the exchange nodes needing maintenance. Over time the connections close themselves and when it's maintenance time we can see the connections are near 0. Understand there are time when you don't have time for this stop-drain process. - Mel

 

Thanks Mel. I looked at my RPC pool. "Action on service down" is set to reject. --Patrick

Patrick_Brown_7
Nimbostratus
Nimbostratus
The reboot takes several minutes. These are physical Dell servers so not a quick reboot like you would get with virtual servers.

Patrick_Brown_7
Nimbostratus
Nimbostratus

We made a lot of progress on this. We ended up deploying with dedicated RPC CAS ports. This made the health monitoring much better. We also know that a service failing is very different that someone shutting down a server. We did a lot of testing on this. We would stop various Exchange services or shutdown NICs. F5 did the job perfectly. The only way users ever saw an auth prompt was if the admin shutdown the CAS server without first downing it in LTM. The Exchange team now knows and accepts this as normal. Drain-stopping the node before maintenance is now part of the standard procedure.

 

--Patrick Brown

 

That's really the only option since Exchange 2010 requires persistent connections per session (it's not really very load balancer friendly).