※本記事はマイクロソフト社員によって公開されております。
みなさま、こんにちは。Windows Commercial Support: Performance チームの鈴木です。最近、Microsoft Connected Cache for Enterprise and Education (以下 MCC) に関するお問い合わせを頂戴する機会が増えてきております。
MCC は、更新プログラムの取得に要する WAN 帯域をローカル キャッシュにより軽減するソリューションです。「キャッシュ ノード」と呼ばれるサーバーをネットワーク内に構築いただくことにより、クライアントが取得した更新プログラムのパッケージを保持し組織内でのダウンロードに再利用することが可能です。
Microsoft Store アプリを業務利用されるユースケースの増加や、WSUS の開発が終了したことなどを背景として MCC をご検討いただいておりますが、2025 年夏に一般提供を迎えた比較的新しいサービスという点もあり情報が少ないとお感じのお客様も多いかと存じます。これまでのお問い合わせ事例等より “勘所” をご紹介いたしますので、お役立ていただけましたら幸いです。
クライアントとキャッシュ ノードそれぞれにインターネット接続が必要です
最も誤解されやすい点ですが、MCC のキャッシュ ノードおよび MCC から更新プログラムをダウンロードするクライアントには双方インターネット接続が必要です。いわゆる完全な閉域網でご利用いただくことはできません。
クライアントが更新プログラムを取得する際の最初のアクセス先はキャッシュ ノードではなく、当社クラウド サービス (Delivery Optimization) となります。更新プログラムを構成するパッケージ本体はキャッシュ ノードから取得するため WAN 帯域の大幅な削減が達成されますが、インターネットへの接続を全く行わないよう構成することはできません。
完全に閉域の環境では、クライアントのみではなく WSUS も多段構成とする手法が取られておりましたが、キャッシュ ノードの多段構成は構築いただけません。直接のインターネット接続が必要である点にご留意ください。
中央集権的に大規模なキャッシュ ノードを構築するよりも、拠点やネットワーク セグメントごとに分散した展開をお勧めします
可能な限り、キャッシュ ノードはクライアントと同じネットワーク セグメントに配置することを推奨しております。サブネットを超える構成ももちろんサポートされておりますが、ルーター等ネットワーク機器への負荷や、キャッシュのヒット率といった観点からベスト プラクティスではございません。
大規模な WSUS を問題なく運用されていた環境においても、WSUS ではキャッシュできなかった Microsoft 365 Apps や Microsoft Store アプリの更新が不定期に取得されることで WSUS よりも圧倒的に多くのトラフィックが転送され、ネットワークが過負荷となる事例が報告されております。なお、WSUS では使用可能であった BranchCache によるトラフィック削減手法も MCC ではご利用いただけません。
Windows Server のライセンスが必要であった WSUS と異なり、MCC のキャッシュ ノードはWindows クライアントや Ubuntu への展開も可能です。キャッシュ ノードの作成にライセンス コストは不要ですので、拠点やネットワーク セグメントごとに分散した配置をご検討ください。
なお、ネットワーク的に最も近いキャッシュ ノードから更新プログラムをダウンロードするため、キャッシュ ノードを分散配置した際は DHCP オプション 235 を使用してキャッシュ ノードのホスト名 / IP アドレスをクライアントに伝えることをお勧めします。グループ ポリシーによる指定よりも機動的に運用いただくことが可能かと存じます。
大規模展開の場合は特に、Linux への展開をご検討ください
Windows クライアントおよび Windows Server を MCC のキャッシュ ノードとして構築することは可能ですが、キャッシュ ノードを実現するソフトウェア群は Linux コンテナーとして実装されております。Windows ネイティブのソフトウェア スタックのご用意はございません。
Windows に構築いただく場合はまず WSL 2 (Windows Subsystem for Linux) 上に Ubuntu がインストールされ、その上で Docker (Azure IoT Edge) コンテナーとしてキャッシュ ノード ソフトウェアが実行されております。
このような背景から、主にストレージやネットワークの部分で Windows 版のほうが複雑な構成となっております。
特に、多数のクライアントを収容する大規模展開の場合はキャッシュを保持するストレージも大きな領域を割り当てる必要が生じますが、Linux 版では Linux ファイル システムを直接利用し、複数のパス (ディスク) を指定できる一方、Windows 版は “/var/mcc” としてマウントされる容量固定かつ単一の VHD (仮想ハードディスク) 以外に変更することができません。
また、若干ではございますが WSL 2 のオーバーヘッドも存在するため、構成の柔軟性やシンプルさ、性能面で Linux への展開にアドバンテージがある一方でデメリットはございません。特に大規模なキャッシュ ノードの構築においては、Linux を強く推奨いたします。
インストールに用いるアカウントと、キャッシュ ノード ソフトウェアの実行に用いるアカウントは必ず別にしていただく必要があります (Windows のみ)
キャッシュ ノードを Windows 上に展開される場合、セットアップに使用するアカウントと、キャッシュ ノードとしての機能を実行するアカウント (ランタイム アカウント) は必ず別なアカウントを指定する必要がございます。
同一のアカウントを指定した場合、一連のセットアップ プロセスの最後で WSL 2 上に作成されたキャッシュ ノードのコンテナーが削除されてしまい、以降正しく動作しなくなることを確認しております。公開技術情報に記載の手順にも別のアカウントを指定するよう注記がございますので、ご確認ください。
Microsoft Connected Cache ソフトウェアを Windows ホスト コンピューターに展開する | Microsoft Learn
https://learn.microsoft.com/ja-jp/windows/deployment/do/mcc-ent-deploy-to-windows?tabs=portal#steps-to-deploy-connected-cache-node-to-windows
なお、デプロイ スクリプトを実行してセットアップを行うアカウントは管理者権限を有している必要がありますが、ランタイム アカウントには管理者権限は不要です。セキュリティの観点から、必要最小限の権限を持たせることをお勧めしております。可能であれば、gMSA (グループ管理サービス アカウント) をランタイム アカウントとして使用することをお勧めいたします。
MCC からキャッシュの提供を受けるクライアントには、Windows Enterprise サブスクリプション ライセンスが必要です
前述の通り、キャッシュ ノードの構築は Windows クライアントや Ubuntu に対しても可能であり、WSUS と異なり Windows Server をご用意いただく必要はありません。サーバー側にライセンスは不要ですが、MCC を利用するクライアント側には下記ライセンスの要件が存在します。
- Windows Enterprise E3
- Windows Enterprise E5
- Windows Education E3
- Windows Education E5
また、Windows Server 2019 以降も MCC のキャッシュ ノード経由で品質更新プログラムを受け取ることが可能です。上記のサブスクリプション ライセンスは Microsoft Entra ID に対し付与する必要があり Windows Server ではご使用いただくことができませんが、正しくライセンスされたクライアントをお持ちであれば Windows Server をキャッシュ ノードに接続いただいて問題ございません。
ライセンスを含む各種要件について記載されている公開技術情報も下記にご用意がございますので併せてご参照ください。
Microsoft Connected Cache for Enterprise and Education の前提条件 | Microsoft Learn
https://learn.microsoft.com/ja-jp/windows/deployment/do/mcc-ent-prerequisites#licensing-requirements
なお、キャッシュ ノードの展開には Azure のサブスクリプションが必要ですが、MCC に関連するリソースでの課金は発生いたしませんのでご安心ください。
Teams の更新を MCC 経由にするには、クライアントとキャッシュ ノード間の接続を TLS にする必要があります
MCC は、Microsoft Teams の更新に係るトラフィックにお悩みのお客様にも積極的にご検討いただいております。Teams は Windows 等と比較しても更新間隔が短い一方、WSUS 等を用いた帯域削減の手段が提供されてこなかった経緯があります。MCC であれば Teams の更新をキャッシュすることが可能であり、各クライアントからのトラフィックを削減することが可能です。MCC がキャッシュできる更新プログラムの種類は、下記の公開技術情報もご確認ください。
配信の最適化とは | Microsoft Learn
https://learn.microsoft.com/ja-jp/windows/deployment/do/waas-delivery-optimization#types-of-download-content-supported-by-delivery-optimization
ただし、Teams の更新を MCC 経由で取得する要件として、クライアントとキャッシュ ノード間の接続を TLS (HTTPS) に対応させる必要があります。Windows や Microsoft 365 Apps の更新をキャッシュする場合は TLS 対応は必要ありませんが、Teams の更新コンテンツの配信においては TLS 接続が必須です。証明書の用意など、通常の MCC の構築に加え追加の手順が存在いたします点にご留意ください。
Microsoft 接続キャッシュの HTTPS サポートの概要 | Microsoft Learn
https://learn.microsoft.com/ja-jp/windows/deployment/do/mcc-ent-https-overview?tabs=portal
また、今後 Intune の Win32 アプリ (.intunewin パッケージ) のキャッシュにおいても TLS が必須化される予定となっております。Windows Autopilot でサイズの大きなアプリを展開する場合の高速化等を目的として MCC をご使用のお客様におかれましては、お持ちのキャッシュ ノードの段階的な TLS 対応をご検討ください。
キャッシュ ノードは静的プロキシのみをサポートしており、PAC や WPAD、クラウド プロキシのような動的構成はご利用いただけません
キャッシュ ノードはなるべくサブネットを超えない範囲に配置することをお勧めしており、またライセンス要件も WSUS や Configuration Manager と比較し緩和されていることから、通常の業務用クライアントを利用してキャッシュ ノードを構築されるお客様のお話も多く伺っております。このような場合に問題となりがちなのが、キャッシュ ノードから Windows Update サイトおよび Delivery Optimization クラウド サービスへの接続経路です。
下記公開技術情報にも記載の通り、キャッシュ ノードから当社 Windows Update 関連のエンドポイントまでは直接接続をご用意いただく必要がございます。
Microsoft Connected Cache ソフトウェアを Windows ホスト コンピューターに展開する | Microsoft Learn
https://learn.microsoft.com/ja-jp/windows/deployment/do/mcc-ent-deploy-to-windows
接続キャッシュのデプロイを成功させるには、接続キャッシュ ホスト マシンからの配信最適化サービスへの直接呼び出しを許可する必要があります。
プロキシの使用自体はサポートされておりますが、実績としてあまり成功例は多くありません。キャッシュ ノードの正常な動作においては、オリジナルの URL や HTTP ヘッダが維持される必要があり、プロキシを介すことでこれらが書き換えられてしまうことが主な失敗の要因です。
また、前述の通り、キャッシュ ノード自体はホストから独立した Linux コンテナー内で動作しております。そのため、ホスト OS に設定されているプロキシ設定を利用することができません。やむを得ずプロキシを使用する際は、キャッシュ ノードのセットアップ時に実行するスクリプトにて “-proxyurl” を指定します。ここではプロキシ サーバーの URL を静的に指定することのみがサポートされており、PAC や WPAD を経由してキャッシュ ノードがインターネットにアクセスする構成はサポートされておりません。
同様に、クライアント ソフトウェアを使用するクラウド プロキシ等もコンテナー内に当該ソフトウェアをインストールすることができないため、ご利用いただけません。
お手数をおかけいたしますが、キャッシュ ノードを構成するコンピューターに対してはプロキシのバイパス等をご検討ください。キャッシュ ノードに接続するクライアントも Windows Update および Delivery Optimization 関連のエンドポイントへの接続が必要ですので、これまで WSUS をご利用であった環境等で URL のフィルタリングを行っている場合などはクライアント側のインターネット接続についても見直しが必要です。
本情報が少しでも皆様のお役に立てば幸いです。
※本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。
更新履歴
- 2025-12-29 初版公開