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

重要:  この記事は機械翻訳されています。機械翻訳についての「免責事項」をお読みください。この記事の英語版を参照するには、ここをクリックしてください。

特定して解決より遅れて、停止する、および SharePoint Online、OneDrive for Business、Exchange Online、または Skype for Business Online、およびクライアント コンピューターのパフォーマンスが低下するための手順をご覧ください。サポートに連絡する前に、Office 365 のパフォーマンスの問題を解決してもの最も一般的な問題を修正をここに役立ちます。

この記事はサンプルのアクション プランで、発生しているパフォーマンスの問題に関する貴重なデータを取得するために使用できます。また、よくある問題もいくつか次に示します。

ネットワーク パフォーマンスを初めて利用し、クライアント マシンと Office 365 間でのパフォーマンスを長期間監視するように計画する場合は、「Office 365 performance tuning and troubleshooting - Admin and IT Pro (Office 365 パフォーマンスのチューニングとトラブルシューティング - 管理者および IT プロ)」を参照してください。

パフォーマンスのトラブルシューティングを行うサンプル プラン

このアクション プランは、準備フェーズとログ記録フェーズという 2 つの部分で構成されています。 パフォーマンスの問題が発生中であり、データ収集が必要な場合は、このプランの使用をすぐに開始できます。

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

  • パフォーマンスの問題を再現できるクライアント コンピューターを見つけます。 このコンピューターは、トラブルシューティング作業中に使用します。

  • パフォーマンスの問題が発生する原因になったステップを記録し、テストを行うときの準備を整えます。

  • 情報を収集および記録するためのツールをインストールします。

    • Netmon 3.4 をインストールします (または同等のネットワーク トレース ツールを使用します)。

    • 無料の HTTPWatch Basic Edition をインストールします (または同等のネットワーク トレース ツールを使用します)。

    • テスト中に実行するステップを記録するために、スクリーン レコーダーを使用するか Windows Vista 以降に付属しているステップ記録ツール (PSR.exe) を実行します。

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

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

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

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

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

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

  • オプション: Exchange Online をテストしている場合は、Office 365 管理コンソールから Exchange Client Performance Analyzer ツールを実行します。

  • パフォーマンスの問題の原因になった正確なステップを再現します。

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

  • コマンド ラインで、次のコマンドを入力して Enter キーを押し、Office 365 サブスクリプションまでの trace route (tracert) を実行します。

    tracert <subscriptionname>.onmicrosoft.com

  • ステップ記録ツールを停止し、動画を保存します。 キャプチャの日時を名前に含め、さらに良いパフォーマンスと悪いパフォーマンスのどちらを示したかも記録します。

  • トレース ファイルを保存します。 この名前にも、キャプチャの日時を含め、さらに良いパフォーマンスと悪いパフォーマンスのどちらを示したかも記録します。

この記事で紹介しているツールの実行方法がよくわからない場合でも、次に説明しますので心配する必要はありません。 この種類のネットワーク キャプチャに慣れている場合は、フィルター処理とログの読み取りについて説明している「トレースの読み取り方法」セクションをスキップできます。

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

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

DNS リゾルバー キャッシュをフラッシュします。

  1. コマンド プロンプトを開きます ([スタート]、[ファイル名を指定して実行] の順にクリックし、「cmd」と入力するか、Windows キーを押して、「cmd」と入力します)。

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

    ipconfig /flushdns

Netmon

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

この時点でフィルターを適用しないでください。 代わりに、トレースを停止して保存する前に、ステップを実行し、問題を実証します。

Netmon 3.4 をインストールした後で、ツールを開き、これらのステップを実行します。

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

  1. Netmon 3.4 を起動します。

    [開始] ページで 3 つのウィンドウがある:最近使用したキャプチャネットワークの選択]、および Microsoft ネットワーク モニター 3.4 の概要します。お知らせします。ネットワークの選択] パネル提供する一連の既定のネットワークをキャプチャすることができます。ネットワーク カードがここで選択されていることを確認します。

  2. スタート ページの上部にある [New Capture] をクリックします。 この操作を行うと、スタート ページのタブ横に [Capture 1] という新しいタブが追加されます。

    [新しいキャプチャ]、[開始]、および [停止] ボタンが強調表示された Nemon のユーザー インターフェイス

  3. 単純にキャプチャするには、ツールバーの [Start] をクリックします。

  4. パフォーマンスの問題を発生させるステップを再現します。

  5. [Stop]、[File]、[Save As] の順にクリックします。 タイムゾーンの日時を名前に含め、悪いパフォーマンスまたは良いパフォーマンスのどちらを示したかも記述します。

HTTPWatch

HTTPWatchが呼び出されます充電、無料のエディションとします。無料の基本的なエディションでは、このテストに必要なすべてのアイテムについて説明します。ブラウザー ウィンドウの右からのネットワーク トラフィックとページの読み込み時間を HTTPWatch の監視します。HTTPWatch は、プラグイン Internet Explorer を視覚的にパフォーマンスを説明します。分析を保存し、HTTPWatch Studio で表示します。

注記: 

  • Firefox、Google Chrome などの別のブラウザーを使用している場合、または HTTPWatch を Internet Explorer にインストールできない場合は、新しいブラウザー ウィンドウを開いて、F12 キーを押します。 ブラウザーの下部に Developer Tool ポップアップが表示されます。 Opera を使用している場合は、Ctrl + Shift + I を押して Web Inspector を起動し、[Network] タブをクリックして、以下に概要を示すテストを実行します。 実際の情報は少し異なりますが、読み込み時間は同じようにミリ秒単位で表示されます。

  • HTTPWatch は、SharePoint Online のページ読み込み時間の問題を解決する場合も非常に役に立ちます。

HTTPWatch を実行し、問題を再現

  1. HTTPWatch は、ブラウザー プラグインであり、Internet Explorer のバージョンによってブラウザー内に表示されるツールが少し異なります。 一般的に、HTTPWatch は、Internet Explorer ブラウザーのコマンド バーの下に表示されます。

    HTTPWatch プラグインがブラウザー ウィンドウに表示されない場合は、[ヘルプ]、[バージョン情報] の順にクリックするか、新しいバージョンの Internet Explorer では、歯車記号をクリックし、[バージョン情報] をクリックして、ブラウザーのバージョンを確認してください。 コマンド バーを起動するには、Internet Explorer でメニュー バーを右クリックし、[コマンド バー] をクリックします。 以前は、HTTPWatch はコマンド バーとエクスプローラー バーの両方に関連付けられていたので、インストールした後にアイコンがすぐに表示されない場合 (再起動の後でも表示されない場合) は、[ツール] を確認し、ツールバーでアイコンを確認できます。 ツールバーはカスタマイズ可能であり、オプションを追加できます。

    HTTPWatch アイコンが表示された Internet Explorer のコマンド ツール バー。

  2. Internet Explorer ブラウザー ウィンドウで HTTPWatch を起動します。 ブラウザー ウィンドウの下部にドッキングされて表示されます。 [Record] をクリックします。

  3. パフォーマンスの問題に関係する正確なステップを再現します。 HTTPWatch の [Stop] ボタンをクリックします。

  4. HTTPWatch を保存するかメールで送信します。 ファイルに日時情報が含まれる名前を付け、Watch で良いパフォーマンスまたは悪いパフォーマンスのどちらが含まれるかを記述します。

    Office 365 ホームページのページ読み込み用 [ネットワーク] タブを表示する HTTPWatch。

    このスクリーン ショットは、Professional バージョンの HTTPWatch の画面です。 Professional バージョンがインストールされたコンピューターで Basic バージョンで取得されたトレースを開いて読むことができます。 この方法でトレースから追加の情報を利用できる場合があります。

問題ステップ記録ツール

ステップ記録ツール (PSR.exe) を使用すると、発生している問題を記録できます。 これは非常に役に立つツールで、簡単に実行できます。

問題ステップ記録ツール (PSR.exe) を作業を記録を実行します。

  1. [スタート]、[ファイル名を指定して実行] の順にクリックし、「PSR.exe」と入力して [OK] をクリックするか、Windows キーを押して、「PSR.exe」と入力し、Enter キーを押します。

  2. 小さな PSR.exe ウィンドウが表示されたら、[記録の開始] をクリックして、パフォーマンスの問題を再現するステップを再現します。

    [コメントの追加] をクリックして、必要に応じてコメントを追加することができます。

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

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

ステップ記録ツールまたは PSR.exe のスクリーンショット

日付と時刻が記録されます。これにより、HTTPWatch、Netmon トレース時間] で、PSR にリンクし、設定できない正確なトラブルシューティングに役立ちます。日付と時刻の PSR レコードの時刻の分が渡されることを表示できます間ログイン情報と URL と管理、サイトの部分のレンダリングの例を参照します。

トレースを読み解く

ネットワークとパフォーマンスのトラブルシューティングについて必要なすべての知識を、記事で伝えることはできません。 パフォーマンスを向上させるには、ネットワークの仕組みと通常の動作に関する経験と知識が必要です。 しかし、重要な問題のリストを作成し、ツールを使用して最も一般的な問題を簡単に排除する方法を示すことはできます。

Office 365 サイトのネットワーク トレースの読み取りのスキルを選ぶ場合は、ページの読み込みのトレースを定期的に作成し、読むエクスペリエンスを得るより良い教師はありません。たとえば、可能性がある場合を Office 365 のサービスを読み込むし、プロセスをトレースします。DNS トラフィックの場合は、トレースをフィルター処理するか、参照するサービスの名前の FrameData を検索します。サービスの読み込み時に発生する手順の理解するためのトレースをスキャンします。これによって、どのような標準の学習ページの読み込みのようになります、パフォーマンス、特に関連のトラブルシューティング] の場合は悪いの適切なトレースを比較することについて説明する多くします。

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

[表示フィルター] フィールドでの IntelliSense の使用を示す Netmon のスクリーンショット。

Netmon トレースに大量のトラフィックことができます。読み取りと経験豊富な場合は、トレースを初めて開くとまどったりする可能性があります。最初には、トレースでバック グラウンドの雑音シグナルを区別します。Office 365 の比較と、トラフィックを表示したいなります。トレース内を移動することを使用する場合は、このリストされない必要があります。

クライアントと Office 365 の間のトラフィックは TLS を使用して送信されます。つまり、トラフィックの本文は暗号化され、汎用の Netmon トレースでは読むことができません。 パフォーマンス分析では、パケット内の情報を具体的に知る必要はありません。 ただし、パケットのヘッダーおよびそれらに含まれる情報は非常に重要です。

効果的なトレースを取得するためのヒントします。

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

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

  • 取り込み中トレースで使用している Office 365 サービスを見つけます。前に、トラフィックをまたはほとんどしないで表示した場合他のネットワーク ノイズからパフォーマンスの問題を区別するときに役に立つ手順です。この作業にいくつかの方法があります。テストする前に直接 ping、または (ping outlook.office365.compsping -4 microsoft-my.sharepoint.com:443、たとえば) は、特定のサービスの url の PsPing を使用できます。簡単に見つかる Netmon のトレース (プロセス名前) を使用してその PsPing します。検索を開始する場所が提供されます。

    問題が発生したときに Netmon トレースのみを使用していた場合も問題はありません。 作業の方向性を定めるには、ContainsBin(FrameData, ASCII, "office")ContainsBin(FrameData, ASCII, "outlook") などのフィルターを使用します。 トレース ファイルからフレーム番号を記録できます。 [Frame Summary] ウィンドウを右端までスクロールして、Conversation ID 列を見つけることができます。 この列にはこの特定のメッセージ交換の ID を示す数値が表示されており、記録して、後で問題を特定するときに参照できます。 他のフィルターを適用する前に必ずこのフィルターを削除してください。

    ヒント: Netmon には、数多くの役に立つ組み込みフィルターが用意されています。 [Display Filter] ウィンドウの上部にある [Load Filter] ボタンを試してください。

    クライアント コンピューターでコマンドラインに PSPing を指定して、IP アドレスを見つける。

    フィルターに TCP.Flags.Syn == 1 を設定して同じ PSPing コマンドを実行したクライアントの Netmon トレース結果

    トラフィックを詳しく理解し、必要な情報を見つける方法を学習してください。 たとえば、使用している Office 365 サービス ("Outlook" など) を最初に参照するパケットをトレース内で特定する方法を学習します。

たとえば Office 365 Outlook Online の場合、トラフィックの最初の部分は次のようになります。

  • 一致する QueryID を含む、outlook.office365.com に対する DNS Standard Query および DNS Response。 このターンアラウンドの Time Offset (時間のオフセット)、および Office 365 Global DNS が名前解決の要求を送信している場所をメモすることが重要です。 地球の反対側ではなく地域的に近いことが理想的です (この後にいくつかのオンライン ログインの DNS トラフィックが続くことがあります)。

  • ステータス レポートが Moved Permanently (301) になっている HTTP GET 要求。

  • RWS 接続要求と接続の返信を含む RWS トラフィック (これは接続を実行している Remote Winsock です)。

  • TCP SYN と TCP SYN-ACK 会話です。このスレッドの設定の多くは、自分のパフォーマンスに影響します。

  • 次に、TLS ハンドシェイクと TLS 証明書のメッセージ交換が実行される一連の TLS:TLS トラフィックが続きます (データは SSL/TLS で暗号化されます)。

トラフィックのすべての部分は重要であり、つながりがありますが、トレースのわずかな部分に、パフォーマンスのトラブルシューティングに関して特に重要な情報が含まれているので、それらの領域を中心に説明します。 さらに、Microsoft で Office 365 のパフォーマンスのトラブルシューティングを十分に行い、重要な一般的な問題のリストを作成しているので、次にそれらの問題および原因を特定するためのツールの使用方法に重点を置いて説明します。

それらのツールをまだインストールしていない場合は、下の表のいくつかのツールを使用してください。可能な場合は、インストール元の場所へのリンクを示しています。この一覧には、NetmonWireshark などの一般的なネットワーク トレース ツールが記載されていますが、ネットワーク トラフィックのフィルター処理に使い慣れた好みのツールがあればそちらを使用してください。テスト時の注意事項を次に説明します。

  • ブラウザーを閉じてテストを実行しているブラウザーを 1 つの全体的なトラフィックをキャプチャする低きます。混雑の少ないトレースを取得して使用するとします。

  • クライアント コンピューターで DNS リゾルバー キャッシュをフラッシュします。- この操作を行うと、クリーンな状態でキャプチャを開始してクリーンなトレースを取得できます。

よくある問題

よくある問題と、ネットワーク トレースで検索する方法について説明します。

重要な問題

ツール

探している情報

TCP ウィンドウのスケーリング

  • SYN - SYN/ACK の情報でわかります。

  • 以前の旧式のハードウェアでは、TCP ウィンドウのスケーリングを利用できない場合があります。

  • 適切な TCP ウィンドウのスケーリングが設定されていない場合、TCP ヘッダー内の既定の 16 ビット バッファーがミリ秒単位で設定されます。

  • 元のデータが受信されたことを示す確認応答をクライアントが受信するまで、トラフィックを継続的に送信できないため、待機時間が発生する原因となります。

Netmon

Wireshark

ネットワーク トレースで SYN - SYN/ACK トラフィックを探します。

Netmon では、 tcp.flags.syn == 1のようにフィルターを使用します。このフィルターは、Wireshark で同じです。

Netmon または Wireshark の両方のツールに TCP.Flags.Syn == 1 を指定して Syn パケットをフィルター処理する。

すべての SYN で、関連する確認応答の接続先ポート (DstPort) と一致する接続元ポート (SrcPort) 番号があります。

ネットワーク接続で使用されているウィンドウ スケーリング値を表示するには、まず SYN を、次に関連する SYN/ACK を展開します。

トレースで SrcPort を DstPort に一致させて、タイム デルタ値を取得する方法を示した画像。

TCP アイドル時間設定

  • 従来、ほとんどの境界ネットワークは一時的な接続用として構成されているため、通常はアイドル接続が終了します。

  • アイドルの TCP セッションは、100 ~ 300 秒を超えた時点でプロキシやファイアウォールによって終了される可能性があります。

  • Outlook Online にとっては、この処理が問題になります。Outlook Online では、接続がアイドルかどうかに関係なく、長期間の接続を作成して使用するからです。

  • クライアントに対しては、接続がプロキシやファイアウォールによって終了されたことが通知されないため、クライアント コンピューターでは、Outlook Online を使おうとするとき、新しい接続を作成する前に、以前の接続をもう一度使用しようとします。

  • そのせいで製品がハングしたり、プロンプトが表示されたり、ページの読み込みが遅くなったりすることがあります。

Netmon

Wireshark

Netmon の [Time Offset] フィールドでラウンドトリップを調べます。 ラウンドトリップは、クライアントが要求をサーバーに送信してから戻ってきた応答を受信するまでの時間です。 クライアントから出口ポイントまでの間 ( クライアント --> プロキシなど) またはクライアントから Office 365 まで (クライアント --> Office 365) を確認します。 この組み合わせはさまざまな種類のパケットで見られます。

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

ヒント: 

  • トレースに含まれる IP アドレスが自分の DNS サーバーのものかどうかが不明な場合は、 コマンド ラインで検索してみてください。 スタート メニューで [ファイル名を指定して実行] をクリックして「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 Official SitePingtest などのサイトを試してみてください。

Ping

PsPing

Netmon

Wireshark

トレースで待機時間を追跡する場合は、クライアント コンピューターの IP アドレスと Office 365 の DNS サーバーの IP アドレスを控えておくと便利です。 こうしておくと、トレースにフィルターをかけやすくなります。 プロキシ経由で接続する場合は、クライアント コンピューターの IP アドレス、プロキシの IP アドレス、出口の IP アドレス、Office 365 DNS の IP アドレスを控えておくと、作業しやすくなります。

outlook.office365.com に送信された ping 要求からは、ping が接続してその特徴的な連続 ICMP パケットを送信できなかった場合でも、要求を受信したデータセンターの名前がわかります。 PsPing (無料でダウンロードできるツール) で特定のポート (443) と IPv4 (-4) を使用すると、送信されたパケットの平均ラウンドトリップ時間がわかります。 この測定は、Office 365 サービスの他の URL に対しても、たとえば「psping -4 yourSite.sharepoint.com:443」のように指定して使用できます。 さらに、「psping -4 -n 20 yourSite-my.sharepoint.com:443」のように入力して、ping の実行回数を指定して平均計算に使用するサンプル数を増やすこともできます。

注: PsPing は ICMP パケットを送信しません。 その代わり、TCP パケットを使用して特定のポート経由で ping を実行するので、開いていることがわかっている任意のポートを使用できます。 Office 365 では SSL/TLS を使用するので、ポート 443 を PsPing に接続してみてください。

outlook.office365.com を解決する Ping、同じことを実行する 443 が指定された PSPing を表しているスクリーン ショットで、6.5 ミリ秒の平均 RTT も報告されています。

ネットワーク トレースの実行中に処理の遅い Office 365 ページを読み込んだ場合は、Netmon や Wireshark のトレースに対して「DNS」でフィルターをかけます。 これが調べている IP の 1 つです。

ここでは、Netmon でフィルターをかけて IP アドレスを見つける (そして DNS の待機時間を確認する) 手順を説明します。 この例では outlook.office365.com を使用しますが、SharePoint Online テナント (hithere.sharepoint.com など) の URL も使用できます。

  1. URL ping outlook.office365.com に対して ping を実行し、その結果から、ping 要求の送信先の DNS サーバーの名前と IP アドレスを控えます。

    namnorthwest の DNS と IP アドレスを表示するために outlook.office365.com への Ping 要求を行う。

  2. ネットワーク トレースのページを開くまたはアクションを実行では、パフォーマンスの問題、または、ping 自体の待機時間が長いを表示する場合ネットワーク トレースします。

  3. 実行したトレースを Netmon で開き、「DNS」でフィルターをかけます (このフィルターは Wireshark でも機能しますが、「dns」のように大文字を小文字にします)。 ping の結果から DNS サーバー名がわかっているので、Netmon で「DNS AND ContainsBin(FrameData, ASCII, "namnorthwest")」のように指定して簡単にフィルターをかけることもできます。Wireshark では「dns and frame contains "namnorthwest"」のように指定します。

    応答パケットを開き、Netmon の [Frame Details] ウィンドウで [DNS] をクリックして展開し、詳細情報を表示します。 その DNS 情報から、Office 365 で要求の送信先となった DNS サーバーの IP アドレスがわかります -- この IP アドレスが次の手順 (PsPing ツール) で必要となります。 フィルターを削除し、Netmon の [Frame Summary] で DNS 応答を右クリックし、[Find Conversations] の [DNS] を選んで、DNS のクエリと応答を並べて表示します。

    [スレッドの検索]、[DNS] の順でフィルター処理されたトレース。

  4. Netmon で、DNS の要求から応答までの間の [Time Offset] 列にも注目します。

    DNS AND CONTAINSBIN(Framedata, ASCII, "namnorthwest") を指定してフィルター処理されたその他の Netmon 結果 - リクエストから応答までのタイム オフセット値がきわめて低い。

次の手順でPsPingツールを使用して、簡単にインストールで役に立つ非常に、両方 ICMP が多くの場合、ファイアウォールでブロックされているため、PsPing 洗練された方法待機時間 (ミリ秒) を追跡します。PsPing をアドレスとポート (で、大文字と小文字開いているポート 443) への TCP 接続を完了します。

  1. PsPing をインストールします。

  2. コマンド プロンプトを開き (スタート メニューの [ファイル名を指定して実行] で「cmd」と入力するか、または Windows キーを押し、「cmd」と入力します)、PsPing のインストール ディレクトリに移動し、PsPing コマンドを実行します。 図からわかるように、この例では C ドライブのルートに Perf というフォルダーが作成されています。 同じようにすると、アクセスが簡単になります。

  3. コマンドを入力し、前に Netmon トレースで取得した Office 365 の DNS サーバーの IP アドレスに対して PsPing を実行します -- ポート番号を忘れずに追加してください。 つまり、「psping -n 20 132.245.24.82:445」のように入力します。 20 回の ping 実行がサンプリングされ、PsPing が停止したときの待機時間の平均がわかります。

    PSPing コマンド psping -n 20 132.245.24.82:443 の実行結果として平均待機時間の 25.51 ミリ秒が返されます。

Office 365 にプロキシ サーバー経由でアクセスしている場合は、手順が若干異なります。 まず、プロキシ サーバーに対して PsPing を実行して、プロキシまたは出口に届いて戻ってくるまでの平均待機時間の値をミリ秒単位で取得し、次にプロキシ上かインターネットに直接接続されているコンピューター上で PsPing を実行して、求める (Office 365 に届いて戻ってくるまでの) 値を算出します。

PsPing をプロキシから実行する場合は、クライアント コンピューターからプロキシ サーバーまたは出口ポイント、およびプロキシ サーバーから Office 365 までの値が 2 ミリ秒となります。 これで完了です。 この値を記録しておきます。

PsPing をインターネットに直接接続されている別のクライアント コンピューターで実行する場合は、プロキシ、せずにする必要があるミリ秒の 2 つの値: プロキシ サーバーまたは出口ポイントとクライアント コンピューターに Office 365 にクライアント コンピューター。この例では、クライアント コンピューターの値をプロキシ サーバーまたは出口ポイントに、Office 365 にクライアント コンピューターの値から減算し、必要があります RTT 番号、クライアント コンピューターから出口ポイント、またはプロキシ サーバーにし、プロキシ サーバーまたは出口ポイントから Office 365 にします。

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

待機時間、Netmon のトレース] に表示されている、余分な数ミリ秒が積み重なって、な任意指定のセッションがある場合。

Netmon の既定の [タイム デルタ] 列を [フレーム サマリー] に追加したときの一般的な待機時間。

注: 実際の IP アドレスは図に示されている IP と異なることがあります。たとえば、ping に対して 157.56.0.0/16 やこれに近い範囲のアドレスが返されることがあります。 Office 365 で使用されている範囲の一覧については、「Office 365 の URL と IP アドレスの範囲」を参照してください。 たとえば、132.245 を検索したい場合は、すべてのノードを展開してください (そのためのボタンが最上部にあります)。

プロキシ認証

  • プロキシ サーバー経由の場合にのみ該当します。 該当しない場合、この手順は省略できます。

  • 適切に機能していれば、プロキシ認証には必ず数ミリ秒かかります。 使用率がピークを迎える時間中などに低いパフォーマンスが断続的に見られることは、本来ならありません。

  • プロキシ認証がオンの場合、情報を取得するために Office 365 への新しい TCP 接続を作成するたびに、背後で認証プロセスを経由する必要があります。 このため、たとえば Outlook Online で予定表からメールに切り替えるときに、認証が行われます。 また、SharePoint Online では、1 つのページに複数のサイトや場所からのメディアやデータが表示される場合に、データのレンダリングに必要な異なる TCP 接続それぞれに対して認証が行われます。

  • そのため、Outlook Online で予定表とメールボックスを切り替えるたびに読み込みが遅くなったり、SharePoint Online でページの読み込みに時間がかかったりします。 ただし、現象は他にもあります。

    プロキシ認証は、[出口プロキシ サーバー設定です。により、Office 365 でパフォーマンスの問題が発生する場合は、ネットワーク チームを参照する必要があります。

Netmon

Wireshark

プロキシ認証が行わたびに、新しい TCP セッションは、サーバーからファイルや情報を要求するには、通常、または情報を指定する、スピンする必要があります。たとえば、HTTP GET または HTTP 投稿に関するプロキシ認証を表示することがあります。フレームのトレースで要求を認証するかを確認するには場合、は、Netmon と.property.NTLMSSPSummaryのフィルターに NTLMSSP 要約列を追加します。認証にどのくらい時間がかかるを表示するには、タイム デルタ] 列を追加します。Netmon に列を追加します。

  1. [Description] などの列を右クリックします。

  2. [Choose Columns] をクリックします。 表示される一覧で [NTLMSSP Summary] や [Time Delta] を選び、[Add] をクリックします。

  3. 新しい列を [Description] 列の前か次に移動し、並んで表示されるようにします。 [OK] をクリックします。

列を追加しない場合でも、Netmon のフィルターが有効です。簡単になっている認証のどの段階を表示する場合は、トラブルシューティングになります。プロキシ認証のインスタンスが NTLM チャレンジ、またはメッセージの認証は、すべてのフレームを分析することを確認するが含まれています。必要に応じて、トラフィックと検索の会話の特定の部分を右クリックして > TCP します。これらの会話でタイム デルタ値を把握します。

スレッドでフィルター処理されたプロキシ認証を示す Netmon のトレース

下の図では、Wireshark のプロキシ認証で 4 秒の遅延が表示されています。 [Time delta from previous displayed frame] 列は、フレーム詳細で同じ名前のフィールドを右クリックし、[Add as Column] を選んで追加されています。

Wireshark で、[Time delta from previous displayed frame] 列は、フレーム詳細で同じ名前のフィールドを右クリックし、[Add as Column] を選んで追加されています。

DNS パフォーマンス

  • 名前解決が最適かつ最速に機能するのは、クライアントの所在国にできるだけ近い場所で処理された場合です。

  • DNS 名の解決が国外で処理される場合、ページの読み込みに数秒間余計にかかることがあります。

  • 名前解決は 100 ミリ秒未満で完了するのが理想的です。 これより時間がかかる場合は、詳しい調査が必要です。

ヒント: クライアント接続における Office 365 の動作がわからない場合は、 こちらでクライアント接続に関するリファレンス ドキュメントを参照してください。

Netmon

Wireshark

PsPing

DNS パフォーマンスの分析は、ネットワーク トレースでよく行われる作業の 1 つです。 ただし、PsPing も使用して、考えられる原因を挙げたり排除したりすることもできます。

DNS は TCP 要求や UDP 要求をベースにしており、応答には ID が明記されているので、特定の要求と応答を対応付けるのに役立ちます。 DNS トラフィックは、たとえば SharePoint Online が Web ページ上でネットワーク名またはネットワーク URL を使用する場合に見られます。 原則的に、このトラフィックのほとんどは、ゾーン転送の場合を除き、UDP 経由で実行されます。

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

Netmon では DNS の基本フィルターは DNS です。

ここでのオフセット時に検索するにはします。することができるように次の手順を実行して Netmonタイム デルタ] 列を追加すると便利なポイントがある可能性があります。

  1. [Description] などの列を右クリックします。

  2. [Choose Columns] をクリックします。

  3. 表示される一覧で [Time Delta] を選び、[Add] をクリックします。

  4. 新しい列を [Description] 列の前か次に移動し、並んで表示されるようにします。 [OK] をクリックします。

興味のあるクエリを検索する場合は、フレーム詳細パネルで、スレッドの検索]を選択するには、そのクエリを右クリックしてを分離することを検討してください > DNSします。ネットワークでの会話のパネルが UDP トラフィックの特定の会話をログに記録する権利にジャンプすることを確認します。

DNS でフィルターされた Outlook Online の読み込みの Netmon トレース結果を [会話を探す]、[DNS] の順に選んで絞り込んだ状態。

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

Wireshark で (小文字の) dns.time を指定してフィルター処理された SharePoint Online の結果 - 詳細情報の時刻を昇順に並べ替えて列に表示。

DNS 解決の時間の他の調査を実行したい場合は、TCP (たとえば、 psping <IP address of DNS server>:53) によって使用される DNS ポートに対して PsPing を試してください。パフォーマンスの問題が引き続き発生するかその場合は、問題が解決のために到達している DNS アプリケーション固有の問題より広範なネットワークを発行する方がします。意味がも、もう一度こと outlook.office365.com に対して ping するが示されている Outlook Online 用の DNS 名前解決が行われて (たとえば、outlook の namnorthwest.office365.com)。

DNS そのものの問題と思われる場合は、IT 部門に連絡して、DNS 構成や DNS フォワーダーを対象にこの問題をさらに詳しく調べる必要があります。

プロキシの拡張性

  • Office 365 の Outlook Online のようなサービスでは、クライアントが複数の長期接続を使用できるようになっています。

  • このため、各ユーザーが長時間接続を多く使用すると考えられます。

ヒント: 今後、Office 365 に多数のユーザーを追加するため、帯域幅の使用計画を立てる必要がある場合は、 「Office 365 向けインターネット帯域幅の使用計画」を参照してください。 帯域幅計算ツールにアクセスできます。

計算

専用のネットワーク トレース ツール、トラブルシューティング ツールはありません。 その代わり、制限事項などの要因に基づく帯域幅計算がベースとなります。

TCP の最大セグメント サイズ (MSS)

  • SYN - SYN/ACK の情報からわかります。

  • パフォーマンス ネットワーク トレースを取得したら MSS をチェックし、TCP パケットが最大限のデータを転送できるように構成されていることを確認してください。

  • 目標としては、MSS がデータ転送用に 1460 バイトに指定されていることを確認します。

  • プロキシの背後にいる場合、または NAT を使用している場合は、このテストをクライアントからプロキシ、出口、NAT まで、およびプロキシ、出口、NAT から Office 365 まで実行すると、最適な結果を得られます。 これらは異なる TCP セッションです。

Netmon

TCP 最大セグメント サイズ (MSS) は、別のパラメーターを SYN -/ACK SYN パケットで必要なデータが表示されますが、ネットワーク トレースでスリーウェイハンドシェイクのです。MSS が実際に表示する簡単です。

取得した任意のパフォーマンス ネットワーク トレースを開き、関心のある接続またはパフォーマンスの問題を示している接続を探します。

注記: 

  • トレースが表示されている状態で会話に関連するトラフィックを探す場合は、クライアントの IP か、プロキシ サーバーまたは出口ポイントの IP か、この両方でフィルターをかけます。 直接アクセスの場合は、テストしている URL に対して ping を実行し、トレースで Office 365 の IP アドレスを見つけ、それを使ってフィルターをかける必要があります。

  • 中古トレースで必要な場合自分の方向にフィルターを使ってみてください。Containsbin(framedata, ascii, "sphybridExample")] など、URL に基づいて検索を実行して、Netmon の点に注意フレーム数。Wireshark では、 frame contains "sphybridExample"のようなものを使用します。リモート Winsock (RWS) のトラフィック (Wireshark で、[PSH、ACK] と表示がいます) を検出したことに気付いた場合 RWS が接続できないことに注意してください説明したように関連する SYN - SYN/Ack の直前に表示されます。この時点では、できるフレームの番号を記録、フィルターを削除、すべてのトラフィックを最も近い SYN. 見て Netmon のネットワークでの会話ウィンドウでをクリックして

  • 重要な点として、トレース期間に IP アドレス情報を何も受信しなかった場合は、トレースで自分の URL (たとえば sphybridExample-my.sharepoint.com の一部) を見ると、フィルターで使用できる IP アドレスがわかります。

  1. 表示する接続をトレースで探します。 探し方としては、トレースを上から順に見ていく、IP アドレスでフィルターをかける、Netmon の [Network Conversations] ウィンドウで特定の会話 ID を選ぶ、などがあります。

    スレッドでフィルター処理しています。 SYN フレームを右クリックして、[スレッドの検索]、[TCP] の順にクリックします。

  2. SYN パケットが見つかったら、[Frame Details] パネルで [TCP] (Netmon の場合) または [Transmission Control Protocol] (Wireshark の場合) を展開します。

  3. [TCP Options]、[MaxSegementSize] の順に展開します。

  4. 関連 SYN-ACK フレームを探し、[TCP Options]、[MaxSegementSize] の順に展開します。

  5. 2 つの値の小さいほうが最大セグメント サイズです。

この図で、TCP Troubleshoot] という Netmon の組み込み列を使用します。

組み込み列を使用してネットワーク モニターでフィルター処理されたネットワーク トレース

この組み込み列には [Frame Details] パネルの最上部からアクセスできます (標準の表示に戻すには、[Columns] をもう一度クリックして、[Time Zone] を選びます)。

[TCP トラブルシューティング] オプション ([フレーム サマリー] の上部) の [列] ドロップ ダウンの場所。

Wireshark でフィルター処理されたトレースを示します。フィルターが MSS (tcp.options.mss) の値を特定します。フレームの詳細と同じ Wireshark の下部にある SYN、SYN-ACK/ACK ハンドシェイク、フレームが関連付けられた (47 ACK、46 SYN-ACK へのリンク、43 SYN へのリンク、フレーム) このような作業を容易にします。

tcp.options.mss で最大セグメント サイズ (MSS) を指定してフィルター処理された Wireshark のトレース結果。

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

選択的確認応答

  • SYN - SYN/ACK の情報からわかります。

  • SYN と SYN/ACK の両方で Permitted とレポートされる必要があります。

  • 選択的確認応答 (SACK) を使用すると、パケットが失われた場合にデータの再転送がよりスムーズになります。

  • デバイスではこの機能を無効にできるため、これが原因でパフォーマンスの問題が発生することがあります。

  • プロキシの背後にいる場合、または NAT を使用している場合は、このテストをクライアントからプロキシ、出口、NAT まで、およびプロキシ、出口、NAT から Office 365 まで実行すると、最適な結果を得られます。 これらは異なる TCP セッションです。

Netmon

選択的確認応答 (SACK) は、SYN-SYN/ACK ハンドシェイクのパラメーターの 1 つです。 トレースで SYN - SYN/ACK のフィルターをかける方法はいろいろあります。

  1. トレースを上から順に見ていく、IP アドレスでフィルターをかける、Netmon の [Network Conversations] ウィンドウで特定の会話 ID を選ぶ、などで関心のある接続をトレースで探します。

  2. SYN パケットが見つかったら、Netmon で TCP] または [Transmission Control Protocol wireshark の対応する [Frame Details] セクションを展開します。

  3. [TCP Options]、[SACK] の順に展開します。

  4. 関連する SYN-ACK フレームを探し、[TCP Options]、[SACK] の順に展開します。

  5. 一部の SACK が SYN と SYN/ACK の両方で許可されていることを確認します。

下の図に、Netmon と Wireshark に表示された SACK 値を示します。

Netmon で tcp.flags.syn == 1 の実行結果として表示された SACK (Selective ACKnowledgment)

フィルターに tcp.flags.syn == 1 を設定して Wireshark に表示された SACK

DNS 位置情報

  • 接続速度は、Office 365 が DNS 呼び出しの解決を世界のどこで処理しようとするかによって影響を受けます。

  • Outlook Online では、最初の DNS 参照が完了すると、その DNS の場所を使って最も近いデータセンターと接続します。 Outlook Online CAS サーバーのどれかに接続され、そのサーバーがバックボーン ネットワークを使ってユーザーのデータが格納されているデータセンター (dC) と接続します。 このようにすると、比較的速い接続が実現されます。

  • SharePoint Online に接続する場合、世界中を移動するユーザーは対応するアクティブ データセンターに転送されます。アクティブ データセンターとは、SPO テナントの本拠に基づく場所にある dC です (よって、ユーザーの本拠がアメリカならアメリカの dC になります)。

  • Lync Online は、一度に複数の dC にアクティブ ノードを持ちます。 要求が Lync Online インスタンスから送信されると、Microsoft の DNS はその要求が世界のどこから来たかを判定し、Lync Online がアクティブになっている最も近い地域 dC から IP アドレスを返します。

ヒント: クライアントが Office 365 に接続される仕組みの詳細については、 「クライアント接続」の参照記事 (とわかりやすいグラフィック) を参照してください。

Ping

PsPing

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

DNS が最速で機能するのは、名前解決がユーザーの所在地にできるだけ近い場所で処理された場合です。 ヨーロッパにいるなら、ヨーロッパの Microsoft DNS に接続され、(理想的には) ヨーロッパに存在するデータセンターで処理される、というのが望ましい状況です。 ヨーロッパにいるクライアントがアメリカにある DNS とデータセンターにアクセスすると、処理が遅くなります。

Ping ツールを outlook.office365.com に対して実行して、DNS 要求が世界のどこへ転送されているかを判定します。 ヨーロッパにいる場合は、outlook-emeawest.office365.com のような応答が表示されます。 南北アメリカの場合は、outlook-namnorthwest.office365.com のような応答が表示されます。

  1. クライアント コンピューターでコマンド プロンプトを開きます (スタート メニューの [ファイル名を指定して実行] に「cmd」と入力するか、または Windows キーを押して「cmd」と入力します)。

  2. ping outlook.office365.com」と入力して、Enter キーを押します。

    ただし、IPv4 経由で ping を指定する場合は、 -4を指定します。ICMP パケットからの返信を取得できない場合がありますが、[DNS の要求のルーティング先の名前が表示されます。

この接続の待機時間の数値を確認したい場合は、ping で返されたサーバーの IP アドレスに対して PsPing を実行します。

outlook-namnorthwest の名前解決を表示するために outlook.office365.com に対して Ping を実行する。

平均 28 ミリ秒の待ち時間を示す outlook.office365.com への Ping によって返された IP アドレスに対する PSPing

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

Netmon

HTTPWatch

IE の F12 開発者ツールのコンソール

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

関連トピック

Office 365 の端点を管理する
のトラブルシューティング Office 365 の接続

注: 機械翻訳についての免責事項: この記事の翻訳はコンピューター システムによって行われており、人間の手は加えられていません。マイクロソフトでは、英語を話さないユーザーがマイクロソフトの製品、サービス、テクノロジに関するコンテンツを理解するのに役立てるため、こうした機械翻訳を提供しています。記事は機械翻訳されているため、用語、構文、文法などに誤りがある場合があります。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×