如何缩小此 ASP.NET ASMX 到 Exchange 2010 托管 API 设置中的故障点范围？
由于使用 Exchange Web Services 2010 有点荒谬，尤其是使用 .NET 以外的任何其他语言，因此我的任务是将一些功能包装在 SOAP Web 服务中，该服务充当其他语言与我们的 Exchange 交互的传递环境。
[杂项] <-(SOAP)-> ASP.NET ASMX Web 服务 <-(EWS 托管 API)-> Exchange2010
为了不要求用户在每次操作时都输入密码，我们使用模拟帐户，这样我们所需要的只是要修改的帐户的帐户名。
这一切都运作得很好。 使用其中一个模拟帐户。为了简化审核，模拟帐户与 API 密钥具有 1:1 的关系。我们设置的其他模拟帐户似乎是工作帐户的精确副本，除了不同的名称和密码，但当我们尝试从 EWS 托管 API 使用它们时，我们收到此错误：
请求失败。远程服务器返回错误：(401) 未经授权。
堆栈跟踪：
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
正如我所说，当使用与某个其他模拟帐户相对应的 API 密钥时，相同的代码可以正常工作；如果我将非工作 api 密钥设置为使用工作模拟帐户，则 api 密钥开始工作。
由于一个帐户可以工作，而另一个帐户则不能，我认为这意味着问题不在于我的 Web 服务代码，而在于模拟帐户设置或 Web 和 Exchange 服务器之间存在的某种配置。但如果是服务器之间的配置，我认为这会阻止所有帐户工作。
与此同时，我认为我们有一些非常非常有能力的交易所管理员，其中至少有两个人查看了假冒帐户并得出结论认为它们不是问题所在。
我们可以去哪里？我认为一种可能的解决方案是通过工作模拟帐户引导所有请求并处理审计影响，但如果我们可以避免这种情况，我们愿意这样做。有什么想法吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Exchange 服务器本身有一些诊断日志记录设置，其中一项专门用于“MSExchange Web 服务”。您可以咨询您的 Exchange 管理员，看看他们是否愿意打开该功能，也许您可以从这些日志中获得更多帮助。
The Exchange server itself has some diagnostic logging settings, one specifically for the "MSExchange Web Services". You might check with your Exchange admins and see if they're willing to turn that on and maybe you can get some more help out of those logs.
事实证明，问题出在模拟帐户配置上。但我不知道 Exchange 管理员是如何解决这个问题的。
As it turns out, the issue was impersonation account configuration. I don't know how the Exchange admins figured that out, though.