Forum Discussion
Misty_Spillers_
Nimbostratus
NimbostratusExchange iapp for multiple Exchange servers (different customers)
I'm on version 11.2.1 and using f5.microsoft_exchange_2010_cas.2012_06_08.
I created an "APM will provided secure remote access" iapp for one of our customers and it worked for the most part ( where you define the AD server, it does not respect routing domains, but not getting into that now as I can work around it)
I decided to create another one for a completely different customer and when I did it messed up the redirection on the first customer even though I shared no configuration. I can provide a lot more details but wanted to see if this is a known issue before I do as I really need to break the production customer and trace to page.
Steps taken:
1. Create first exchange iApp (working)
2. Create second Exchange iApp (First one now does not auto-login and I am dumped at the logon page for OWA)
3. Delete second Exchange iApp (First one now gets a "page cannot be display" with clearly an incorrect redirect)
4. Create a duplicate of the first Exchange iApp (even though this is a different VS, now the first iApp is working properly)
Now I did this just to confirm the issue.
5. Delete duplicate Exchange iApp (back to "Page cannot be displayed" on the original iApp)
6. Recreate the duplicate iApp. (Original working fine and this is where I sit today)
Activesync was fine throughout all of this, seems like purely a redirection/sso issue. I have no idea if the second iApp ever worked.
Any ideas,
Thanks in advance,
Misty
- Misty,
This morning I successfully tested deploying two separate Exchange environments behind a single BIG-IP running APM. I can think of at least two features required by this solution that are only available in BIG-IP v11.3 and above, which are the AAA server pool and client-initiated forms SSO.
You will also want to use the latest version of the iApp, RC3, which we expect to release in the next day or so. Can you send me a private message on DevCentral with your email contact info? I can let you know as soon as that RC has been declared.
Mike
- hi Misty, I think this may be due to a lack of uniqueness in the iRule that chooses an SSO configuration based on request URI. Can you post the text from the iRule(s) that end in "_select_sso_irule"?
thanks
Mike 
Misty_SpillersHere is the one from the orginal:
when RULE_INIT {
set static::OWA_FORM_BASE_SSO_CFG_NAME "/vpn/wud_owa.app/exchange_forms_sso"
}
when ACCESS_ACL_ALLOWED {
set req_uri [HTTP::uri]
if { $req_uri contains "/owa/&reason=0" } {
WEBSSO::select $static::OWA_FORM_BASE_SSO_CFG_NAME
}
unset req_uri
}This is the Duplicate one (remember I can't delete this without the original one failing)
when RULE_INIT {
set static::OWA_FORM_BASE_SSO_CFG_NAME "/vpn/wud_owa_test.app/exchange_forms_sso"
}
when ACCESS_ACL_ALLOWED {
set req_uri [HTTP::uri]
if { $req_uri contains "/owa/&reason=0" } {
WEBSSO::select $static::OWA_FORM_BASE_SSO_CFG_NAME
}
unset req_uri
}Thanks in advance,
Misty
- Let's test by changing "static::OWA_FORM_BASE_SSO_CFG_NAME" to "static::OWA_FORM_BASE_SSO_CFG_NAME_TEST" in *only* the wud_owa_test.app iRule:
when RULE_INIT {
set static::OWA_FORM_BASE_SSO_CFG_NAME_TEST "/vpn/wud_owa_test.app/exchange_forms_sso"
}
when ACCESS_ACL_ALLOWED {
set req_uri [HTTP::uri]
if { $req_uri contains "/owa/&reason=0" } {
WEBSSO::select $static::OWA_FORM_BASE_SSO_CFG_NAME_TEST
}
unset req_uri
}
You will need to disable strictness from the properties page of the wud_owa_test.app iApp first, then edit the iRule.
Every time you do a new test, you should delete any existing APM sessions for the test client first by clicking on Access Policy>Manage Sessions. - Misty_SpillersMay I ask what the expected result of this test should be? To see if the original iApp keeps working? I just want to know what to look for.
Thanks,
Misty - Yes, the goal is for both iApps to work correctly. My thought is that changing the static variable name to something unique may prevent the iRule from selecting the wrong SSO configuration.
- Misty_Spillersok made that change
The original is working fine.
The duplicate SSO never worked, it dumps you at the outlook login page and making that change had no effect on that. Remember I only created the duplicate to fix the original. I have no idea why I thought that would work but it did. - Sorry, I intended that you would compare the iRules created for the 1st and 2nd customers, not the duplicate of the 1st iApp. At any rate, a good way to troubleshoot is to go to System>Logs>Configuration>Options and set the APM SSO log to debug level. Then, ssh into the BIG-IP and run a "tail -f /var/log/apm" command while the error is happening. F5 support can assist with this if necessary.
- Misty_SpillersI appreciate the help. When I had the second customer's config on there it broke the first production customer. I deleted it in desperation to try to fix the production customer (which it made the problem worst).
I don't have the resources for setting up a lab. I was just hoping someone here had run into the issue before or could look at the iApp and see why they would step on each other. Support is going to assist me tomorrow on some Firepass to APM issues and this is on the list. Hopefully they can advise me. - Misty_SpillersI just wanted to bump this. After a long time of this being open with F5 support I was essentially told that the iApp doesn't support multiple exchange servers configurations and I could try to build it myself or pro service consultants.
If it doesn't work it shouldn't let you even try to create a second iApp so you don't break your production/working environment like I did. I'm really surprised this doesn't come up more often. I can see all kinds of reasons to create a second even without multiple customers.
So if anyone ever run into this and figures out how to fix it please post. I pretty much have to leave those customers on Firepass until its fixed or we just take F5 out of the picture and put these servers in a DMZ. - Can you please send me your F5 case number?