Exchange 2010 CAS connection issues after server reboots

Hey jintel, by latest version of the iApp, you mean the template named f5.microsoft_exchange_2010_cas.2012_06_08, correct? Do these bad PCs have anything else in common? What happens if you disable all but one pool member from the affected pools (you'd need to delete all persistence records using the tmsh "del ltm persistence persistence-records" command to make sure connections are really going to server you choose). We've seen cases where RPC and EWS connections being persisted to different CAS can cause problems, but it shouldn't affect OWA at all...

 

 

I defintely recommend opening a case with F5 support on this.

 

Mike

Another thing to try is setting the Action on Service Down to "Reject" on the pools in question.

Mike,

 

 

Thanks for the reply. Yes, that is the iApp template we are using. These 'bad' computers I refer to are random and a 'good' computer can be a 'bad' computer after a server reboot. I'll give your suggestions a try and see how I get on.

 

 

Thanks again,

 

J.

Hi we kinda get the same issues - but were using version 10.2, when we reboot one of the CAS servers we get numerous issues with client connections... obvisouly we tried the host file config to the cassarry to point to a cas server and its fine!!!!! also we recently switched over the backend MBX servers and we have alot of users stating they where unable to connect to their mailbox??

 

 

we are using the follwoing irule:-

 

 

iRule to select pool and persistence method when all Exchange

 

Client Access services are accessed through the same BIG-IP

 

virtual server.

 

when HTTP_REQUEST {

 

switch -glob [HTTP::path] {

 

 

"/Microsoft-Server-ActiveSync*" {

 

Direct all ActiveSync clients to a common pool; use

 

HTTP cookie persistence

 

persist cookie

 

pool Exchange_2010_CAS_single_as_pool

 

HTTP::class disable

 

}

 

 

"/rpc/rpcproxy.dll" {

 

Grab all requests for Outlook Anywhere; the following

 

checks assign correct persistence methods.

 

switch -glob [HTTP::header "User-Agent"] {

 

"MSRPC" {

 

This User-Agent section matches most versions of

 

Outlook and Windows using Outlook Anywhere.

 

The OutlookSession cookie is new to Outlook 2010.

 

if { [HTTP::cookie exists "OutlookSession"] } {

 

persist uie [HTTP::header "OutlookSession"] 3600

 

}

 

else {

 

persist uie [HTTP::header "Authorization"] 3600

 

}

 

}

 

 

"*Microsoft Office*" {

 

This section matches some versions of

 

Outlook 2007 on Windows XP

 

persist uie [HTTP::header "Authorization"] 3600

 

}

 

 

default {

 

This section catches all other requests for

 

Outlook Anywhere, and sets a persistence method

 

that does not require the client to support

 

HTTP cookies

 

persist source_addr

 

}

 

}

 

 

Finally, this assigns the Outlook Anywhere pool and turns

 

off full HTTP parsing and compression. If the preceding

 

clients should be sent to separate pools, the pool statement

 

should be removed here, and a separate pool statement

 

placed in each of the preceding logic branches.

 

Other modules (APM, ASM, etc.) should be disabled here

 

as well, if active for other traffic though this virtual

 

server.

 

pool Exchange_2010_CAS_single_oa_pool

 

HTTP::disable

 

COMPRESS::disable

 

HTTP::class disable

 

}

 

 

"/xml/autodiscover.aspx" {

 

Requests for Autodiscovery information. The selected pool

 

might be unique, or might be the same as e.g. your pool

 

for OWA or ActiveSync. In this example, we use the same

 

pool that receives ActiveSync traffic.

 

persist cookie

 

pool Exchange_2010_CAS_single_ad_pool

 

HTTP::class disable

 

}

 

default {

 

This final section takes all traffic that has not

 

otherwise been accounted for and sends it to the

 

pool for Outlook Web App

 

persist cookie

 

pool Exchange_2010_CAS_single_owa_pool

 

 

If using the Web Accelerator module, uncomment the

 

following line and change the name to that of

 

your WA class.

 

HTTP::class select Exchange_2010_CAS_single_wa_http_class

 

}

 

}

 

}

 

 

But as someone had mentioned to select the reject option on the rpc and owa pools???? i kinda get that but need to test this, as it kinda make sense that if the server isnt there then f5 will rejest the connection. But when switching the mbs servers the majority of users where unable to connect up and took 10 minutes???

 

 

I have raised a call with F5 support (still havent got back to me), on relation tom this issue and when they do manage to get back to me on an answer i will kindly pass it on :-)

 

I also have this issue when migrating users to a new mailbox servers.

Huwster75, have you followed all the post-configuration guidance listed in the v10.2 deployment guide? That iRule has been updated and the version you have there will cause nothing but headaches.

 

Mike

Hi mke, so the existing irule we have needs to be changed or tweaked????? is it possible you could give me a suggested configuration? if possible or point me in the right direction? from our testing we had no issues but if the irule needs to be changed..... i d wouldnt mide if you could give me some pointers.... i am kinda new to F5 and its alot to pick up....

Huwster, the deployment guide (located here: http://www.f5.com/pdf/deployment-guides/f5-exchange-2010-dg.pdf) has several post-configuration steps that you should perform after running the v10 deployment wizard. I recommend doing that, it'll keep you out of future trouble.

 

Mike