New iApp, Exchange 2010 and SSL bridging

Hello and thanks for giving the new iApp template a try.

 

 

We haven't seen this particular error before -- where exactly are you seeing it? Before ever getting to the login page, or after logging in but before getting to the Mailbox view?

 

 

Some things to check:

 

 

Did you by any chance change the URI for reaching OWA (within the context of the iApp template)? The question immediately follows the one about if you're deploying OWA; you should really leave that at the default value -- we default that to "/owa/".

 

 

Is your OWA pool actually listed as available (green) by BIG-IP LTM? If not, What type of monitors are you using -- simple or advanced?

 

 

If using Advanced monitors, what Auth method are you using for OWA -- forms-based or Basic/Integrated? If forms-based (default), did you specify that correctly in the iApp template monitor section, and also follow the requirement to change the credential format on each CAS server from 'domain\username' to just 'username'?

 

 

Lastly, did you remember to make the External URL for both Outlook Web App and Exchange Control Panel 'https:///owa' (where is your client-resolvable DNS name, of course) rather than 'https:///owa'?

 

 

Let us know about these items and, if none of those are the culprit, we can suggest some further troubleshooting steps.

Thanks for the suggestions!

 

 

Did you by any chance change the URI for reaching OWA (within the context of the iApp template)? The question immediately follows the one about if you're deploying OWA; you should really leave that at the default value -- we default that to "/owa/".

 

 

This is still on the default.

 

 

Is your OWA pool actually listed as available (green) by BIG-IP LTM? If not, What type of monitors are you using -- simple or advanced?

 

 

It is set to simple and it all shows green in the monitors.

 

 

If using Advanced monitors, what Auth method are you using for OWA -- forms-based or Basic/Integrated? If forms-based (default), did you specify that correctly in the iApp template monitor section, and also follow the requirement to change the credential format on each CAS server from 'domain\username' to just 'username'?

 

 

This was set previously.

 

 

Lastly, did you remember to make the External URL for both Outlook Web App and Exchange Control Panel 'https:///owa' (where is your client-resolvable DNS name, of course) rather than 'https:///owa'?

 

 

These kinda look the same.... ;) They are set to https://mail.whatever.com/owa.

 

 

Any other thoughts? Thanks!!!

Sorry for the confusion about the URLs -- this forum stripped the example names I had in the URLs because I had encased them in left and right angle-brackets and it thought they were HTML.

 

 

When your browser gives you the error, what's the URI in your browser location bar? Is it just https://mail.whatever.com/owa, or do you have something like https://mail.whatever.com/owa/auth/logon.aspx followed by possibly some other values?

 

 

Do you have HTTPwatch or Firebug or something similar available to you? We'd like to see what the actual error message is (for example, 401 Not Found, or whatever it happens to be) rather than the "friendly" message provided by your browser.

 

 

What about SNAT settings and routing? (which are controlled by the topology questions about where your BIG-IP and actual servers are in relationship to one another? How did you answer those?

 

 

Is your Windows firewall on the CAS servers enabled (any of the Domain, Public or Private profiles)?

 

 

Can you try an Advanced monitor instead, using a real mailbox login? This will give us some additional information based on whether that works or not.

 

 

I know we're fishing a bit, but we so far seem to be missing some piece of information that will point us towards a solution.

 

 

Thanks again!

 

 

When your browser gives you the error, what's the URI in your browser location bar? Is it just https://mail.whatever.com/owa, or do you have something like https://mail.whatever.com/owa/auth/logon.aspx followed by possibly some other values?

 

 

It's whatever I type in. It doesn't change to the OWA URI or any other URI.

 

 

Do you have HTTPwatch or Firebug or something similar available to you? We'd like to see what the actual error message is (for example, 401 Not Found, or whatever it happens to be) rather than the "friendly" message provided by your browser.

 

 

I don't, unfortunately.

 

 

What about SNAT settings and routing? (which are controlled by the topology questions about where your BIG-IP and actual servers are in relationship to one another? How did you answer those?

 

 

Primary connections are LAN based. And the CAS boxes are on the same subnet as the F5.

 

 

Is your Windows firewall on the CAS servers enabled (any of the Domain, Public or Private profiles)?

 

 

Nope. All off.

 

 

Can you try an Advanced monitor instead, using a real mailbox login? This will give us some additional information based on whether that works or not.

 

 

Green monitors across the board, minus Exchange_2010_combined_http, as it shows Unknown.

 

It sounds like, for whatever reason, the request is not getting to the server (or not returning properly), since you should receive a redirect.

 

 

I'm sending you a private message via your DevCentral Inbox in just a few minutes with some additional questions.

 

 

If whatever we discover is relevant to a larger audience (bug, configuration error, or something else that is not unique to just this one instance) we'll post the eventual solution here.

Sounds great! Thanks!!

Are you certain you have both a Client SSL profile AND a Server SSL Profile? Also try using the Default Server SSL profile since i have come across situations where securing the session with the same public/private key on both ends had broken the session. So just to make sure ... you have....

 

 

VirtuaServer on 443

 

Using a client SSL profile that includes a cert with a key pair. (Try the default Client SSL Profile for troubleshooting)

 

Using a Server SSL profile ( Try the default Server SSL profile for troubleshooting)

 

CAS Pool on 443.

 

Using AutoSnat or SnatPool if using a One Arm config.

 

 

Just a couple basic things to check off the top of my head.

 

 

Chris Dearie

 

I didn't do anything outside of what the iApp setup, to be honest with you.

 

 

And Chris, you should know more about this environment than I do. You set most of it up, from what I hear. Minus these new LTMs. ;)

The iApp takes care of the SSL profiles and SNATing.

We're having an issue sending private messages right now, but we will be in touch soon via DevCentral.

 

 

In the meantime, can you please open a support case with F5 for this so we can track it internally?

 

 

What browser(s) are you using? I can suggest a few tools that can let us look inside the traffic, but need to know what platform we have to work with.

 

 

Are you able to create a new virtual server on another IP address? We'd like to try an experiment. If you can, please do this manually, rather than using an iApp template. Create the virtual with these characteristics:

 

 

Type: Performance (Layer 4)

 

Destination: Host, with whatever new IP address you have

 

Service Port: https

 

SNAT Pool: Automap

 

Default Pool: the pool that was created by the iApp template, likely named [somename]_owa_pool

 

Default Persistence Profile: source_addr

 

 

Then use a local Hosts file entry to make your client use the new address for the FQDN you have assigned to OWA.

 

 

This setup makes BIG-IP LTM do almost nothing to the traffic other than translate the destination IP (that's inherent to any Host-based virtual server) and translate the source IP to avoid asymmetric routing situations. If you can't get to OWA this way either, it points heavily towards a network topology issue, server configuration issue, or something of that nature. If you *can* get to OWA this way, then we can look more carefully at LTM configuration or some possible Exchange changes. Either way, it will give us more information to work with.