配信の最適化について #1 概要篇

Last Update: feedback 共有

※本記事はマイクロソフト社員によって公開されております。
※この記事は過去に作成され、公開された記事を再編したものです。


2017/12/12 更新 - 「ポート要件」に記載した URL の情報を更新しました。

みなさま、こんにちは。WSUS サポート チームです。

今秋にも Windows 10 Fall Creators Update のリリースが予定されておりますが、Windows 10 の展開も進み、更新プログラムやアップグレードの配信についてどうするか検討されているお客様も多いのではないでしょうか。Windows 10 においては、更新プログラムが累積型となり、サイズが大きくなっております。また、アップグレード用の更新プログラム (機能更新プログラムと呼びます) も数 GB のファイル サイズとなりますので、WSUS クライアントと WSUS サーバー間のネットワーク帯域を逼迫させないためにどうすべきか議論にあがることもあるかと存じます。

WSUS 環境におけるネットワーク帯域制御については、こちらのブログ記事が役に立ちますが、この設定に加えて、そもそも WSUS サーバーからファイルをダウンロードする際のネットワーク トラフィックを抑えることができないかとお思いの事もあるかと思います。現時点において、ダウンロードする際のネットワーク トラフィックを抑える方法としては、次の 3 つがあります。

  1. 高速インストール ファイルを有効にする
  2. BranchCache を使用する
  3. 配信の最適化を使用する

1.と2.については、Windows 10 リリース以前から存在する方法ですので、ご存じの方も多いのではないでしょうか。(Windows 10 1607 以降で BranchCache を利用する際の条件については、こちらのブログ記事が役立ちますので、ご参照ください。) 3. の配信の最適化については、Windows 10 から導入された機能であり、当サポート チームにも配信の最適化がどういう機能か教えて欲しいというお問い合わせを多くいただくようになりました。

そこで、今回は全 3 回にわたって、「配信の最適化」の機能について説明いたしますので、検討の際にお役立ていただけますと幸いです。第 1 回は「概要篇」です。第 2 回は「グループポリシー篇」、第 3 回は「効果測定篇」を予定しております。

概要

「配信の最適化」 (Delivery Optimization : DO) とは、Windows 10 から導入された P2P 型の配布方法です。Windows 10 のアップグレードや累積形式の更新プログラムを配信した際に、世界的なネットワーク負荷高騰が発生してしまうことを防ぐために実装された機能であり、ホーム ユーザーまたは 数十台規模のスモール ビジネス環境での利用を主に想定しています。本機能を利用すると、品質更新プログラムや機能更新プログラムのダウンロードをインターネットや WSUS だけでなく、ピアとなるクライアントのキャッシュから細かく分割されたファイル単位で分散してダウンロードします。また、Windows 10 1607 から更新プログラムをダウンロードする既定のコンポーネントは、BITS から DO に変わりました。この機能は WSUS 環境でも使用することができます。DO での更新プログラムのダウンロードは、BITS と同様に可能な限り、クライアント内の他の処理に影響を与えないよう行われます。

(参考情報)
Windows Update の配信の最適化に関する FAQ

動作フロー

WSUS 環境における、配信の最適化の動作フローは次の通りです。重要なポイントとしては、WSUS 環境であっても、配信の最適化を使用してダウンロード ソースのピアとなるクライアント端末を探すために、インターネットへの接続が必要になる、ということです。この点が BranchCache と大きく異なります。

  1. クライアント A は WSUS に更新プログラムのチェックを行います。
  2. WSUS は、更新プログラムの情報をクライアント A に返します。
  3. クライアント A は Delivery Optimization のクラウド サービスにダウンロード ソースを要求します。
  4. Delivery Optimization のクラウド サービスは、ダウンロード ソースの候補としてクライアント B と C を返します。
  5. クライアント A は、クライアント B と C から、分割された更新プログラムのファイルを要求します。
  6. クライアント A の要求に対して、B、C が応答します。応答がない場合は、WSUS からファイルをダウンロードします。
  7. クライアント A は、分割された更新プログラムのハッシュをチェックします。ハッシュが異なる分割ファイルは破棄します。
  8. クライアント A は、インストール前にすべてのファイルのハッシュをチェックします。

ポート要件

配信の最適化を使用するためのポート要件は次の通りです。

  • クライアント -> インターネット(HTTP 80、HTTPS 443)
  • クライアント <-> クライアント (TCP 7680)
  • クライアント <-> クライアント (UDP 3544) ※
    ※ NAT を超えた P2P を使用する場合。また、Teredo サービスを有効にする必要があります。

なお、クライアント -> インターネットにおいては、次の URL に対して、アクセスを許可するようにプロキシを構成する必要があります。

  • クライアントが配信の最適化クラウド サービスにアクセスするために使用

    • *.do.dsp.mp.microsoft.com
  • 配信の最適化のメタデータをダウンロードするために使用

    • *.dl.delivery.mp.microsoft.com
    • *.emdl.ws.microsoft.com
  • 更新プログラムのペイロード(データ本体)をダウンロードするために使用(オプション)

    • *.download.windowsupdate.com
    • *.windowsupdate.com

(参考情報)
Configure Delivery Optimization for Windows 10 updates
Windows の更新のためのプロキシの要件

前提条件

配信の最適化を使用するためには、次の前提条件を満たす必要があります。

  1. ディスクの容量が 32 GB 以上であること。
  2. メモリが 4 GB 以上であること。
  3. ダウンロードする ファイルが 100 MB 以上であること。
  4. ダウンロードするファイル サイズの x2 以上の空きディスク領域があること。
    なお、1. ~ 3. の前提条件については、Windows 10 1703 からグループ ポリシーを使用して設定変更可能です。

(参考情報)
Windows 10, Delivery Optimization, and WSUS: Take #2

ログ

配信の最適化に関するログは、%windir%\Logs\dosvc に ETL 形式で保存されますが、こちらは現在のところ、シンボルが公開されておりませんので、お客様ご自身でデコードして、解析いただくことはできません。また、パフォーマンス カウンターも用意されておりませんので、ピアからダウンロードしているかどうかを正確に確認する場合は、パケットを解析していただく必要があります。但し、ファイルがキャッシュされているかどうかであれば、次のフォルダーにファイルが存在するかどうかでご確認いただけますので、まずはこちらをご確認ください。

%windir%\SoftwareDistribution\DeliveryOptimization

当該フォルダー配下に実体となるファイルとメタデータである pieceshash ファイルが配置されます。

また、Windows 10 1703 からジョブを確認するための次の PowerShell コマンドが用意されました。

  • Get-DeliveryOptimizationStatus
  • Get-DeliveryOptimizationPerfSnap

こちらのコマンドの出力結果の詳細は第三回「効果測定篇」で説明する予定です。なお、Windows 10 1703 以前の Windows 10 でも、次のレジストリ値より、DO ジョブの確認可能です。こちらも参考までにお役立てください。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DeliveryOptimization\Jobs

「概要篇」は以上です。Windows 10 から実装された機能ですので、ビルド毎に新しい機能が搭載されている状況ではありますが、今後のご検討の際に是非ともお役立てください。次回は「グループポリシー篇」です。

(免責事項)
本情報の内容 ( 添付文書、リンク先などを含む ) は、作成日時点でのものであり、予告なく変更される場合があります。