0

私が次のことをしたら

var autodiscoverService = new AutodiscoverService{
    // Timeout = 100,  // Appears to have no impact
    EnableScpLookup = false,
    RedirectionUrlValidationCallback =
        delegate { return true; },
    PreAuthenticate = true,
    TraceEnabled = true,
    TraceFlags = TraceFlags.All,
    TraceListener = listener,
    Credentials =
        new WebCredentials("billg@microsoft.com", "anything", null)
};

最初に表示されるトレース メッセージは次のとおりです。

<Trace Tag="AutodiscoverConfiguration" Tid="19" Time="2012-07-06 16:05:09Z">
   Determining which endpoints are enabled for host microsoft.com
</Trace>

時刻 (:09) に注意してください。次のイベントは約 40 秒後です。

<Trace Tag="AutodiscoverConfiguration" Tid="19" Time="2012-07-06 16:05:51Z">
   Determining which endpoints are enabled for host autodiscover.microsoft.com
</Trace>

その後すぐに (予想どおり、認証は失敗します)。

https://www.testexchangeconnectivity.com/でExchange 接続テスターを使用すると、無効な認証情報を使用しても、ほとんどすぐに回答が得られます。

テストする有効な MS アカウントを持っていませんが、1 人にテストを依頼したところ、有効なユーザー名/パスワードを使用しても同じ 40 秒のタイムアウトが発生しました。

ほんの数週間前にこれをテストしたところ、Microsoft の自動検出設定に問題は見られませんでした。最近何かが変わったのではないかと思います。

この質問では例として microsoft.com を使用していますが、これと同じ遅延が発生し、私のユーザーにとってはひどい構成の Exchange セットアップが他にもあるのではないかと心配しています。

私は設定を試みましたがautodiscoverService.Timeout = 100、それは役に立ちませんでした。

EWS の自動検出機能をより細かく制御する方法はありますか?

他にどのようにこの問題に対処/回避できますか?

4

1 に答える 1

0

問題は、ドメイン「microsoft.com」が予想される方法で自動検出を実装していないことだと思います。その結果、自動検出サービスは考えられるすべてのエンドポイントを試行し、最終的に失敗します。

私の電子メール アドレス/資格情報を使用してコードを試し、MS がAutodiscoverService.GetUserSettings Methodで提供する例に基づいて GetUserSettings 要求を発行しました。

オンプレミスの Exchange と Office 365 の両方を使用してテストしましたが、オンプレミスの Exchange は約 2 秒で完了し、Office 365 は開始から終了まで 7 秒かかりました。

次に、使用した電子メールアドレス/資格情報を使用するようにコードを変更しましたが、同じ 40 タイムアウトが発生しました。

これを microsoft.com 以外の別のドメインに対してテストしてみましたか?

于 2012-07-08T04:55:31.373 に答える