If you’re attempting to try out the OWA for iPhone and iPad apps, then there is likely to come a point that you’ll need to perform a little troubleshooting. In this article, I’m going to show you how get hold of, and make use of, the logs that are stored on the iDevice itself.

First of all, let’s have a look at our hypothetical situation. We’ve got a Hybrid organization, with AD FS being used to provide login to OWA. At first glance all appears fine. I can access Outlook Web App from a local machine without issue, and know my password is correct:

So with everything looking good, I attempt to install and login to the OWA for iPhone app:

However all is not well in the world. Upon entering the correct username and password, I get an error, indicating my username and password might be wrong – or even worse, I might not have an Office 365 account! As we can see when logging into OWA via a web browser, I do know my password and I’m using Office 365.

If we choose try again or advanced, we won’t get any more useful troubleshooting information. It’s time to get the diagnostic logs of the device and see where it’s failing.

To get the logs, plug in the iDevice into your computer and launch iTunes. Within the iDevice section, find the Apps tab and scroll down until you OWA in the list. Select OWA, and you’ll then see the mowa.log file:

Select the mowa.log file and download it. You can now open this in your favourite text editor (top tip – it’s not formatted with DOS line breaks, so you’ll need to open in Wordpad first rather than Notepad). As you can see below, we get a rather detailed log file showing the actions performed under the app’s hood:

Because we’re interested in where it failed, we’ll look towards the bottom of the file. Reading through the file we see that it failed during the final stage of AutoDiscover, when it contacts https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml. This is the stage where it’s attempting to authenticate against AD FS, after successfully using on-premises AutoDiscover to redirect to the cloud:

The error might not be particularly intuitive, but it’s enough to give us a starting point. We can then use the Remote Connectivity Analyser to perform an AutoDiscover test. The Exchange ActiveSync test will do fine. As we expected, it’s failed:

We’ll expand and confirm that when attempting to authenticate against an AD FS-backed endpoint it’s seeing incorrect username and password:

We do know that when I logged in against AD FS on the LAN, it worked, so what could be wrong? When I jump over to the TMG sever that’s publishing it, I see that someone (me!) has disabled the AD FS rule. Doh!

After re-enabling the rule, funnily enough it works:

Although the error I’ve shown was a little forced – it represents the kind of problems you might encounter and most importantly where to find the information you’ll need to troubleshoot the underlying issue; and as always we see that the Remote Connectivity Analyser really is useful when it comes to diagnosing issues!