Since working with Exchange Web Services 2010 is a bit ridiculous, especially from anything other than .NET, I’ve been tasked with wrapping some functionality up in a SOAP web service that acts as a pass-through for other languages to interact with our Exchange environment.
[Misc] <-(SOAP)-> ASP.NET ASMX web service <-(EWS Managed API)-> Exchange2010
In order to not require the user to enter their password for every action, we’re using impersonation accounts so that all we need is the account name for the account we want to modify.
This all works pretty well. With one of the impersonation accounts. Impersonation accounts have a 1:1 relationship with api keys for auditing simplicity purposes. The other impersonation accounts we’ve setup appear to be exact copies of the working account, except for the different name and password, but when we attempt to use them from the EWS Managed API, we get this error:
Request failed. The remote server returned an error: (401) Unauthorized.
Stack Trace:
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.InternalExecute()
at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder(FolderId folderId, PropertySet propertySet)
at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder[TFolder](FolderId folderId, PropertySet propertySet)
at Microsoft.Exchange.WebServices.Data.Folder.Bind(ExchangeService service, FolderId id, PropertySet propertySet)
at Microsoft.Exchange.WebServices.Data.Folder.Bind(ExchangeService service, WellKnownFolderName name)
at WhartonEWS.GetEmailUnreadCount(String apiKey, String emlUserAddress) in c:\workspace\dotnet\EWS\v1\App_Code\EWS.cs:line 357
As I said, this same code works fine when using an API key corresponding to a certain other impersonation account; and if I set the non-working api key to use the working impersonation account then the api key starts working.
Since one account works and another doesn’t, I would take this to mean that the problem is not in my web service code, but rather in either the impersonation account setup or some sort of configuration that exists in between the web and Exchange servers. But if it were configuration between servers, I’d think that would stop all accounts from working.
At the same time, we have what I believe to be some very competent exchange admins, and at least two of them have looked at the impersonation accounts and come to the conclusion that they are not the problem.
Where can we go from here? I suppose one possible solution would be to channel all requests through the working impersonation account and deal with the auditing implications, but if we can avoid that, we’d like to. Any ideas?
As it turns out, the issue was impersonation account configuration. I don’t know how the Exchange admins figured that out, though.