Exchange 2013 iApp Confguration for MobileIron

Question

I've deployed the iApp for Exchange 2013 using the defaults except for using SSL Bridging instead of SSL Offloading. All internal and external mail flows just fine, but mobile devices configured with MobileIron get an error stating 'Cannot connect to server'. Are there specific settings that are required for MobileIron to work with this iApp? The MobileIron Sentry is a stand-alone VM in the DMZ and not load balanced by F5. A manually created F5 virtual server that was deployed prior to the iApp being utilized is configured for 'Performance (Layer 4)' for the Type, but the iApp-created virtual server for combined_https is using 'Standard' for the type. If I change this to 'Performance (Layer 4)' to match the old virtual server, I get an error stating: "01070394.3: TCP::idletime in rule (/Common/Exchange-2013.app/Exchange-2013_combined_pool_irule7) requires an associated TCP profile on the virtual server (/Common/Exchange-2013.app/Exchange-2013_combined_https).

rainhail_281362 · Accepted Answer

We resolved this. We had the ActiveSync virtual directory in IIS locked down to the MobileIron servers, but needed to add the self-ip's of the F5 devices as well.&nbsp;

mikeshimkus_111 · Answer

Hi RainHail, You can't change the iApp virtual server type to Performance L4 because that VS type isn't supported for doing all the things that the iApp deployment needs to do.&nbsp;
I'm unfamiliar with how MobileIron works, so I'm just going to ask some general questions.&nbsp;
Is MobileIron sitting between mobile clients and your Exchange server? Was the previously configured Performance L4 virtual server the target for traffic sourced from MobileIron, and did it work until you switched it to point at the iApp-created virtual server?&nbsp;
Did you deploy APM or AFM with your Exchange iApp?&nbsp;

rainhail_281362 · Answer

From MobileIron: "Standalone Sentry serves as an intelligent gatekeeper to the ActiveSync server. It uses the ActiveSync protocol to communicate with the ActiveSync server and with the ActiveSync devices."&nbsp;
Essentially, a MobileIron app sits on the mobile device and is pointed to the MobileIron Sentry device. This Sentry device is in the DMZ and passes the information to the Exchange iApp using ActiveSync over 443. This configuration works fine using the manually created virtual servers, but doesn't work with the iApp. On the external F5 appliance, there is a virtual server that answers all Exchange requests. It points those to an APM 'portal' where the user gets authenticated with username and password, then uses Symantec VIP for two-factor. Once authenticated, the traffic gets passed to the internal F5 device where the Exchange iApp is deployed (along with the old Exchange VS).  The only thing that changes in this scenario is the internal VS that the traffic gets passed to.&nbsp;
Old way: Mobile Device -&gt; Ext F5 -&gt; APM for authentication -&gt; Internal F5 w/created VS&nbsp;
New way: Mobile Device -&gt; Ext F5 -&gt; APM for authentication -&gt; Internal Exchange F5 iApp&nbsp;

mikeshimkus_111 · Answer

Do you see successful authentications in APM for the clients when they are forwarded to the iApp VS?&nbsp;
Does the MobileIron Sentry have a cert installed?  It should either have the cert that matches the one used in the iApp, a self-signed cert, or none at all, according to this:  https://www.ndm.net/mobile/pdf/vol_iv_using_mobileiron_sentry.pdf&nbsp;
In the old way, if the MobileIron device had a cert with it's own CN, that should work.  But it would break if you started pointing that to a VS using the Exchange cert.&nbsp;

rainhail_281362 · Answer

We haven't gotten that far yet to look for successful authentications in APM when forwarded to the iApp VS.&nbsp;
Everything is using a wildcard certificate, except that the old VS is using 'Performance (Layer 4)' for the type, so no certificate is used. That's why I was wondering about changing the combined_https VS to 'Performance (Layer 4)' instead of 'Standard'. That was the one thing the stood out as a difference between the old VS and the iApp VS.  That being said, the wildcard cert on the Sentry, F5 and Exchange all have different thumbprints, but are all issued from the same primary wildcard certificate from Digicert.&nbsp;

mikeshimkus_111 · Answer

It's hard to do much more troubleshooting without knowing exactly where it's breaking.  We'd want to verify that the request is getting to the iApp virtual server and if it's making it through to the ActiveSync pool on the back end.  You can turn up the APM log level to debug and watch /var/log/apm to verify that you are getting an authenticated session.  You should also be able to add an iRule to the iApp VS to log the ActiveSync requests and responses from Exchange.&nbsp;
I recommend opening a case with F5 support on this.  If you want, you can send me the case number so I can track it.&nbsp;

Forum Discussion

Exchange 2013 iApp Confguration for MobileIron

6 Replies

Recent Discussions

google autenticator broken barcode

Error while running ansible

ASM instance creation

[ASM] - what is "Browser Challange file" ?

[ASM] - HTML5 Cross-Domain Request Enforcement - CLI command

Related Content

MobileIron MDM APM Integration iApp Template

Exchange 2016

Integrating APM with MobileIron MDM – Part 1

MS Exchange ProxyNotShell block implemented via iRules

Exchange 2019