Getting a 401 with EWS? Read this before opening a support case!

  • Article

If your getting a 401 with an API going against Exchange or basically anything then the issue is most likely with your credentials and NOT your code. Instead of jumping to the step of opening a support case do the following:

  1. Recheck your login information. Check the user id used, password and domain information. Logins are normally done with the user's UPN and NOT their SMTP address. The SMTP address and UPN usually are the same textually, however they are very different entities and can be different. If you use a UPN then don't use an Domain – only the UPN and password are needed. You can use the UPN or Domain\User along with the password for BASIC authentication. With NTLM the User, Password and Domain are supplied along with the password. With Exchange 365 the normal method is to use the UPN and password. Be sure to double check every character for accuracy – sometimes customers have opened cases because they were typing a "1" instead of an l" in a password… I'm not joking here, I see stuff like that at least once a year.
  2. User the Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/). This is Microsoft's official connectivity tester and it provides a lot of connectivity tests. If you cannot connect with this tool then the issue is not with your code and rather you have issues with your credentials, a config issue or something messing with traffic. This tool provides a downloadable version which can be run from the desktop and can be used when your connection endpoints are not exposed to the web. Getting the credentials to work with Microsoft Remote Connectivity Analyzer should be done before looking at resolving the issue with your code instead – you could open a product support case for this if you need help.
  3. Try using the credentials with OWA. If you cannot log into OWA then the issue is not with your code and you most likely have an issue with the credentials being used or a config issue. Getting the credentials to work with OWA should be done before looking at resolving the issue with your code instead – you could open a product support case for this if you need help.
  4. If Microsoft Remote Connectivity Analyzer and OWA do not reproduce the issue, then see if the EWSEditor sample does repro. EWSEditor is not an Microsoft tool – it is a very large open source sample which demonstrates EWS calls. If it works, then check its logs and code to see how it works and compare it to your code.

Doing these tests will help eliminate your code as being the culprit of a 401. All the above tests should be tried day 1 and before you open a support case – this will save your company money and time. Also, it will help with getting a new case routed to the correct team at Microsoft. Microsoft has many support teams. If you reproduce the issue with Microsoft Remote Connectivity Analyzer or OWA then the case would go to an Exchange connectivity team as a "product support" issue. If the issue only reproduces with your code, then our team which provides developers support for EWS (and other Exchange and Outlook APIs) can assist as a "developer support" issue.

Here is a blog post where I log veracious access issues and work-arounds:

Best Practices – EWS Authentication and Access Issues
https://blogs.msdn.microsoft.com/webdav_101/2015/05/11/best-practices-ews-authentication-and-access-issues/