1

Exchange Webサービス2010での作業は、特に.NET以外では少しばかげているため、他の言語がExchangeと対話するためのパススルーとして機能するSOAPWebサービスに一部の機能をラップする必要があります。環境。

[その他] <-（SOAP）-> ASP.NET ASMX Webサービス<-（EWSマネージAPI）-> Exchange2010

ユーザーがすべてのアクションでパスワードを入力する必要がないように、偽装アカウントを使用しているため、必要なのは変更するアカウントのアカウント名だけです。

これはすべてかなりうまく機能します。なりすましアカウントの1つを使用します。偽装アカウントは、監査を簡素化する目的で、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キーが機能し始めます。

1つのアカウントは機能し、別のアカウントは機能しないため、問題はWebサービスコードにあるのではなく、偽装アカウントのセットアップまたはWebサーバーとExchangeサーバーの間に存在するある種の構成にあると解釈します。ただし、サーバー間の構成の場合は、すべてのアカウントが機能しなくなると思います。

同時に、私たちは非常に有能な取引所管理者であると私が信じているものを持っており、少なくとも2人はなりすましアカウントを調べて、問題ではないと結論付けています。

ここからどこへ行けますか？考えられる解決策の1つは、すべてのリクエストを実際のなりすましアカウントに転送し、監査の影響に対処することだと思いますが、それを回避できるのであれば、そうしたいと思います。何か案は？

4

2 に答える 2

1

Exchangeサーバー自体には、「MSExchangeWebサービス」専用の診断ログ設定がいくつかあります。Exchange管理者に確認して、それをオンにする意思があるかどうかを確認し、それらのログからさらにヘルプを得ることができるかもしれません。

于 2010-09-23T14:34:52.807 に答える
0

結局のところ、問題はなりすましアカウントの構成でした。ただし、Exchange管理者がそれをどのように理解したかはわかりません。

于 2010-09-24T03:06:24.167 に答える