かつて山市良と呼ばれたおじさんのブログ

セイテクエンジニアのブログ  かつて山市良と呼ばれたおじさんのブログ  vol.76 オンプレミスWSUSの代替になるか? Microsoft Connected Cache for Enterprise(Preview)をプレビュー|Windows Server 2025大特集(13)

 

 

vol.76 オンプレミスWSUSの代替になるか? Microsoft Connected Cache for Enterprise(Preview)をプレビュー|Windows Server 2025大特集(13)

2025年01月20日配信
執筆者:山内 和朗

 前回は、Windows Server 2025で開発終了(非推奨)リスト入りした「Windows Server Update Services(WSUS)」が、機能的にWindows Server 2022以前の最新のWSUSと同等のもので、問題なく機能することを検証しました。今回は、前回の最後に少しだけ触れた「Microsoft Connected Cache for Enterprise and Education(Preview)」を試してみます。

 

Microsoft Connected Cache for Enterprise and Education(プレビュー)とは

 

 Microsoftは、Windows Server 2025が正式リリースされた2024年11月1日(米国時間)のちょうど1週間前に、「Microsoft Connected Cache for Enterprise and Education(Preview)」(以下、Microsoft Connected Cache、Microsoft Connected Cache for Enterprise)のパブリックプレビューを開始しました(それ以前は、別途申し込みが必要な早期プレビューでした)。

Microsoft Connected Cache for Enterprise and Education preview|Windows IT Pro Blog(Tech Community)
Microsoft Connected Cache for Enterprise and Education の概要|Windows(Microsoft Learn)

 Microsoft Connected Cacheは、Windows 10以降の「配信の最適化(Delivery Optimization)」機能のキャッシュ専用サーバーとして動作する、ソフトウェアベース(Linuxベースのコンテナー)の“無料”のキャッシュソリューションです。Microsoft Connected Cacheは、Azureポータル(またはAzure CLI)を使用して準備、展開、管理することができます。

 Windows 10以降では、配信の最適化が既定で有効になっており、ローカルネットワーク上の別のデバイスにキャッシュされた更新プログラムのコンテンツが利用可能な場合、Microsoftからではなく、そのコンテンツをピアツーピア(P2P)でダウンロードして利用します。オンプレミスの企業ネットワーク上にソフトウェアベースのMicrosoft Connected Cacheを展開すると、Windows 10/11デバイスからの要求をキャッシュ専用サーバーが仲介して、デバイスに変わってMicrosoftのCDN(コンテンツ配信ネットワーク)からダウンロードしてキャッシュを埋め、キャッシュからP2Pでクライアントデバイスにコンテンツを提供するようになります。これにより、企業ネットワークとMicrosoft CDN間のコンテンツのダウンロード帯域の大幅に縮小を期待できます。

 Microsoft Connected Cacheは“無料”と言いましたが、重要な前提条件があります。それは、Azureサブスクリプションが利用可能であること(Azureサブスクリプションがあれば無料で利用できます)。そして、「for Enterprise and Education」とあるように、Microsoft Connected Cacheからコンテンツをダウンロードするクライアントデバイスごとに、Windows Enterprise(E3/E5)またはEducation(A3/A5)のサブスクリプションライセンスが必要になることです。この前提条件に従うなら、Windows 10/11のその他のエディション(ProやHome)やWindows Serverは、Microsoft Connected Cacheを利用することができないようです(※Windows Server 2025をクライアントデバイスとして構成してみたところ、Microsoft Connected Cacheを利用しているように見えました)。なお、この前提条件は、後述する「for Enterprise」ではないMicrosoft Connected Cacheには適用されないと思います。

 Microsoft Connected Cacheは、Windows 10以降の配信の最適化機能とともに動作するため、インターネットから遮断されたクライアントデバイスに更新プログラムを提供することもできません。クライアントデバイスが多く、インターネット接続帯域の圧迫が懸念される環境に適しています。インターネットに断続的に接続する環境(ダイヤルアップ接続)や、インターネットの帯域幅が大幅に制限される(衛星インターネットなど)にも対応できます。

 クライアントデバイスは、クラウド管理されているMicrosoftコンテンツ(Microsoft CDN上のコンテンツ)をダウンロードする際に、Microsoft Connected Cacheを利用できます。Microsoft Connected Cacheでサポートされるコンテンツは、次に示す更新プログラムです。ただし、これがすべてではありません。

 

  • Windows 11の機能更新プログラム
  • Windows 10/11の品質更新プログラム
  • Microsoft 365 Apps
  • Microsoft Office(クイック実行)
  • ストアアプリ(Universal Windows Platform≪UWP≫アプリ)
  • Microsoft Defender定義の更新プログラム(セキュリティインテリジェンス)
  • Microsoft Edge

 

 Microsoft Connected Cacheには、この他に「for ISP(プレビュー)」と「for Configuration Manager」があります。「Microsoft Connected Cache for ISP」は、エンドカスタマーや他のサービスプロバイダー向けにコンテンツのダウンロードを提供するプロバイダー向けのソリューションです。

 「Microsoft Connected Cache for Configuration Manager」は、「配布ポイント」サイトシステムの役割で簡単に有効にすることができます。「for Enterprise」とはアーキテクチャが異なりますが、Microsoft CDNやIntuneのコンテンツのキャッシュとして機能します。この機能は2021年11月に一般提供(GA)されており、Current Branchバージョン2111以降にGA版の機能が搭載されています。なお、Configuration ManagerのMicrosoft Connected Cacheは、Configuration Managerで管理されるコンテンツについてはキャッシュしません。つまり、WSUSに依存する「更新ポイント」サイトシステムの役割が不要になるわけではありません、言い換えれば、Configuration ManagerのMicrosoft Connected Cacheは、Configuration ManagerをWSUS非依存にするものではありません。

Microsoft Connected Cache for Configuration Manager generally available|Microsoft Intune Blog(Tech Community)

Microsoft Connected Cache for Enterpriseを展開する

 

 Microsoft Connected Cacheは、最終的に物理サーバーまたは仮想マシン(VM)上で動作するLinux環境のコンテナー(Microsoft Connected Cache《MMC》コンテナー)として「Azure IoT Edgeコンテナー管理サービス」を通じてLinux環境にダウンロードされ、動作します。コンテナーを動かすLinux環境としては、Windows 11またはWindows Server 2022の「Windows Subsystem for Linuxバージョン2(WSL 2)」と、Ubuntu 22.04またはRed Hat Enterprise Linux 8または9を使用できます。

 

 プレビュー版であるため、システム要件など細かいところは省略しますが、物理サーバーまたはVMのWindows Server(デスクトップエクスペリエンスまたはServer Core)に導入する方法で説明します。Windowsに展開する場合、WSL 2を使用するため、VMの場合は入れ子になった仮想化(Nested Virtualization)を有効にする必要があります。

 

 まず、AzureポータルのMarketplaceで「Microsoft Connected Cache for Enterprise」を検索して、リソースの作成を開始します。リソースの作成は、リソースグループと場所(リージョン)、リソース名を指定するだけで完了します(画面1)。なお、この記事のために利用した時点では、プレビューが利用できる場所がWest US、North Europe、Korea Centralリージョンに限られていました。

 

画面1
画面1 「Microsoft Connected Cache for Enterprise」のリソースを作成する

 

 リソースを作成できたら、リソースの場所(「 Connected Caches for Enterprise & Education」ブレードの「リソース名」)に移動し、「+Create Cacne Node」をクリックして、キャッシュノードの仕様としてキャッシュノードの名前とOSの種類(今回はWindows)を指定し、「Create」をクリックします。

 

画面2
画面2 「Connected Cache for Enterprise & Education」リソースにキャッシュノードを作成する

 キャッシュノードが作成されたら、その設定を開きます。最初の「1. Configuration」タブでキャッシュドライブのサイズをGB(最小50~最大2000)で指定し、キャッシュノードがインターネットアクセスにプロキシサーバーを使用する必要がある場合はプロキシサーバーの設定を行います。「Save」をクリックして設定を保存し、「Download provisioning package」をクリックして、インストーラー(Windowsに展開する場合は「MCC-WSL-Installer.zip」)をダウンロードします(画面3)。

 

画面3
画面3 キャッシュドライブサイズ(GB)を指定し、「Save」で設定を保存したら、WindowsにMicrosoft Connected Cache(MCC)を展開するためのインストーラーをダウンロード

 

 続いて、「2. Provisioning」タブに切り替え、プロビジョニングコマンドを実行するアカウント(GMSAまたはローカルユーザーアカウント)を選択し、プロビジョニング用のPowerShellのコマンドラインをクリップボードにコピーします(画面4)。このとき、コマンドラインに「<COMMAND GENERATION IN PROGRESS, PLEASE CHECK BACK LATER.>」と表示される場合は、キャッシュノードの設定をいったん閉じ、開き直してください。なお、キャッシュノードの設定の「4. Updates」タブでは、キャッシュノードの更新サイクルを設定(既定は「Fast」)することができます。「4. Updates」タブの設定を変更した場合は、「Save」をクリックして設定を保存してください。改めて、PowerShellのコマンドラインをコピーしてください。

 

画面4
画面4 キャッシュノードの設定の「2. Provisioning」タブに切り替え、アカウントの種類を選択し、PowerShellのコマンドラインをコピーする

 インストーラーのZIPファイルとPowerShellのコマンドラインの準備が出来たら、Microsoft Connected Cacheを展開するWindows Server 2022以降のサーバー(またはWindows 11)でコマンドプロンプトまたはPowerShellを開き、次のコマンドラインを実行して、LinuxディストリビューションなしでWSL 2をインストールし、サーバーを再起動します(画面5)。

PS C:¥> wsl.exe --install --no-distribution

 

画面5
画面5 WSL 2に必要なオプション機能だけをインストールして再起動する

 次に、インストーラーのZIPファイルの内容を任意の場所に展開し、PowerShellを開いてその場所に移動したら、コピーしておいたPowerShellのコマンドラインを次のように実行します。次の例は、ローカルアカウントを使用する場合の例です。最初のコマンドラインでは$User変数に実行アカウントのローカルユーザーを指定し、次のコマンドラインではGet-Credentialでその資格情報を$myLocalAccountCredential変数に格納します(「Windows PowerShell資格情報の要求」ダイアログボックスが表示されます)。そして最後に、Azureポータルからコピーしたプロビジョニング用のコマンドラインを実行します。このとき、インストール先フォルダー(-installationFolder)のパスを、指定したキャッシュドライブのサイズを格納するのに十分な空き領域あるパスに変更できます(画面6)。なお、実行アカウントGMSAを使用する場合は、-mccLocalAccountCredentialパラメーターはありません(2行目は不要です)。

 

PS C:¥> $User = "$env:computername\Administrator"
PS C:¥> $myLocalAccountCredential = Get-Credential
(または、$myLocalAccountCredential = Get-Credential -Credential $User)
PS C:¥> ./provisionmcconwsl.ps1 -installationFolder c:\mccwsl01 -customerid ~(中略)~ -cacheDrives "/var/mcc,100" -mccRunTimeAccount $User -mccLocalAccountCredential $myLocalAccountCredential


画面6
画面6 既定のインストール先フォルダー「c:¥mccwsl01」を、「D:¥mccwsl01」に変更して実行した。インストール先フォルダーには、WSL 2にインポートされるLinuxディストリビューションのディスクイメージ(ext4.vhdx)、インストールログ、アンインストールスクリプトなどが配置される

 プロビジョニング用のスクリプトがエラーなしで実行され、「Installer return code 0」で終了すれば、インストール成功です。しかし、Windows Server 2025日本語版および英語版(OSビルド26100.2314)で試してみたところ、いずれも次のような例外エラー(日本語の場合)が発生し、インストールが失敗する状況でした。

“System.Management。Automation.RuntimeException: null 値の式ではメソッドを呼び出せません... WSL MMC install failed (ReturnCode: )”

 プレビューの前提条件にWindows 11(OSビルド22631.3296)以降、Windows Server 2022(OSビルド20348.2227)以降となっていたので、Windows Server 2022日本語版(OSビルド20348.2849)でも試してみましたが、同じ例外エラーが発生します。唯一、Windows Server 2022英語版(OSビルド20348.2849)で、インストールを成功させることができ、Azureポータルのステータスは「Healthy」になりました(画面7、画面8)。参考までに、Windows Server 2022英語版の環境は、入れ子になった仮想化が有効になっているHyper-V VMで用意しました。VMに割り当てたリソースは、8コアCPU、12GBメモリです。

Microsoft Connected Cache for Enterprise and Education の要件|Windows(Microsot Learn)
Troubleshoot Microsoft Connected Cache for Enterprise and Education|Windows(Microsoft Learn)

 

 後日、上記のトラブルシューティングのページに、Windows 11日本語版で問題が発生することが追加されましたが、Windows Serverについても、おそらく同じ理由です。表示言語を英語に切り替えてスクリプトを実行することで問題を回避できるとのことです。

画面7
画面7 Windows Server 2022英語版の環境には、エラーなくインストールが成功した

 

画面8
画面8 インストールに成功すると、Azureポータルのキャッシュノードのステータスが「Healthy」になる

 Microsoft Connected Cacheのキャッシュノードが動作しているかどうかは、Microsoft Connected CacheをホストしているサーバーのPowerShellで次のコマンドラインを実行することで確認できます。ステータスコード「200(OK)」であれば問題ありません。

 

PS C:¥> wget http://localhost/filestreamingservice/files/7bc846e0-af9c-49be-a03d-bb04428c9bb5/Microsoft.png?cacheHostOrigin=dl.delivery.mp.microsoft.com

 

 Microsoft Connected Cacheとクライアントデバイスの接続性を確認するには、上記コマンドラインのlocalhostの部分をWindows ServerのIPアドレス(v4)に変更して実行します。

 なお、WindowsにMicrosoft Connected Cacheを展開した場合、WSL 2の環境に「Ubuntu-22.04-Mcc-Base」がインポートされ、実行中になります。Microsoft Connected Cacheの機能のストレージは、このLinux環境の「/var/mcc/cache」が提供するのですが、サービスはLinux上のコンテナー環境(containerd)で実行される「MCC」コンテナー(Azure IoT Edge管理サービスによってダウンロード、展開)が提供します(画面9)。

 

画面9
画面9 キャッシュはWSL 2上のLinux環境(Ubuntu-22.04-Mcc-Base)の「/var/mcc/cache」に格納され、サービスはMMCコンテナーとしてデプロイ、実行される(iotedge listコマンドで確認可能)

 

Microsoft Connected Cacheを使用するようにクライアントを構成する

 

 企業内ネットワークにMicrosoft Connected Cacheを展開したら、Microsoft IntuneのMDM管理やグループポリシー(またはローカルコンピューターポリシー)の「配信の最適化」ポリシーの一部としてクライアントデバイスがMicrosoft Connected Cacheを使用するように構成することができます。

 Microsoft Intuneが利用できる場合、Windows 10以降向けの「配信の最適化」ポリシーテンプレートにある「キャッシュサーバーの完全修飾ドメイン名(FQDN)またはIPアドレス」にMicrosoft Connected CacheのFQDNまたはIPアドレスを設定します(画面10)。

 

画面10
画面10 Microsoft Intuneで「配信の最適化」ポリシーを作成する

 グループポリシー(またはローカルコンピューターポリシー)を利用する場合は、「コンピューターの構成¥(ポリシー)¥管理用テンプレート¥Windows コンポーネント¥配信の最適化」にある「キャッシュサーバーのホスト名」ポリシーを有効にし、キャッシュサーバーのFQDNまたはIPアドレスを設定します(画面11)。

 

画面11
画面11 ローカルコンピューターポリシーによるキャッシュサーバーの設定。Active Directoryドメインを展開済みであれば、グループポリシーを使用して一元管理できる

 

Microsoft Connected Cacheの使用状況の監視

 

 Microsoft Connected Cacheの使用状況は、Azureポータルの「Connected Cache for Enterprise & Education」リソースの「概要」ページで確認することができます(画面11)。Cache Node Summaryの「Healthy nodes」「Unhealthy nodes」は、キャッシュノードの正常性を示しており、「Max in」は過去24時間にキャッシュノードがCDNエンドポイントからプルしたMbpsを、「Max out」は過去24時間にクライアントデバイスに送信したMbpsを、「Average in」「Average out」はその平均を示しています。そして、「Cache Efficiency」はキャッシュノードのキャッシュで実現されたキャッシュ効率を示しています。

 

画面12

画面12 AzureポータルでMicrosoft Connected Cacheの使用状況を監視する

 Microsoft Connected Cacheが高いパフォーマンスを提供出来ている場合、90%以上のキャッシュ効率を実現できるようです。画面12の例は、キャッシュノードのクライアントとして構成した3台のWindows 11バージョン24H2から、2024年11月末にWindows Updateの手動実行、Microsoft Edgeの手動更新、Microsoft Storeの更新プログラムの取得を実行し、2024年11月のオプションの更新プログラム(KB5046740、Microsoft Updateカタログでのx64用サイズは981MB)を含む更新プログラムをダウンロード、インストールした後の状況を示しています。3台のクライアントだけでも、60%以上のキャッシュ効率を実現しました。

 クライアント側では、「設定|Windows Update|詳細オプション|配信の最適化|アクティビティモニター」から、更新プログラムのダウンロードにキャッシュサーバーが使用されているかどうかを確認することができます(画面13)。詳細な情報は、PowerShellの「Get-DeliveryOptimizationStatus」を使用して確認することもできます。

画面13
画面13 3台のWindows 11クライアントのうち1台の「アクティビティモニター」は、ほとんどのダウンロードにキャッシュサーバーを使用していた(注: Microsoftキャッシュサーバーは、Microsoft Connected Cache以外にもインターネット上に存在するようだが、この例の場合、オンプレミスのMicrosoft Connected Cacheを示していると思われる)

 

WSUSの代替ではないけれど、他の更新方法との組み合わせでオンプレミスのダウンロードを最適化できそう

 

 このように、Microsoft Connected Cache for Enterpriseは、事前にMicrosoft CDNからダウンロードして、完全なキャッシュを提供するものではなく、クライアントからの要求に応じてキャッシュを埋めていく仕組みです。更新プログラムの管理機能を含むものではなく、WSUSの機能を置き換えるものではありません。しかし、Microsoft CDNからダウンロードする更新方法、例えば、クライアントデバイス自身のWindows Updateによる更新、Microsoft 365 Appsの更新、ストアアプリの更新、Microsoft Edgeの更新、Windows Updateの遅延ポリシー(旧Windows Update for Business)、オンプレミスの更新ポイントを持たない(持てない)クラウドベースの更新管理機能(Microsoft Intune単体)、Azure Arc対応サーバーのAzure Update Managerによる更新などと組み合わせて、オンプレミスのダウンロードトラフィックを最適化することができそうです。

 

 ただし、「for Enterprise」の前提条件であるWindows EnterpriseまたはEducationライセンスが、導入の壁になるかもしれません。

blog_yamanxworld_subscribe

blog_yamanxworld_comment

blog_yamanxworld_WP_2024fh_TOP5

最新記事