H,

We are using EWS to read exchange mail box. The application was working fine until yesterday. From yesterday onward we started getting The request failed with HTTP status 401: Unauthorized message when reading mails from exchange mail box. We have not made changes to server setting. We can login via owa for the same user without any problem. When using EWS we get this unauthorized message.

Any help would be appreciated.

Thanks

Probably the best place to start is try using the EWSeditor https://ewseditor.codeplex.com/ to access a Mailbox and see if that works okay. You can also try checking the EWS Log on the CAS Server, if its just one user check the EWS setting for that user via Get-CasMailbox UserName@domain.com

Cheers
Glen

Thank you for the reply. I have tried with ewseditor i am getting the same error. I have checked the ews logs and there is not a much information other than the 401 status code. ews is enabled for the organisation. I have checked Get-CasMailbox UserName@domain.com and found that ews is enabled for the user.

There should be a subcode after the 401 in the IIS log file. Since there are several types of 401, this might help to better identify the cause. But if you're sure that nothing has changed, then I'm not sure that what you'll find there will be any help.

Another thing indicated by the logged line is whether the credentials are correct.  If a username appears in the logged line, then it means that the credentials are correct, but the user is refused access for some other reason (ACL restrictions or IP address restrictions).  If a dash appears instead of the username, then the credentials were not accepted at all.

One oddity is that if FBA is enabled, then a username is logged even if the password is incorrect, but you are very unlikely to have FBA enabled on your EWS vdir.

Thank you for the reply. I analyzed the iis log files and it seems to be that subcode is 0. 

I can see that the the username is logged in log file with the status code 401.

Now I wish I'd never asked :-) There is officially no subcode 0

https://support.microsoft.com/en-us/kb/943891

but I've heard of Exchange producing it many times. Each time, it has been the result of the 401 being returned from a proxied request to some other server (it used to happen often in old front-end/back-end setups), and the subcode from the other server being lost in the process, and not returned to the originating requester. Which Exchange version do you have?

We are using Exchange server 2013, 15.0.1076.9

Okay, well I sort of expected that. E2007 and E2010 didn't do that sort of proxying anymore (I think) and let the CAS server do all the work by itself. I don't know much about how E2013 does it, but it seems to have gone back to something like the old way. I'd have a look in the log files of other sites on the server (like the Exchange back end site) and see if you can also see coincidental 401's in there.

It might also mean that the authentication mechanism has broken, but that normally affects the entire site, not just a single application. But if all else fails, removing and recreating a vdir (in this case the EWS vdir), often fixes problems for which no explicable cause can be found.

Thanks for the reply. I have checked backend site log files and found 401 status code when accessing exchange.asmx...whenever exchange.asmx is accessed it shows the status code 401 in backend site logs...

dont understand what is causing the issue.

I have asked our sysadmin to reset the ews virtual directory. Will post later whether it fixes the issue or not.

What is the subcode in the backend site?  Is a username logged, or just a dash - ?

Sub Code is 1 Logon failed. User name is just blank

Are the logged events simultaneous?  We need to be sure that the root cause of the 401 from the default web site is definitely caused by a failed proxy into the backend site.

I say that because we could now end up wasting a lot of your time if we head in the wrong direction :-) and also, I'm not exactly sure how to find out why the credentials don't make it from the default site to the backend site.

Did you manage to recreate the EWS vdir on the default site?  It may also be necessary to recreate the one in the backend site, but this (link below) suggests that it's different for the backend.  It's not something I've done or even heard much about other people having to do.

http://blogs.technet.com/b/get-exchangehelp/archive/2013/02/07/managing-exchange-2013-iis-virtual-directories-amp-web-applications.aspx

It started working again. We have not done any changes. The only thing i tried is enable basic authentication in default site and back end site and disabled again. After that it started working again. 

Unable to identify which was causing the issue

Thank You

That probably woke it up, or something. Anyway, I'm glad it works now.