OWA リダイレクトは、Exchange Server 2019、2016、または 2013 の 2021 年 11 月のセキュリティ更新プログラムをインストールした後に機能しません

現象

Microsoft Exchange Server 2019、2016、または 2013 の 2021 年 11 月のセキュリティ更新プログラム (KB5007409) をインストールすると、ハイブリッド環境でのOutlook on the web (OWA) リダイレクトが壊れます。

オンプレミス展開の場合、サイト間 OWA リダイレクトは、フォーム ベース認証 (FBA) プロトコルを使用していない環境でも動作を停止する可能性があります。

予期せぬ動作

ハイブリッド環境の場合

Exchange Onlineメールボックスを持つユーザーは、オンプレミスの OWA にログインすると、https://outlook.office.com を指すリダイレクト URL を受け取ります。

オンプレミス環境の場合

異なる URL を使用して OWA にアクセスする複数の Active Directory (AD) サイト (たとえば、サイト 1 = https://site1.contoso.com/owa、サイト 2 = https://site2.contoso.com/owa) にまたがる Exchange 展開では、site1 のメールボックスを持ち、"site2" URL を使用して OWA にログインしたユーザーは、"site1" URL にサイレント リダイレクトされます。

実際の動作

どちらのシナリオでも、ユーザーはログインできません。Exchange Server 2019 または 2016 で次のエラー メッセージが表示されます。

ユーザーは、Exchange Server 2013 で次のエラー メッセージを受け取ります。

解決策

この問題は、Microsoft Exchange Serverの 2022 年 1 月のセキュリティ更新プログラムで修正されています。 1 月のセキュリティ更新プログラムをインストールして、「現象」セクションに記載されている OWA リダイレクトの問題を解決します。

1 月のセキュリティ更新プログラムをインストールできない場合は、次のセクションのいずれかの方法を使用して、OWA リダイレクトの問題を回避します。

回避策

オンプレミスのクロスサイト リダイレクトの失敗シナリオの場合

回避策 1

影響を受けるすべてのフロントエンド サーバーで、FBA を使用するように OWA と ECP の仮想ディレクトリを構成します。

回避策 2

各サイトのユーザーに、適切なサイト固有の OWA URL を使用してログインするように依頼します。

例:

サイト 2 にメールボックスがあるユーザーは 、https://site2.contoso.com/owa を使用する必要があります。

ハイブリッド シナリオの場合

回避策 1

ユーザーは、https://outlook.office.com/owa のブラウザーで Exchange Online OWA の直接 URL を使用できます。

回避策 2

メモ次の回避策は、Exchange Server 2019 および Exchange Server 2016 にのみ適用されます。

Exchange Server管理者は、リダイレクト ルールを使用してリダイレクト URL を変更して、エラーがユーザーに表示されないようにすることができます。 この回避策の手順は、OWA トラフィックを処理するすべてのサーバーで構成する必要があります。

URL 書き換えを適用する手順

1. IIS マネージャーを開きます。 [ 接続 ] ウィンドウで、 <ServerName>を展開し、[ サイト] を展開し、[ 既定の Web サイト] を選択します。

   メモ この手順では、 <ServerName> をサーバーの名前に置き換えます。

2. [機能 (中央)] ペインには、IIS 領域に URL 書き換え機能が表示されます。 表示されない場合は、機能がインストールされていない可能性があります。 この場合、インストール パッケージは URL 書き換え: 公式の Microsoft IIS サイトからダウンロードできます。 このインストールでは、再起動は必要ありません。 ただし、IIS アプリ プールが再起動されます。

   メモ必ず X64 バージョンをインストールしてください。
   URL 書き換えモジュールが既にサーバーにインストールされていて、パス指定を使用してサーバーが同様に構成されている場合は、変更を行った後、最初のサーバーの Wwwroot フォルダーから他のサーバーに Web.config ファイルをコピーできます。 変更が最初のサーバーで有効になるまでしばらく待つ必要がある場合があることに注意してください。

   

3. [URL の書き換え] をダブルクリックします。

4. [ 操作 ] ウィンドウで、[ ルールの追加] を選択します。
   

5. [ 規則の追加 ] ウィンドウの [ 受信規則] で、[ 空白の規則] を選択し、[ OK] を選択します。
   

6. [ 受信規則の編集] 画面の [名前 ] ボックスに「 Nov21 OWA redirect fix」と入力します。

7. [要求された URL] を[パターンに一致する] のままにします。

8. [ 使用 ] の値を [ワイルドカード] に変更します。

9. [ パターン] に「 *owa/Auth/errorFE.aspx*」と入力します。

10. [大文字と小文字を区別しない] をオンのままにします。

    

11. [ 条件 ] ボックスの一覧を選択して展開し、[ 追加] を選択します。

    

12. [ 条件の編集 ] ダイアログ ボックスの [ 条件] 入力 ボックスに「 {REQUEST_URI}」と入力します。

13. 入力文字列を [パターンに一致する] のままにします。

14. [ パターン] に「 *\u0026*\u0026*\u0026*」と入力します。

15. [OK] を選択します。
    

16. [アクション] ダイアログ ボックスの [アクションの種類] ボックスの一覧で [書き換え] を選択します。

17. [ アクションのプロパティ] の [ URL の書き換え ] テキスト ボックスに、次のコードを入力します。

    {C:1}&{C:2}&{C:3}&{C:4}

18. [ クエリ文字列の追加] チェック ボックスをオフにします。

19. [ ログに書き換えられた URL ] チェック ボックスをオンにします。

20. [ 操作 ] ウィンドウで、[ 適用] を選択します。
    

21. [ 適用] を選択し、[ 規則に戻る] を選択します。

22. [URL 書き換え] ウィンドウで、作成したルールを選択し、[操作] ウィンドウの [受信規則] の下にチェックして、ルールが有効になっていることを確認します。
    

    この新しいルールでは IIS のリセットは必要ありません。また、有効にするとすぐに有効になります。 これで、(問題を再現したアカウントを使用して) OWA を使用してテストし、予想される URL リダイレクトが得られるかどうかを確認できます。

ログ記録を有効にしてルール アクションを確認する

予想されるリダイレクト動作を確認するには、失敗した要求トレースを使用できます。 手順は次のとおりです。

1. IIS マネージャーを開きます。 [ 接続 ] ウィンドウで、[ 既定の Web サイト] を選択します。

2. [ 操作 ] ウィンドウの [ 構成] で、[ 失敗した要求トレース] を選択します。

3. [ Web サイトの失敗した要求トレース設定の編集 ] ダイアログ ボックスで、[ 有効] を選択します。

4. [ディレクトリ] と [トレース ファイルの最大数] の値は変更しません。

5. [OK] を選択します。
   

6. 中央のウィンドウで、[ 失敗した要求トレース] をダブルクリックします。

7. [ 操作 ] ウィンドウで、[ 追加] を選択します。

8. [ カスタム] を選択し、「 errorFE.aspx」と入力します。
   

9. [ 状態コード] に「 100-900」と入力し、[完了] を選択 します。
   

10. [ASP、ASPNET、ISAPI 拡張機能] チェック ボックスをオフにします。

11. [ WWW サーバー] を選択します。 [ 領域] で、最後のオプション ( [書き換え]) 以外の選択をすべて解除します。

12. [完了] をクリックします。
    

13. オンプレミス OWA のExchange Online メールボックスに再度ログインしてみてください。

14. 影響を受けるサーバー上の Windows エクスプローラーで、C:\inetpub\logs\FailedReqLogFiles に移動します。

15. 最新の .xml ファイルをダブルクリックします。 以前にトレースを行っていない場合、このファイルは Fr000001.xml される可能性があります。

16. 最後の行を選択します。これは要求 のすべてのイベントを表示する必要があります。

17. URL_REWRITE_STARTとURL_REWRITE_ENDを探します。 これらのイベント間のコンテンツを調べます。  次のエントリが表示されます。

    ULE_EVALUATION_START
    PATTERN_MATCH
    CONDITION_EVALUATION
    REWRITE_ACTION
    RULE EVALUATION_END

18. REWRITE_ACTION値を確認します。  書き換え では、 すべての \0026 パターンをアンパサンド (&) に変更する必要があります。

複数のサーバーへのデプロイ

1 つのサーバーでこれらの手順を完了すると、前述の URL 書き換えモジュールが既にすべての Exchange クライアント アクセス サーバーにインストールされている限り、複数のサーバーに簡単に展開できます。

すべてのサーバーで現在の Web.config ファイルのバックアップを作成することをお勧めします。 ただし、ルールを作成したサーバーで変更を加えた後は、そのサーバーの C:\inetpub\wwwroot フォルダーから他のサーバーの同じ場所に Web.config ファイルをコピーできます。 構成の変更が有効になるまでしばらく待つ必要があることに注意してください。 プロセスを高速化するには、 iisreset コマンドを実行します。