Office 365 のパフォーマンス トラブルシューティング計画

SharePoint、OneDrive、Exchange Online、または Skype for Business Online とクライアント コンピューターの間のラグ、ハング、パフォーマンス低下を特定して修正するための手順を知る必要がありますか? サポートを呼び出す前に、この記事は、Office 365のパフォーマンスの問題のトラブルシューティングや、最も一般的な問題の一部の修正に役立ちます。

この記事は、実際には、パフォーマンスの問題に関する貴重なデータをキャプチャするために使用できるサンプル アクション プランです。 この記事には、いくつかの一部の問題も含まれています。

ネットワーク パフォーマンスを初めて使用し、クライアント マシンとOffice 365の間のパフォーマンスを監視する長期的な計画を立てる場合は、パフォーマンスのチューニングとトラブルシューティング (管理と IT Pro) Office 365参照してください。

パフォーマンストラブルシューティングアクションプランのサンプル

このアクション プランには 2 つの部分が含まれています。準備フェーズ、およびログフェーズ。 現在パフォーマンスに問題があり、データ収集を行う必要がある場合は、すぐにこのプランの使用を開始できます。

クライアント コンピューターを準備する

• パフォーマンスの問題を再現できるクライアント コンピューターを見つけます。 このコンピューターはトラブルシューティング中に使用されます。
• パフォーマンスの問題が発生する原因となる手順を書き留めて、テストの準備を整えます。
• 情報を収集および記録するためのツールをインストールします。
  • Netmon 3.4 をインストールします (または、同等のネットワーク トレース ツールを使用します)。
  • HTTPWatch の無料の Basic Edition をインストールします (または、同等のネットワーク トレース ツールを使用します)。
  • テスト中に実行した手順を記録するには、スクリーン レコーダーを使用するか、Windows Vista 以降に付属のステップ レコーダー (PSR.exe) を実行します。

パフォーマンスの問題をログに記録する

• すべての不要なインターネット ブラウザーを閉じます。

• ステップ レコーダーまたは別のスクリーン レコーダーを起動します。

• Netmon キャプチャ (またはネットワーク トレース ツール) を開始します。

• ipconfig /flushdns と入力して、コマンド ラインからクライアント コンピューターの DNS キャッシュをクリアします。

• 新しいブラウザー セッションを開始し、HTTPWatch を有効にします。

• 省略可能: Exchange Onlineをテストする場合は、Office 365管理コンソールから Exchange クライアント パフォーマンス アナライザー ツールを実行します。

• パフォーマンスの問題の原因となる正確な手順を再現します。

• Netmon またはその他のツールのトレースを停止します。

• コマンド ラインで、次のコマンドを入力して Enter キーを押して、Office 365 サブスクリプションへのトレース ルートを実行します。

  tracert <subscriptionname>.onmicrosoft.com
  

• ステップレコーダーを停止し、ビデオを保存します。 キャプチャの日付と時刻と、パフォーマンスが良好か悪いかを必ず含めます。

• トレース ファイルを保存します。 ここでも、キャプチャの日付と時刻、およびパフォーマンスが良好か悪いかを必ず含めます。

この記事で説明されているツールの実行に慣れていない場合は、次にこれらの手順を提供するので心配しないでください。 この種のネットワーク キャプチャに慣れている場合は、「 ベースラインを収集する方法」に進み、ログのフィルター処理と読み取りについて説明します。

最初に DNS キャッシュをフラッシュする

どうしてでしょうか? DNS キャッシュをフラッシュすることで、クリーンスレートでテストを開始します。 キャッシュをクリアすることで、DNS リゾルバーの内容を最新のエントリにリセットします。 フラッシュでは HOST ファイル エントリは削除されません。 HOST ファイル・エントリーを広範囲に使用する場合は、それらのエントリーを別のディレクトリー内のファイルにコピーしてから、HOST ファイルを空にする必要があります。

DNS リゾルバー キャッシュをフラッシュする

1. コマンド プロンプト ( Start>Run>cmd または Windows キー>cmd) を開きます。

2. 次のコマンドを入力し、Enter キーを押します。

   ipconfig /flushdns
   

Netmon

Microsoft のネットワーク監視ツール (Netmon) は、ネットワーク上のコンピューター間を通過するパケット (ネットワーク トラフィック) を分析します。 Netmon を使用して、Office 365を使用してトラフィックをトレースすることで、パケット ヘッダーのキャプチャ、表示、読み取り、介在するデバイスの特定、ネットワーク ハードウェア上の重要な設定のチェック、ドロップされたパケットの検索、企業ネットワークとOffice 365上のコンピューター間のトラフィックのフローに従うことができます。 トラフィックの実際の本文は暗号化されているため、つまり、SSL/TLS 経由でポート 443 を移動するため、送信されるファイルを読み取ることはできません。 代わりに、パケットが受け取るパスのフィルター処理されていないトレースを取得します。これは、問題の動作を追跡するのに役立ちます。

現時点ではフィルターを適用しないでください。 代わりに、手順を実行し、トレースを停止して保存する前に問題を示します。

Netmon 3.4 をインストールした後、ツールを開き、次の手順を実行します。

Netmon トレースを取得し、問題を再現する

1. Netmon 3.4 を起動します。 [スタート] ページには、[最近のキャプチャ]、[ネットワークの選択]、[Microsoft Network Monitor 3.4 を使用したはじめに] の 3 つのペインがあります。注意してください。 [ネットワークの選択] パネルには、キャプチャ元の既定のネットワークの一覧も表示されます。 ここでネットワーク カードが選択されていることを確認します。

2. [スタート] ページの上部にある [新しいキャプチャ] をクリックします。 これにより、[キャプチャ 1] という名前の [スタート] ページ タブの横に新しいタブが追加されます。

3. 単純なキャプチャを行う場合は、ツール バーの [開始 ] をクリックします。

4. パフォーマンスの問題を示す手順を再現します。

5. [ファイルの名前を付けて保存を>停止>] をクリックします。 タイム ゾーンの日付と時刻を指定し、パフォーマンスが悪い、または良好なパフォーマンスを示す場合は、メンションしてください。

HTTPWatch

HTTPWatch は有料で、無料のエディションが用意されています。 無料の Basic Edition では、このテストに必要なものがすべて網羅されています。 HTTPWatch は、ブラウザー ウィンドウからネットワーク トラフィックとページ読み込み時間を監視します。 HTTPWatch は、パフォーマンスをグラフィカルに記述する Microsoft Edge へのプラグインです。 分析は HTTPWatch Studio で保存および表示できます。

注:

Firefox、Google Chrome などの別のブラウザーを使用している場合、または Edge に HTTPWatch をインストールできない場合は、新しいブラウザー ウィンドウを開き、キーボードの F12 キーを押します。 ブラウザーの下部に [開発者ツール] ポップアップが表示されます。 Opera を使用する場合は、Ctrl キーを押しながら Shift キーを押しながら I キーを押して [Web インスペクター] を選択し、[ ネットワーク ] タブをクリックして、以下に示すテストを完了します。 情報は若干異なりますが、読み込み時間はミリ秒単位で表示されます。 > HTTPWatch は、SharePoint ページの読み込み時間に関する問題にも非常に役立ちます。

HTTPWatch を実行し、問題を再現する

HTTPWatch はブラウザー プラグインであるため、ブラウザーでツールを公開することは、Microsoft Edge のバージョンごとに若干異なります。 通常、HTTPWatch は Microsoft Edge ブラウザーの [コマンド] バーにあります。 ブラウザー ウィンドウに HTTPWatch プラグインが表示されない場合は、[ヘルプ>] をクリックしてブラウザーのバージョンをチェックするか、以降のバージョンの Microsoft Edge で歯車記号と [エッジについて] をクリックします。 コマンド バーを起動するには、Microsoft Edge のメニュー バーを右クリックし、[コマンド バー] をクリックします。

以前は、HTTPWatch はコマンドバーとエクスプローラーバーの両方に関連付けられていたため、インストールすると、アイコン (再起動後も) チェックツールとアイコンのツールバーがすぐに表示されない場合。 ツール バーはカスタマイズでき、オプションを追加できることに注意してください。

1. Microsoft Edge ブラウザー ウィンドウで HTTPWatch を起動します。 そのウィンドウの下部にブラウザーにドッキングされたように表示されます。 [ レコード] をクリックします。

2. パフォーマンスの問題に関連する正確な手順を再現します。 HTTPWatch の [停止 ] ボタンをクリックします。

3. HTTPWatch または Send by Emailを保存します。 ファイルに名前を付けて、日付と時刻の情報と、Watch にパフォーマンスの良さと悪さのデモンストレーションが含まれているかどうかを示す名前を付けます。

このスクリーンショットは、プロフェッショナル バージョンの HTTPWatch からのスクリーンショットです。 Professional バージョンのコンピューターで Basic バージョンで取得したトレースを開き、そこで読み取ることができます。 追加情報は、そのメソッドを介してトレースから入手できる場合があります。

問題ステップ レコーダー

ステップ レコーダー (PSR.exe) を使用すると、問題が発生しているときに記録できます。 これは非常に便利なツールであり、簡単に実行できます。

問題ステップ レコーダー (PSR.exe) を実行して作業内容を記録する

1. [実行>の開始>] の種類 PSR.exe>[OK] を使用するか、[Windows キー>の種類] PSR.exe> をクリックして Enter キーを押します。

2. 小さな PSR.exe ウィンドウが表示されたら、[ レコードの開始 ] をクリックし、パフォーマンスの問題を再現する手順を再現します。 [コメントの追加] をクリックすると、必要に応じて コメントを追加できます。

3. 手順が完了したら、[ レコードの停止 ] をクリックします。 パフォーマンスの問題がページ レンダリングの場合は、記録を停止する前にページがレンダリングされるのを待ちます。

4. [保存] をクリックします。

日付と時刻が記録されます。 これにより、PSR が Netmon トレースと HTTPWatch に時間内にリンクされ、精度のトラブルシューティングに役立ちます。 PSR レコードの日付と時刻は、サインインと URL の参照と管理サイトの部分的なレンダリングの間で 1 分が経過したことを示すことができます。たとえば、

トレースを読み取る

誰かが記事を介して知る必要があるネットワークとパフォーマンスのトラブルシューティングに関するすべてを教えることはできません。 パフォーマンスを高めるには、ネットワークのしくみと通常のパフォーマンスに関する経験と知識が必要です。 ただし、上位の問題の一覧を切り上げ、ツールを使用して最も一般的な問題を簡単に排除する方法を示すことができます。

Office 365 サイトのネットワーク トレースを読み取るスキルを習得する場合は、ページ読み込みのトレースを定期的に作成し、読み取り経験を得るよりも優れた教師はいません。 たとえば、機会がある場合は、Office 365 サービスを読み込み、プロセスをトレースします。 DNS トラフィックのトレースをフィルター処理するか、FrameData で参照したサービスの名前を検索します。 トレースをスキャンして、サービスの読み込み時に発生する手順を把握します。 これにより、通常のページ読み込みのようになります。特にパフォーマンスに関するトラブルシューティングの場合は、良好なトレースと悪いトレースを比較すると、多くのことを教えることができます。

Netmon は、[表示フィルター] フィールドで Microsoft Intellisense を使用します。 Intellisense (インテリジェント コード補完) は、期間に入力し、使用可能なすべてのオプションがドロップダウン選択ボックスに表示されるトリックです。 たとえば、TCP ウィンドウのスケーリングが心配な場合は、この方法でフィルター (など .protocol.tcp.window < 100) への道を見つけることができます。

Netmon トレースには多数のトラフィックが含まれる場合があります。 読み取り経験がない場合は、初めてトレースを開くと圧倒される可能性があります。 まず、トレース内のバックグラウンド ノイズから信号を分離します。 Office 365に対してテストしました。これは、表示するトラフィックです。 トレース間の移動に慣れている場合は、この一覧が必要ない場合があります。

クライアントとOffice 365間のトラフィックは TLS 経由で移動します。つまり、トラフィックの本文は暗号化され、汎用 Netmon トレースでは読み取りできません。 パフォーマンス分析では、パケット内の情報の詳細を把握する必要はありません。 ただし、パケット ヘッダーと、そのヘッダーに含まれる情報に非常に関心があります。

適切なトレースを取得するためのヒント

• クライアント コンピューターの IPv4 または IPv6 アドレスの値を把握します。 これを取得するには、コマンド プロンプトで 「IPConfig」 と入力し、Enter キーを押します。 このアドレスを知ることで、トレース内のトラフィックがクライアント コンピューターに直接関係しているかどうかをひとめで確認できます。 既知のプロキシがある場合は、ping を実行し、その IP アドレスも取得します。

• DNS リゾルバー キャッシュをフラッシュし、可能であれば、テストを実行しているブラウザーを除くすべてのブラウザーを閉じます。 これを行えない場合は、たとえば、サポートがブラウザー ベースのツールを使用してクライアント コンピューターのデスクトップを表示している場合は、トレースをフィルター処理する準備をします。

• ビジー トレースで、使用しているOffice 365 サービスを見つけます。 これまでにトラフィックを確認したことがない場合、これはパフォーマンスの問題を他のネットワーク ノイズから分離する際に役立つ手順です。 これを行うには、いくつかの方法があります。 テストの直前に、特定のサービス (ping outlook.office365.comまたは など) の URL に対して ping または psping -4 microsoft-my.sharepoint.com:443PsPing を使用できます。 また、(そのプロセス名によって) Netmon トレースでその ping または PsPing を簡単に見つけることもできます。 それはあなたに探し始める場所を与えます。

問題の時点で Netmon トレースのみを使用している場合は、それも問題ありません。 自分の向きを設定するには、 や ContainsBin(FrameData, ASCII, "outlook")のようなContainsBin(FrameData, ASCII, "office")フィルターを使用します。 トレース ファイルからフレーム番号を記録できます。 [ フレームの概要 ] ウィンドウを右までスクロールし、[会話 ID] 列を探すこともできます。 この特定の会話の ID には、後で分離して記録して確認できる番号が示されています。 他のフィルター処理を適用する前に、このフィルターを削除してください。

ヒント

Netmon には、多くの便利な組み込みフィルターがあります。 [フィルターの表示] ウィンドウの上部にある [フィルターの読み込み] ボタンを試してください。

トラフィックを理解し、必要な情報を見つける方法を学習します。 たとえば、トレース内のどのパケットが、使用しているOffice 365 サービスへの最初の参照 ("Outlook" など) を持つかを判断する方法について説明します。

Outlook Online Office 365例として、トラフィックは次のように開始されます。

• 一致するクエリ ID を持つ outlook.office365.com の DNS 標準クエリと DNS 応答。 このターンアラウンドのタイム オフセットと、Office 365 グローバル DNS が名前解決の要求を送信する場所に注意することが重要です。 理想的には、世界中の中途半端ではなく、可能な限りローカルに。

• 状態レポートが永続的に移動された HTTP GET 要求 (301)

• RWS Connect 要求と Connect 応答を含む RWS トラフィック。 (これは、接続を行うリモート Winsock です)。

• TCP SYN と TCP SYN/ACK の会話。 この会話の多くの設定は、パフォーマンスに影響します。

• 次に、TLS ハンドシェイクと TLS 証明書の会話が行われる一連の TLS:TLS トラフィック。 (データは SSL/TLS 経由で暗号化されていることに注意してください)。

トラフィックのすべての部分は重要で接続されていますが、トレースのごく一部にはパフォーマンスのトラブルシューティングの観点から重要な情報が含まれているため、これらの領域に焦点を当てます。 また、Microsoft でパフォーマンスのトラブルシューティングOffice 365十分に行い、一般的な問題の上位 10 個の一覧をコンパイルしたので、これらの問題と、それらを根絶するために必要なツールの使用方法に焦点を当てます。

まだインストールしていない場合は、以下のマトリックスで可能な限りいくつかのツールを使用します。 インストール ポイントへのリンクが提供されます。 この一覧には、Netmon や Wireshark などの一般的なネットワーク トレース ツールが含まれていますが、使い慣れたトレース ツールを使用し、ネットワーク トラフィックのフィルター処理に慣れているものをすべて使用します。 テストするときは、次の点に注意してください。

• ブラウザーを閉じ、1 つのブラウザーのみを実行してテスト します。これにより、キャプチャする全体的なトラフィックが減少します。 これにより、ビジートレースが少なくなります。
• クライアント コンピューターで DNS リゾルバー キャッシュをフラッシュする - これにより、キャプチャの取得を開始すると、よりクリーンなトレースのクリーンスレートが得られます。

一般的な問題

発生する可能性のあるいくつかの一般的な問題と、ネットワーク トレースでそれらを見つける方法。

TCP Windows スケーリング

SYN - SYN/ACK にあります。 レガシまたはエージング ハードウェアでは、TCP ウィンドウのスケーリングを利用できない場合があります。 適切な TCP ウィンドウスケーリング設定がない場合、TCP ヘッダーの既定の 16 ビット バッファーはミリ秒単位で入力されます。 クライアントが元のデータが受信されたことを確認して遅延を引き起こすまで、トラフィックは送信を続行できません。

ツール

• Netmon
• Wireshark

検索対象

ネットワーク トレースで SYN - SYN/ACK トラフィックを探します。 Netmon で、 のような tcp.flags.syn == 1フィルターを使用します。 このフィルターは、Wiresharkでも同じです。

SYN ごとに、関連する受信確認 (SYN/ACK) の宛先ポート (DstPort) に一致する送信元ポート (SrcPort) 番号があることに注意してください。

ネットワーク接続で使用されている Windows スケーリング値を確認するには、最初に SYN を展開し、次に関連する SYN/ACK を展開します。

TCP アイドル時間の設定

従来、ほとんどの境界ネットワークは一時的な接続用に構成されています。つまり、アイドル接続は一般的に終了します。 アイドル状態の TCP セッションは、プロキシとファイアウォールによって 100 秒から 300 秒を超えて終了できます。 これは、アイドル状態かどうかにかかわらず、長期的な接続を作成して使用するため、Outlook Online では問題になります。

接続がプロキシまたはファイアウォール デバイスによって終了されると、クライアントには通知されません。また、Outlook Online を使用しようとすると、クライアント コンピューターは、新しい接続を作成する前に、接続を再び再生しようとします。 ページの読み込み時に、製品のハング、プロンプト、またはパフォーマンスの低下が表示される場合があります。

ツール

• Netmon
• Wireshark

検索対象

Netmon で、[時間オフセット] フィールドでラウンド トリップを確認します。 ラウンド トリップとは、クライアントがサーバーに要求を送信してから応答を受信するまでの時間です。 クライアントとエグレス ポイント (例: クライアント --> プロキシ)、またはOffice 365するクライアント (クライアント --> Office 365) の間で確認します。 これは、さまざまな種類のパケットで確認できます。

たとえば、Netmon のフィルターは、 のように表示.Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12されるか、Wiresharkip.addr == 10.102.14.112 && ip.addr == 10.201.114.12では のようになります。

ヒント

トレース内の IP アドレスが DNS サーバーに属しているかどうかを知りませんか? コマンド ラインで調べることをお試しください。 [Start Run]\(実行>の開始\>) をクリックし、「cmd」と入力するか、Windows キーを>押して「cmd」と入力します。 プロンプトに「」と入力します nslookup <the IP address from the network trace>。 テストするには、自分のコンピューターの IP アドレスに対して nslookup を使用します。 >Microsoft の IP 範囲の一覧については、「OFFICE 365 URL と IP アドレス範囲」を参照してください。

問題が発生した場合は、長い時間オフセットが表示されることを想定します。この場合 (Outlook Online)、特にアプリケーション データの通過を示す TLS:TLS パケット (たとえば、Netmon では を使用して .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"アプリケーション データ パケットを見つけることができます)。 セッション全体の時間がスムーズに進むはずです。 Outlook Online の更新時に長い遅延が発生する場合は、高度なリセットが送信されていることが原因である可能性があります。

待機時間/ラウンド トリップ時間

待機時間は、エージング デバイスのアップグレード、ネットワークへの多数のユーザーの追加、ネットワーク接続上の他のタスクによって消費される帯域幅全体の割合など、多くの変数に応じて大きく変化する可能性のあるメジャーです。

Office 365用の帯域幅計算ツールは、この [ネットワークの計画とパフォーマンスのチューニング] ページOffice 365参照してください。

接続の速度、または ISP 接続の帯域幅を測定する必要がありますか? このサイト(またはそのようなサイト)を試してみてください: Speedtest公式サイト、またはフレーズ スピードテストのためにお気に入りの検索エンジンにクエリを実行します。

ツール

• ping
• PsPing
• Netmon
• Wireshark

検索対象

トレースの待機時間を追跡するには、クライアント コンピューターの IP アドレスと DNS サーバーの IP アドレスをOffice 365に記録することでメリットがあります。 これは、トレース のフィルター処理を容易にするためです。 プロキシ経由で接続する場合は、作業を容易にするために、クライアント コンピューターの IP アドレス、プロキシ/エグレス IP アドレス、Office 365 DNS IP アドレスが必要です。

outlook.office365.com に送信された ping 要求は、商標の連続した ICMP パケットを送信するために ping が接続できない 場合 でも、要求を受信するデータセンターの名前を示します。 PsPing (ダウンロード用の無料ツール) を使用し、ポート (443) を特定し、おそらく IPv4 (-4) を使用する場合は、送信されるパケットの平均ラウンドトリップ時間が得られます。 これは、Office 365 サービス内の他の URL (などpsping -4 yourSite.sharepoint.com:443) に対してこれを機能します。 実際には、いくつかの ping を指定して、平均のより大きなサンプルを取得できます。次のようなもの psping -4 -n 20 yourSite-my.sharepoint.com:443を試してください。

注:

PsPing は ICMP パケットを送信しません。 特定のポートを介して TCP パケットで ping を実行するため、開いていることがわかっている任意のポートを使用できます。 SSL/TLS を使用するOffice 365で、ポート :443 を PsPing にアタッチしてみてください。

ネットワーク トレースの実行中にパフォーマンスの低下するOffice 365 ページを読み込んだ場合は、Netmon トレースまたは Wireshark トレースを フィルター処理するDNS必要があります。 これは、探している IP の 1 つです。

IP アドレスを取得するために Netmon をフィルター処理する手順を次に示します (DNS 待機時間を確認してください)。 この例では、outlook.office365.com を使用しますが、SharePoint テナントの URL (hithere.sharepoint.com など) を使用することもできます。

1. URL ping outlook.office365.com に ping を実行し、その結果、ping 要求が送信された DNS サーバーの名前と IP アドレスを記録します。
2. ページを開くネットワーク トレース、またはパフォーマンスの問題を示すアクションの実行、または ping で待機時間が長い場合は、ネットワーク トレースを実行します。
3. Netmon でトレースを開き、DNS をフィルター処理します (このフィルターはWiresharkでも機能しますが、大文字と小文字-- dnsは区別されます)。 ping から DNS サーバーの名前を知っているので、Netmon では次のようにより迅速にフィルター処理することもできます。これは、DNS AND ContainsBin(FrameData, ASCII, "namnorthwest")dns とフレームに "namnorthwest" が含まれているWiresharkで次のようになります。
   応答パケットを開き、[Netmon フレームの 詳細 ] ウィンドウで [ DNS ] をクリックして展開して詳細を確認します。 DNS 情報には、要求が送信された DNS サーバーの IP アドレスがOffice 365に表示されます。 次の手順 (PsPing ツール) には、この IP アドレスが必要です。 フィルターを削除し、Netmon の DNS 応答 (フレーム の概要>会話>の検索 DNS) を右クリックして、DNS クエリと応答を並べて表示します。
4. Netmon では、DNS 要求と応答の間の [タイム オフセット] 列もメモします。 次の手順では、 PsPing ツールを簡単にインストールして使用できます。ICMP はファイアウォールでブロックされることが多く、PsPing は待機時間をミリ秒単位でエレガントに追跡するためです。 PsPing はアドレスとポートへの TCP 接続を完了します (ここではポート 443 を開きます)。
5. PsPing をインストールします。
6. コマンド プロンプト (Start > Run > type cmd、または Windows Key > type cmd) を開き、PsPing をインストールしたディレクトリにディレクトリを変更して PsPing コマンドを実行します。 私の例では、Cのルートに'Perf'フォルダーを作成したことがわかります。クイック アクセスでも同じことができます。
7. コマンドを入力して、以前の Netmon トレースのOffice 365 DNS サーバーの IP アドレス (ポート番号などpsping -n 20 132.245.24.82:445) に対して PsPing を作成します。 これにより、20 回の ping のサンプリングと、PsPing が停止したときの待機時間の平均が得られます。

プロキシ サーバーを使用してOffice 365する場合、手順は少し異なります。 まず、プロキシ サーバーに PsPing を実行して、プロキシ/エグレスとバックまでの平均待機時間の値をミリ秒単位で取得し、プロキシで PsPing を実行するか、インターネットに直接接続しているコンピューターで不足値 (Office 365と戻る) を取得します。

プロキシから PsPing を実行する場合は、クライアント コンピューターからプロキシ サーバーまたはエグレス ポイントへの 2 ミリ秒の値と、Office 365するプロキシ サーバーの 2 ミリ秒の値があります。 これで完了です。 さて、とにかく値を記録します。

インターネットに直接接続されている別のクライアント コンピューターで PsPing を実行する場合、つまりプロキシを使用しない場合は、クライアント コンピューターからプロキシ サーバーまたはエグレス ポイントへのクライアント コンピューター、Office 365するクライアント コンピューターの 2 ミリ秒の値があります。 この場合は、クライアント コンピューターからプロキシ サーバーまたはエグレス ポイントの値をクライアント コンピューターの値からOffice 365に減算すると、クライアント コンピューターからプロキシ サーバーまたはエグレス ポイント、プロキシ サーバーまたはエグレス ポイントから Office 365 までの RTT 番号が得られます。

ただし、影響を受ける場所に直接接続されているクライアント コンピューターが見つかるか、プロキシをバイパスしている場合は、問題が最初にそこで再現されているかどうかを確認し、その後それを使用してテストすることができます。

Netmon トレースに示されているように、待機時間は、特定のセッションに十分な数がある場合、それらの余分なミリ秒が加算される可能性があります。

注:

IP アドレスは、ここに示されている IP とは異なる場合があります。たとえば、ping から 157.56.0.0/16 などの範囲が返される場合があります。 Office 365で使用される範囲の一覧については、Office 365 URL と IP アドレス範囲をチェックします。

132.245 など、検索する場合は、すべてのノードを展開してください (上部にボタンがあります)。

プロキシ認証

これは、プロキシ サーバーを経由する場合にのみ適用されます。 そうでない場合は、これらの手順をスキップできます。 正常に動作する場合、プロキシ認証は一貫してミリ秒単位で行われます。 ピーク時の使用期間中 (たとえば) に断続的にパフォーマンスが低下することはありません。

プロキシ認証がオンになっている場合は、情報を取得するためにOffice 365に新しい TCP 接続を確立するたびに、バックグラウンドで認証プロセスを通過する必要があります。 そのため、たとえば、Outlook Online で予定表からメールに切り替えると、認証が行われます。 また、SharePoint では、ページに複数のサイトまたは場所のメディアまたはデータが表示される場合、データをレンダリングするために必要な異なる TCP 接続ごとに認証を行います。

Outlook Online では、予定表とメールボックスを切り替えるたびに読み込み時間が遅くなったり、SharePoint でページの読み込みが遅くなったりすることがあります。 ただし、ここに記載されていない他の症状があります。

プロキシ認証は、エグレス プロキシ サーバーの設定です。 Office 365でパフォーマンスの問題が発生している場合は、ネットワーク チームに問い合わせてください。

ツール

• Netmon
• Wireshark

検索対象

プロキシ認証は、通常、サーバーからファイルや情報を要求したり、情報を提供したりするために、新しい TCP セッションをスピンアップする必要があるときに実行されます。 たとえば、HTTP GET 要求または HTTP POST 要求に関するプロキシ認証が表示される場合があります。 トレースで要求を認証しているフレームを表示する場合は、'NTLMSSP Summary' 列を Netmon に追加し、 をフィルター処理します .property.NTLMSSPSummary。 認証にかかる時間を確認するには、Time Delta 列を追加します。

Netmon に列を追加するには:

1. [説明] などの列を右クリックします。
2. [ 列の選択] をクリックします。
3. 一覧で NTLMSSP の概要 と 時間差 を見つけて、[ 追加] をクリックします。
4. 新しい列を [説明 ] 列の前後に移動して、並べて読むことができます。
5. [OK] をクリックします。

列を追加しない場合でも、Netmon フィルターは機能します。 ただし、認証の段階を確認できれば、トラブルシューティングがはるかに簡単になります。

プロキシ認証のインスタンスを探す場合は、NTLM チャレンジまたは認証メッセージが存在するすべてのフレームを確認してください。 必要に応じて、特定のトラフィックを右クリックし、[会話 TCP の検索] > をクリックします。 これらの会話の Time Delta 値に注意してください。

Wiresharkに示されているように、プロキシ認証の 4 秒の遅延。 前に表示されたフレーム列からの時間差は、フレームの詳細で同じ名前のフィールドを右クリックし、[列として追加] を選択することで行われました。

DNS パフォーマンス

名前解決は、クライアントの国/地域にできるだけ近い場所で行われる場合に最適かつ最も迅速に機能します。

DNS の名前解決が海外で行われている場合、ページ読み込みには数秒を追加できます。 理想的には、名前解決は 100 ミリ秒以下で行われます。 そうでない場合は、さらに調査する必要があります。

ヒント

Office 365でのクライアント接続のしくみがわからない場合 ここでは、「クライアント接続リファレンス」ドキュメントを参照 してください。

ツール

• Netmon
• Wireshark
• PsPing

検索対象

通常、DNS パフォーマンスの分析は、ネットワーク トレースの別のジョブです。 ただし、PsPing は、考えられる原因の判断にも役立ちます。

DNS トラフィックは TCP 要求と UDP 要求に基づいており、応答には特定の要求とその特定の応答との照合に役立つ ID で明確にマークされます。 たとえば、SharePoint が Web ページでネットワーク名や URL を使用すると、DNS トラフィックが表示されます。 経験則として、ゾーンを転送する場合を除き、このトラフィックのほとんどは UDP 経由で実行されます。

Netmon と Wireshark の両方で、DNS トラフィックを確認できる最も基本的なフィルターは単純ですdns。 フィルターを指定するときは、必ず小文字を使用してください。 クライアント コンピューターで問題の再現を開始する前に、必ず DNS リゾルバー キャッシュをフラッシュしてください。 たとえば、ホーム ページの SharePoint ページの読み込みが遅い場合は、すべてのブラウザーを閉じ、新しいブラウザーを開き、トレースを開始し、DNS リゾルバー キャッシュをフラッシュし、SharePoint サイトを参照する必要があります。 ページ全体が解決されたら、トレースを停止して保存する必要があります。

ここでタイム オフセットを確認します。 また、次の手順を実行して実行できる [Time Delta ] 列を Netmon に追加すると便利な場合があります。

1. [説明] などの列を右クリックします。
2. [ 列の選択] をクリックします。
3. 一覧で Time Delta を見つけて、[ 追加] をクリックします。
4. 新しい列を [説明 ] 列の前後に移動して、並べて読むことができます。
5. [OK] をクリックします。

目的のクエリが見つかる場合は、フレームの詳細パネルでそのクエリを右クリックし、[ 会話>の検索 DNS] を選択して分離することを検討してください。 [ネットワーク会話] パネルは、UDP トラフィックのログ内の特定の会話に右にジャンプすることに注意してください。

Wiresharkでは、DNS 時間の列を作成できます。 Wiresharkでトレースを取得し(またはトレースを開く)、または でdnsフィルター処理します。より役にdns.time立ちます。 任意の DNS クエリをクリックし、詳細を表示するパネルで詳細を Domain Name System (response) 展開します。 時間のフィールドが表示されます (たとえば、 [Time: 0.001111100 seconds]など)。 今回は右クリックし、[ 列として適用] を選択します。 これにより、トレースの並べ替えを迅速に行う [時間 ] 列が表示されます。 新しい列をクリックして降順の値で並べ替え、解決に最も時間がかかった DNS 呼び出しを確認します。

(小文字) dns.time でWiresharkフィルター処理された SharePoint の参照。詳細からの時刻が列に作成され、昇順で並べ替えられます。

DNS 解決時間の詳細な調査を行う場合は、TCP で使用される DNS ポート (例: psping <IP address of DNS server>:53) に対して PsPing を試してください。 パフォーマンスの問題が引き続き発生しますか? その場合、問題は解決を行うために発生する特定の DNS アプリケーションの問題よりも広範なネットワークの問題である可能性が高くなります。 また、outlook.office365.com への ping を実行すると、Outlook Online の DNS 名解決が行われている場所 (たとえば、outlook-namnorthwest.office365.com) が表示されることにも言及する価値があります。

問題が DNS 固有である場合は、IT 部門に問い合わせて DNS 構成と DNS フォワーダーを確認して、この問題をさらに調査する必要がある場合があります。

プロキシのスケーラビリティ

Office 365の Outlook Online などのサービスは、クライアントに複数の長期的な接続を許可します。 したがって、各ユーザーは、より長い寿命を必要とするより多くの接続を使用する可能性があります。

ツール

数学

検索対象

これに固有のネットワーク トレースやトラブルシューティング ツールはありません。 代わりに、制限事項やその他の変数を指定した帯域幅の計算に基づいています。

TCP 最大セグメント サイズ

SYN - SYN/ACK にあります。 このチェックは、可能な限り最大量のデータを伝送するように TCP パケットが構成されていることを確認するために実行したパフォーマンス ネットワーク トレースで行います。

目標は、データの転送に 1,460 バイトの MSS を表示することです。 プロキシの背後にいる場合、または NAT を使用している場合は、クライアントからプロキシ/エグレス/NAT、プロキシ/エグレス/NAT から最適な結果を得るために、このテストを実行してOffice 365してください。 これらは異なる TCP セッションです。

ツール

Netmon

検索対象

TCP 最大セグメント サイズ (MSS) は、ネットワーク トレースの 3 方向ハンドシェイクのもう 1 つのパラメーターです。つまり、SYN - SYN/ACK パケットに必要なデータが見つかります。 MSS は見て非常に簡単です。

使用しているパフォーマンス ネットワーク トレースを開き、関心のある接続を見つけるか、パフォーマンスの問題を示します。

注:

トレースを見て、会話に関連するトラフィックを見つける必要がある場合は、クライアントの IP、またはプロキシ サーバーまたはエグレス ポイントの IP、またはその両方でフィルター処理します。 直接実行するには、トレース内のOffice 365の IP アドレスをテストしている URL に ping を実行し、その URL でフィルター処理する必要があります。

中古のトレースを見て? フィルターを使用して自分の向きを設定してみてください。 Netmon で、 などの Containsbin(framedata, ascii, "sphybridExample")URL に基づいて検索を実行し、フレーム番号をメモします。

Wiresharkで、 のようなものframe contains "sphybridExample"を使用します。 リモート Winsock (RWS) トラフィックが見つかった場合 (Wiresharkで [PSH, ACK] として表示される場合があります)、RWS 接続は、前述したように関連する SYN - SYN/ACK の直前に確認できることに注意してください。

この時点で、フレーム番号を記録し、フィルターを削除し、Netmon の [ネットワーク会話] ウィンドウで [すべてのトラフィック ] をクリックして、最も近い SYN を確認できます。

重要なのは、トレースの時点で IP アドレス情報を受信しなかった場合、トレース内の URL (例: の一部 sphybridExample-my.sharepoint.com) を見つけると、フィルター処理する IP アドレスが提供されます。

表示するトレース内の接続を見つけます。 これを行うには、トレースをスキャンするか、IP アドレスでフィルター処理するか、Netmon の [ネットワーク会話] ウィンドウを使用して特定の会話 ID を選択します。 SYN パケットが見つかったら、[フレームの詳細] パネルで [TCP (Netmon)] または [伝送制御プロトコル ] (Wireshark) を展開します。 [TCP オプション] と [MaxSegmentSize] を展開します。 関連する SYN-ACK フレームと [TCP オプションの展開] と [MaxSegmentSize] を見つけます。 2 つの値のうち小さい方が、最大セグメント サイズになります。 この図では、TCP トラブルシューティングと呼ばれる組み込みの Netmon 列を使用します。

組み込みの列は、[ フレームの詳細 ] パネルの上部にあります。 (通常のビューに戻すには、もう一度 [列 ] をクリックし、[ タイム ゾーン] を選択します)。

Wiresharkのフィルター処理されたトレースを次に示します。 MSS 値 (tcp.options.mss) に固有のフィルターがあります。 SYN、SYN/ACK、ACK ハンドシェイクのフレームは、フレームの詳細に相当するWiresharkの下部にリンクされます (そのため、フレーム 47 ACK、46 SYN/ACK へのリンク、43 SYN へのリンク)。

選択的受信確認 (このマトリックスの次のトピック) をチェックする必要がある場合は、トレースを閉じないでください。

選択的受信確認

SYN - SYN/ACK にあります。 SYN と SYN/ACK の両方で許可済みとして報告する必要があります。 選択的受信確認 (SACK) を使用すると、パケットまたはパケットが見つからない場合にデータをよりスムーズに再送信できます。 デバイスでこの機能を無効にすると、パフォーマンスの問題が発生する可能性があります。

プロキシの背後にいる場合、または NAT を使用している場合は、クライアントからプロキシ/エグレス/NAT、プロキシ/エグレス/NAT から最適な結果を得るために、このテストを実行してOffice 365してください。 これらは異なる TCP セッションです。

ツール

Netmon

検索対象

選択的受信確認 (SACK) は、SYN-SYN/ACK ハンドシェイクの別のパラメーターです。 SYN - SYN/ACK のトレースは、さまざまな方法でフィルター処理できます。

トレースをスキャンするか、IP アドレスでフィルター処理するか、Netmon の [ネットワーク会話] ウィンドウを使用して会話 ID をクリックして、目的のトレース内の接続を見つけます。 SYN パケットが見つかったら、[フレームの詳細] セクションの [Netmon で TCP] を展開するか、Wiresharkの [伝送制御プロトコル] を展開します。 [TCP オプション] を展開し、[SACK] を展開します。 関連する SYN-ACK フレームを見つけ、TCP オプションとその SACK フィールドを展開します。 SYN と SYN/ACK の両方で特定の SACK が許可されるようにします。 Netmon と Wireshark の両方で見られる SACK 値を次に示します。

DNS 位置情報

DNS 呼び出しを解決しようとする世界Office 365は、接続速度に影響します。

Outlook Online では、最初の DNS 参照が完了すると、その DNS の場所が最も近いデータセンターへの接続に使用されます。 Outlook Online CAS サーバーに接続します。このサーバーでは、バックボーン ネットワークを使用して、データが格納されているデータセンター (dC) に接続します。 これはより高速です。

SharePoint にアクセスすると、海外に旅行するユーザーは、アクティブなデータセンター (SPO テナントのホーム ベースに基づく dC) に移動します (米国ベースの場合は米国の dC)。

Lync Online には、一度に複数の dC にアクティブなノードがあります。 Lync オンライン インスタンスに対して要求が送信されると、Microsoft の DNS は、要求が送信された世界の場所を決定し、Lync オンラインがアクティブな最も近いリージョン dC から IP アドレスを返します。

ヒント

クライアントがOffice 365に接続する方法について詳しく知る必要がありますか? クライアント接続のリファレンス記事 (およびその役立つグラフィックス) を見てください。

ツール

• ping
• PsPing

検索対象

クライアントの DNS サーバーから Microsoft の DNS サーバーへの名前解決の要求では、ほとんどの場合、Microsoft DNS がリージョン データセンター (dC) の IP アドレスを返す必要があります。 これはどういう意味ですか? 本社がインドのベンガルールにあるが、米国で移動している場合、ブラウザーが Outlook Online の要求を行うとき、Microsoft の DNS サーバーは、米国のデータセンター (リージョン データセンター) に IP アドレスを渡す必要があります。 Outlook からメールが必要な場合、そのデータはデータセンター間で Microsoft のクイック バックボーン ネットワークを経由します。

DNS は、名前解決が可能な限りユーザーの場所の近くで行われる場合に最も速く機能します。 ヨーロッパにいる場合は、ヨーロッパの Microsoft DNS にアクセスし、(理想的には) ヨーロッパのデータセンターを取り扱う必要があります。 ヨーロッパのクライアントが DNS とアメリカのデータセンターにアクセスする場合、パフォーマンスは低下します。

outlook.office365.com に対して Ping ツールを実行して、DNS 要求がルーティングされている世界の場所を判断します。 ヨーロッパにいる場合は、outlook-emeawest.office365.com などの返信が表示されます。 アメリカ大陸では、outlook-namnorthwest.office365.com のようなものを期待してください。

クライアント コンピューターでコマンド プロンプトを開きます (Start > Run > cmd または Windows キー > の種類 cmd を使用)。 「ping outlook.office365.com」と入力し、Enter キーを押します。 IPv4 経由で ping を実行するように指定する場合は、-4 を指定してください。 ICMP パケットから応答を取得できない場合がありますが、要求がルーティングされた DNS の名前が表示されます。 この接続の待機時間番号を表示する場合は、ping によって返されるサーバーの IP アドレスに PsPing を試してください。

Office 365 アプリケーションのトラブルシューティング

ツール

• Netmon
• HTTPWatch
• ブラウザーの F12 コンソール

このネットワーク固有の記事では、アプリケーション固有のトラブルシューティングで使用されるツールについては説明しません。 ただし、このページで使用できるリソースが表示されます。

関連記事

Office 365 エンドポイントの管理

Office 365 エンドポイントの FAQ