Another simple ‘hack’ that can prove useful in some situations. But first of all, refresher on how to check autodiscover information (or in other words, I need a nice article with screenshot instructions which I can link when needed).
To get the Autodiscover info from Outlook, press and hold the CTRL key and right-click on Outlook’s icon in the tray, then select ‘Test E-mail Autoconfiguration’. This will open the wizard with the same name. In the ‘E-mail address’ field, enter your primary smtp address or preferably, the UserPrincipalName (if they don’t match). Enter your password, clear the ‘Use Guessmart’ and ‘Secure Guessmart Authentication’ checkboxes, then press the Test button. It will take few seconds for the process to complete and you can monitor the progress on the Log tab. If you are prompted for credentials, the authentication attempt was not successful, so double-check the password. It might also indicate other issues, but we will discuss this later. For now, let’s focus on how a successful attempt looks like. As you can see on the picture below, it will actually show you all the info required to connect to your mailbox. This info is frequently queried by Outlook and is stored as XML file in your profile directory. You can get the content of the XML file from the XML tab.
Now, in some cases, you will need to make sure that Autodiscover is working as expected from external location as well. The easiest way to test this is the Microsoft Remote Connectivity Analyzer, or http://aka.ms/rca. The ExRCA is a very useful tool, but in this case we are only interested in one of its functions. To make sure your Autodiscover works as expected, open the ExRCA, navigate to the Office 365 tab and select the ‘Outlook Autodiscover’ test under ‘Microsoft Office Outlook Connectivity Tests’. The information you will need to provide in order to run the test is similar to that in Outlook. You have some additional fields however: ‘Microsoft Account’ corresponds to the UserPrincipalName; ‘Ignore trust for SSL’ allows you to skip some steps of the certificate verifications and can usually be selected; the last checkbox is used to provide your consent. This is a web based tool after all and Microsoft wants to make sure that you understand the risk involved in entering your credentials on a public website. Lastly, you will also have to fill a captcha.
Running the test will provide you with a lot of useful troubleshooting information, and the results are very detailed on each step of the process. There is a reason we ask you to use the tool!
Anyway, now back to the topic on hand. Once you are familiar with obtaining the autodiscover info for your account, you might start wondering if there is a way to do the same with another user’s account. Well, there is of course, but you have to know his username and password! Or do you? All you need is actually Full Access to the mailbox. Yes, not an ideal scenario. It’s great for shared/resource/team mailboxes, but what about another user mailbox? Well, if you are the administrator and your company policy allows it, you can easily grant yourself the permissions and perform any tests necessary without having to disturb the user, or force change his password. More importantly, you can use this ‘hack’ to obtain the autodiscover info in scenarios where it would have been impossible otherwise.
So how exactly it is done? Well the ExRCA screenshot above might have given you a hint already. You have the field for the email address and another one for the username. But if you have Full Access to that mailbox, your username and password can also be used to identify in front of the Exchange server. Thus, you can fill in the same form, but simply change the email address, run the test and verify that Autodiscover is configured correctly, or troubleshoot any issues with it. What about doing the same from Outlook? Well, there isn’t a username field there, but you can make it ask you for the credentials. Enter the email address of the mailbox you want to obtain the info for, and enter any password. It will try to connect to the Exchange server, and unless you are extremely lucky, the authentication will fail. But Outlook is stubborn enough, and will want to try again. You will be presented with a login prompt, and this is where the magic happens. Remove the email address listed there and use your own username and password. You might be prompted again, in case of additional redirects – repeat the process (remove the email address of the target mailbox and use your own credentials). If all goes well, you will be presented with the autodiscover info and you will be able to verify the settings for that mailbox.
So, where do things get really useful? If you have implemented AD FS and are using claims rules to limit Exchange connectivity to specific IP ranges only, you might have blocked Autodiscover as well. So if you want to perform the test from remote location or from the ExRCA (which of course is a remote location as well), you will always end up with the nasty result: ‘An HTTP 401 Unauthorized response was received from the remote Unknown server’. The issue is so common, there is even a Microsoft KB article about it: http://support2.microsoft.com/kb/2466333. Well, apart from the workarounds suggested in that article, you can simply use the ‘on behalf of’ trick explained here. Grant Full Access permissions to a non-federated mailbox (surely your Office 365 tenant has at least one non-federated Global Admin account?) and run the test. Works perfectly with the ExRCA! Outlook however is stubborn again (or just plain dumb) and even though it will prompt you for credentials once, it will fail if second redirect occurs. To work around this, simply do not enter any password on the initial screen, only the email address. Silly Outlook!
Lastly, if you have been patient enough to read the whole post, here’s a small bonus: If you want to check the Autodiscover info for a shared mailbox, you can simply use the username and password for that mailbox. You don’t know the password you say? The following cmdlet will take care of that:
Set-MsolUserPassword -UserPrincipalName shared@domain.com -NewPassword Password -ForceChangePassword $false