非永続的 RDS 環境での Outlook 検索の処理

適用対象: Windows Server (半期チャネル)、Windows Server 2016

非永続的 (プールされた) リモート デスクトップ サービス環境で顧客が直面する一般的な問題は、ユーザーの Outlook データの処理です。 Outlook がキャッシュ交換モードで実行されている場合は、 です。ユーザーの Outlook データを格納する OST は、ホストからホストへのローミング時にユーザーに従う必要があります。 Windows Search Service では、 のインデックスが作成されます。OST と では、Outlook で検索機能を有効にするインデックス カタログが作成されます。 非永続的 RDS 環境では、インデックス カタログはユーザー データをローミングせず、ユーザーが新しい PC にサインインするたびに再構築する必要があります。これは、すべてのサインオンになる可能性があります。 Windows Search Service が のインデックス作成を完了するまで。OST では、ユーザーは制限付き検索機能または不完全な検索機能を利用できます。

RDS Gurus の発行されたレポートによると、FSLogix (サード パーティ ソリューション プロバイダー) には、この問題を解決することを目的としたソリューションがあります。FSLogix の Office 365 Container は、ユーザーの Outlook データとその検索インデックス カタログをローミングし、ユーザーがメールにアクセスできるようにし、ユーザーがコレクション内の異なるホスト上のセッション間をローミングする場合でも Outlook で検索できるようにします。 

RDS Gurus は、FSLogix の Office 365 Container に対してテストを実行し、RDS のネイティブ ユーザー プロファイル ディスク ローミング ソリューションと比較しました。 このテスト シナリオでは、RD セッション ホスト (RDSH) 上の非永続的セッションのオンプレミス環境と Azure RDS 環境の両方について説明しました。 テストには、オンプレミス専用の RD 仮想化ホスト (RDVH) 上のプールされた VM も含まれていました (Azure では RDVH は使用できません)。 RDS Gurus は、主に、"ノイズの多い隣人" がある場合、またはシステム上で同様のワークロードを実行している同じセッション ホストにログオンしている他のユーザーがユーザー エクスペリエンスに焦点を当てていました。

これらのテストで収集されたパフォーマンス カウンターでは、UPD と FSLogix の両方で同様のリソース使用量 (CPU、RAM、ネットワーク アクティビティ) が明らかになります。 リソース使用量の類似性は、インデックス作成時に Windows Search Service によって CPU 使用率が調整されるためです。 ユーザー エクスペリエンスに関しては、RDS Gurus は、FSLogix の Office 365 Container が Outlook 検索機能の UPD を超えていることがわかりました。 UPD の場合、Windows Search Service で のインデックスが作成されるため、検索では結果が返されないか、不完全な結果が返されます。Ost。 FSLogix はインデックス カタログをローミングするため、ユーザーはすぐに検索結果を表示します。 RDS Gurus では、FSLogix を使用して非永続的な RDS 環境で Outlook を検索するときに、ユーザー エクスペリエンスが大幅に向上しました。

RDS Gurus ブログで結果と結論の詳細を確認してください。