Trying to implement Exchange 2010

We are trying to implement Exchange 2010 using the F5 deployment guide section "Configuring the BIG-IP LTM to support Outlook Web App, Outlook Anywhere, and Active Sync using a single virtual server". OWA works OK (except when you log in and click "options" it goes to a 404 error). We are running LTM 10.1.0. Tried using the template first and that did not work well at all so moved on to using deployment guide instead and made better progress. When testing Outlook Anywhere as well as Active Sync (using using www dot testexchangeconnectivity dot com/) site I receive the following error: "Initial Anonymous HTTP(s) request did not fail but Anonymous is not a supported Authentication Method for this scenario http://technet.microsoft.com/en-us/library/dd439395(exchg.80).aspx"

 

Has anyone seen this issue already? Any suggestions on what to change on the iRules from the deployment guide? They are pretty basic so frustrating I cannot get this to work. Anything else I should look for?

Mike,

 

I changed the default append iRule from from the deployment guide:

 

when HTTP_REQUEST {

 

if { not ([HTTP::uri] starts_with "/owa") } {

 

HTTP::uri /owa[HTTP::uri]

 

}

 

}

 

 

To

 

when HTTP_REQUEST {

 

if { [HTTP::path] equals "/" } {

 

HTTP::redirect "https://[HTTP::host]/owa"

 

}

 

}

 

and now Outlook Anywhere appears to work correctly.

Looks like that worked!

I'm sorry I meant to post a follow up. That iRule broke OWA for us so we went back to the drawing board and now trying to setup without SSL offloading.

Brendan,

 

 

Similar problems, now we have OWA working in SSL offloading mode (had to change registry on CAS server sides to get it working), but testing ActiveSync via iPhone gives us errors about unable to verify. I will be doing more testing but I am thinking the issue is on our Exchange side. The document for the setup of the single instance is what I used (didn't use the templates) and everything did work after we got the Exchange side fixed. It'a pretty simple ruleset - redirect to /owa add https, if RPC use source address afffinity, else use cookies. - (I think off top of my head)

 

 

This one should work (same as document) but remember it must go after the persistence rule:

 

 

when HTTP_REQUEST {

 

if { not ([HTTP::uri] starts_with "/owa") } {

 

HTTP::uri /owa[HTTP::uri]

 

}

 

}

 

Brendan (or anyone for that matter), did you find a solution to the 404 error when clicking on Options within OWA? I'm seeing the exact same thing.

In case anyone else comes across this, here's the problem. Clicking on the "options" link in OWA sends you to a link that does not include /owa in the uri. Instead, it directs you to /ecp/?rfr=owa. The owa append iRule in the current deployment guide does not account for this. It will append /owa and break the link.

 

 

Here's the iRule I settled on, so far so good.

 

 

when HTTP_REQUEST {

 

if { ([HTTP::uri] equals "/") } {

 

HTTP::uri /owa[HTTP::uri]

 

}

 

}

 

So I am still having the issue last posted on 07/02/2010 even when changing the iRule (even when removing the iRule). Has anybody else had luck with this?

I think I might have it working....finally

 

 

On our http virtual server I have 1 iRule to rewrite incoming url and redirect the https server, we are an exchange hosting company so I need to this.

 

 

when HTTP_REQUEST {

 

if { [HTTP::host] contains "email" ||

 

[HTTP::host] contains "outlook" ||

 

[HTTP::host] contains "webmail" ||

 

[HTTP::host] contains "mail" }

 

{

 

HTTP::redirect "https:/mycas.mydomain.com/owa"

 

}

 

else {

 

HTTP::redirect https://[HTTP::host][HTTP::uri] <-non /owa requests (http://mycas.mydomain.com/ecp)

 

}

 

}

 

 

 

Then on the https server I have the append irule noted above and nothing else

 

 

when HTTP_REQUEST {

 

if { ([HTTP::uri] equals "/") } {

 

HTTP::uri /owa[HTTP::uri]

 

}

 

}

 

 

Lastly, and I think the missing part of puzzle. Edit the http profile used for you virtual servers and change this option "Redirect Rewrite" to All (should be set to MATCH).

 

 

We found that when "Redirect Rewrite" set to "match" the requests between the client and f5 would bounce from http to https to http and so on. And cause long load times