「Microsoft Connected Cache for Enterprise & Education（以下、Microsoft Connected Cache for E/E ）」の連載シリーズは今回で最終回です。今回は、Microsoft Connected Cache for E/E に関連するよくある“かもしれない”質問（Frequently Asked Questions《FAQ》）を想定してお送りします。連載シリーズ最終回恒例の目次付き。
公式ドキュメントのFAQは、以下のURLにあります。
Microsoft Connected Cache for Enterprise のよく寄せられる質問｜Windows（Microsoft Learn）
配信の最適化に関してよく寄せられる質問｜Windows（Microsoft Learn）
Microsoft Connected Cache for E/E、勝手にFAQ
- キャッシュノードは何台必要ですか？
- Windows ServerはMicrosoft Connected Cache for E/Eのキャッシュノードを利用できますか？
- キャッシュノードはWindowsとLinuxのどちらで展開するべきですか？
- Server CoreインストールにWindowsキャッシュノードを展開できますか？
- Linuxマシンで展開コマンドを実行すると、「command not found」と表示されて実行できません
- Windowsキャッシュノード用の実行アカウントの準備方法を教えてください
- 空きディスク領域が不足しているため、展開コマンドがエラーで失敗します。どう対処すればよいでしょうか
- Windowsキャッシュノードの展開中に「ユーザー設定の読み込み中にエラーが発生しました。無効な "icon" を持つプロファイルが見つかりました」と表示される
- Windowsキャッシュノードの展開コマンドを実行してインストールは成功したようですが、キャッシュの動作を確認できません
- ホストOSのメンテナンスは必要ですか？
キャッシュノードは何台必要ですか？
Microsoft Connected Cache for E/Eのキャッシュノードは1台で、10～50台のWindowsデバイスがある小規模環境（キャッシュノードの推奨スペック: 4コア、8GBメモリ、1Gbpsネットワーク）、数千台の大規模環境まで1台のキャッシュノードで対応できます（キャッシュノードの推奨スペック: 16コア、32GBメモリ、10Gbpsネットワーク）。キャッシュノードが利用できない場合、配信の最適化（Delivery Optimization《DO》）クライアントはCDNにフォールバックするため、可用性のための複数台設置はあまり重要ではありません。
必要なキャッシュノードの数は、Windowsデバイスの台数にはあまり関係なく、ネットワークトポロジに依存します。
インターネット接続回線や、拠点間のWAN回線のトラフィックを最適化するために、拠点ごとに設置するのが望ましいでしょう。物理サーバーや仮想マシン（VM）を用意できない拠点の場合は、Windows 11デバイスをWindowsキャッシュノードとしてセットアップできます。
Windows ServerはMicrosoft Connected Cache for E/Eのキャッシュノードを利用できますか？
配信の最適化（DO）クライアントの機能は、Windows Server 2016以降に標準搭載されています。Windows 10/11の場合、ピアツーピア機能が既定で有効ですが、Windows Serverでは既定で無効になっています。そして、DOクライアントのキャッシュサーバーを指定すれば、ピア機能の有効/無効に関係なく、キャッシュサーバーを利用します。
Microsoft Connected Cache for E/EはDOクライアントがWindows 10/11であるか、Windows Serverであるかを区別しません。そのため、機能的には、Windows ServerでもMicrosoft Connected Cache for E/Eをキャッシュサーバーとして利用できます。しかし、Microsoft Connected Cache for E/Eの要件として、“接続キャッシュノードからコンテンツをダウンロードするデバイスごとに、次のいずれかのライセンスサブスクリプションが必要”とされています。
- Windows 10/11 Enterprise E3またはE5、またはこれらのライセンスを含むMicrosoft 365 F3、E3、またはE5
- Windows 10/11 Education A3またはA5、またはこれらのライセンスを含むMicrosoft 365 A3またはA5
上記のライセンス要件にWindows Serverは含まれていないため、Windows Serverからの利用はライセンス違反になる可能性があります。なお、Microsoft Configuration Manager搭載のMicrosoft Connected Cacheの場合は、サーバー管理ライセンス（ML）でカバーされるWindows Serverから利用でき、Microsoft Connected Cache for E/Eと同様のキャッシュ機能の恩恵を受けることができます。
Microsoft Connected Cache for Enterprise and Education の要件 > ライセンスの要件｜Windows（Microsoft Learn）
キャッシュノードはWindowsとLinuxのどちらで展開するべきですか？
Microsoft Connected Cache for E/Eは、Linux（Ubuntu 24.04 LTS、RHEL 8.x/9.x）およびWindows（Windows 11バージョン23H2以降、Windows Server 2022以降）に展開できます。
LinuxキャッシュノードとWindowsキャッシュノードのどちらも、キャッシュエンジンはAzure IoT Edgeの展開サービスを介して提供されるLinuxベースのコンテナー（コンテナー名MCC）であり、キャッシュドライブはLinuxのファイルシステムの一部です。Linuxキャッシュノードは、ホストとコンテナーの2つのレイヤーで動作するのに対し、Windowsキャッシュノードは、Windows Subsystem for Linux（WSL）2上でLinuxを動かすため、WSL 2のレイヤーがさらに1つ増えます。レイヤーが1つ多いということは、少なからずオーバヘッドがあるでしょう。さらに、ホスト環境のOS（LinuxまたはWindows）が使用するリソースを考慮すれば、つまりパフォーマンス面から言えば、Linuxキャッシュノードの方が効率的です。
一方で、Microsoft Connected Cache for E/Eを展開する方法を柔軟に選べるのは、利点でもあります。既存のインフラストラクチャに存在する物理/仮想環境に追加することもできますし、新規に導入することもできます。サーバーを用意するのが難しい支店でも、Windows 11デバイスにMicrosoft Connected Cache for E/Eを展開できます。
導入する担当者がLinuxに慣れているかどうかも重要です。Linuxに慣れていない場合、Linuxキャッシュノードを展開するのは、難しいかもしれません。一方、Linuxに慣れていなくても、Windowsに展開する場合は、Linuxのシェルに触ることなく、導入、運用することができます。HTTPSのサポートを構成する際も、Windows側での作業だけで終わります。しかし、この連載の最初のほうで指摘したように、アーキテクチャ、仕組みを知らないと、どこで何が動いているのか全く理解できないでしょう。
最後に、ホストOSの更新サイクルも検討材料になるでしょう。Windowsに展開した場合、当然のことながら、キャッシュノードを利用する他のWindowsデバイスと同じように、同時期に、再起動が必要な更新プログラム（米国時間毎月第2火曜日にリリース）のインストールが必要になります。そのため、キャッシュを最大限に活用させるためには、キャッシュノードを利用する別のWindowsデバイスと更新時期をずらすなど対応が必要です。一方、Linuxの更新サイクルはWindowsとは異なります。更新プログラムの提供は不定期ですが、OSのアップグレードでもない限り、通常、再起動を必要としません。
Server CoreインストールにWindowsキャッシュノードを展開できますか？
いいえ、できません。Windowsキャッシュノードは、Windows Server 2022（OSビルド20348.2227《2024-01B》以降）、Windows Server 2025のデスクトップエクスペリエンス、Windows 11バージョン23H2（OSビルド22631.3296《2024-03B以降》）、およびWindows 11バージョン24H2に展開できます。Windowsキャッシュノードの前提コンポーネントである「DeliveryOptimization」アプリはストア（UWP）アプリであり、ストア（UWP）アプリに対応していないServer Coreインストール環境へのインストールは失敗します（画面1）。
画面1 Windows ServerのServer Coreインストールには、前提コンポーネントである「DeliveryOptimization」アプリをインストールできない
Linuxマシンで展開コマンドを実行すると、「command not found」と表示されて実行できません
AzureポータルのCache Node Deployment Command（キャッシュノード展開コマンド）に提示されるコマンドラインを実行するためには、Azureポータルの「Download deployment package」からダウンロードした（mccscrpts.zip）を圧縮解凍して展開したら、展開先のディレクトリに移動して、すべてのシェルスクリプト（.sh）に実行可能（eXecutable）パーミッションを付与してください（画面2）。
| ~$ unzip mccscript.zip ~$ cd MccSripts ~/MccScripts$ chmod +x *.sh |
画面2 「mccscrpts.zip」を展開した後、すべてのシェルスクリプト（*.sh）に実行可能（eXecutable）パーミッションを付与する
Windowsキャッシュノード用の実行アカウントの準備方法を教えてください
Windowsキャッシュノードの実行アカウントとしては、ワークグループ環境の場合はローカルユーザーアカウントを、Active Directoryドメイン環境の場合はローカルユーザーアカウント、ドメインユーザーアカウント、またはグループ管理サービスアカウント（グループの管理されたサービスアカウント、gMSA）を使用できます。
実行アカウントを準備したら、キャッシュノード展開コマンドを実行する前に$User変数に「<コンピューター名>￥<ユーザー名>」（ローカルユーザーアカウントの場合）または「<NetBIOSドメイン名>￥<ユーザー名>」（ドメインユーザーアカウントの場合）または「<NetBIOSドメイン名>￥<ユーザー名>$」（gMSAの場合）を設定する必要があります。ローカルユーザーアカウントまたはドメインユーザーアカウントを使用する場合は、さらに、$myLocalAccountCredential変数にユーザーの資格情報（Get-Credential $User）を設定する必要があります。グループ管理サービスアカウント（gMSA）は、パスワードが委任されたコンピューターにより自動管理されるため、ユーザーが知ることはできませんし、設定する必要もありません。
ローカルユーザーアカウントは、「ローカルユーザーとグループ」スナップイン（lusrgr.msc）を使用して、一般ユーザー（ローカルグループUsersのメンバー）として作成し、パスワードを設定して、さらにパスワードを無期限に設定します。ローカルコンピューター上のPowerShell（管理者）で次のコマンドラインを実行して準備することもできます。
|
net user "<ユーザー名>" <パスワード> /Add 例:
|
ドメインユーザーアカウントの場合は、ドメインコントローラー上で「Active Directoryユーザーとコンピューター」スナップイン（dsa.msc）を使用して、一般ユーザー（ドメイングループDomain Usersのメンバー）として作成し、パスワードを設定して、さらにパスワードを無期限に設定します。ドメインコントローラー上のPowerShell（管理者）で次のコマンドラインを実行して準備することもできます。
|
net user "<ユーザー名>" <パスワード> /Add /Domain 例:
|
グループ管理サービスアカウント（gMSA）の場合は、ドメインコントローラー上のPowerShell（管理者）で次のコマンドラインを実行して作成し、キャッシュノードを展開するコンピューター（複数指定する場合はserver01$, server02$のようにコンマ区切りで指定）がパスワードを自動管理できるように委任します。なお、Add-KdsRootKeyコマンドレットは、New-ADServiceAccountコマンドレットの実行時に"キーがありません”と表示された場合にのみ実行します（画面3）。
|
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10) 例:
|
画面3 グループ管理サービスアカウント（gMSA）を作成し、キャッシュノードを展開するコンピューターに管理を委任する
グループ管理サービスアカウント（gMSA）を作成し、その管理をコンピューターに委任したら、委任先のコンピューター（キャッシュノードを展開するコンピューター）のPowerShell（管理者）で次のコマンドラインを実行し、グループ管理サービスアカウント（gMSA）をテストします。Trueが返ってくれば、問題ありません。
|
Test-ADServiceAccount -Identity "<ユーザー名>" 例:
|
実行アカウントを準備したら、キャッシュノードを展開するWindowsマシンで、実行アカウントに対してユーザーの権利「バッチジョブとしてログオン」を割り当てます。それには、キャッシュノードを展開するWindowsマシンで「ローカルコンピューターポリシー」（Gpedit.msc）または「ローカルセキュリティポリシー」（Secpol.msc）を開き、「コンピューターの構成￥Windows の設定\セキュリティの設定￥ローカル ポリシー￥ユーザー管理の割り当て」で「バッチジョブとしてログオン」のプロパティを開き、「<コンピューター名>￥<ユーザー名>」（ローカルユーザーアカウントの場合）または「<NetBIOSドメイン名>￥<ユーザー名>」（ドメインユーザーアカウントの場合）または「<NetBIOSドメイン名>￥<ユーザー名>$」（gMSAの場合）を追加します（画面4）。
画面4 実行アカウントのローカルユーザーアカウント、ドメインユーザーアカウント、またはgMSAに「バッチジョブとしてログオン」のユーザーの権利を割り当てる
空きディスク領域が不足しているため、展開コマンドがエラーで失敗します。どう対処すればよいでしょうか
キャッシュノードを展開するためには、キャッシュドライブのパスを含むパーティションに、キャッシュドライブのサイズ（最小100GB）の空き領域がない場合、展開コマンドはエラーで中止されます。Windowsキャッシュノードの場合、キャッシュドライブはLinuxディストリビューションの「/var/mcc」に固定されますが、このファイルシステムを含むVHDXファイルが容量固定に変換され（Ubuntu-24.04-Mcc-Converted.vhdx）、展開コマンドの-InstallationFolderに指定されたパス（既定は「C:\mccwsl01」）に配置されます。
Linuxキャッシュノードの場合:
Specified amount of space does not exist on /cachenode/node01. Available space is XX GB and specified space is 100 GB. Please update the space in portal and try again. Exiting
Windowsキャッシュノードの場合:
WSL MCC setup requires a VHDX fixed image to be created at path : c:\mccwsl01, please ensure Hyper-V is installed and space is available for VHDX file, required space : 100 GB
Linuxキャッシュノードの場合、/（ルート）パーティションに十分な空き領域がない場合は、十分な容量のある別のディスクをマウントして、そのマウントポイント（またはマウントポイントのサブディレクトリ）をキャッシュドライブのパスに指定してください（画面5）。
画面5 Linuxキャッシュノードの場合は、別ディスクをマウントし、マウントポイントをキャッシュドライブのパスに指定する
Windowsの場合、C:ドライブに十分な空き容量がない場合は、十分な容量のある別のディスクをドライブ（D:など）にマウントし、展開コマンド実行時に-InstallationFolderのパスをそのドライブ上のパスに変更して実行します（画面6）。
画面6 Windowsキャッシュノードの場合は、展開コマンドの-InstallationFolderのパスを、十分な空き容量のある別ドライブのパスに変更して実行する
Windowsキャッシュノードの展開中に「ユーザー設定の読み込み中にエラーが発生しました。無効な "icon" を持つプロファイルが見つかりました」と表示される
キャッシュノード展開スクリプトを「Windows Terminal」の「Windows PowerShell」や「PowerShell」で実行していて、インストールに使用しているログオンユーザーと実行ユーザーが同じ場合、インストールの最終段階からWindows Terminalを開くたびにこのエラーが発生することを確認しています（画面7）。
なお、コンソール出力のログからはインストールが成功しているかのように見えますが（Successfully verified MCC is installed, running and responding to requests!およびInstaller return code 0）、実際にはそのインストールは失敗しています（次のQを参照）。
画面7 インストールに使用しているログオンユーザーと実行ユーザーが同じ場合、インストールの最終段階から、Windows Terminalでこのようなエラーが発生
Windowsキャッシュノードの展開コマンドを実行してインストールは成功したようですが、キャッシュの動作を確認できません
Windowsキャッシュノードのインストールに使用するログオンユーザーと、実行アカウントを同じにしていませんか？ ログオンユーザーと実行アカウントは別にする必要があります。
Windowsキャッシュノードの展開は、ログオン中のユーザーのWSL 2環境にLinuxディストリビューション「Ubuntu 24.04」がインストールされ（インストール先パス￥ext4.vhdx）、それをエクスポート（インストール先パス￥Ubuntu-24.04-Mcc.vhdx）したものを容量固定VHDXに変換（インストール先パス￥Ubuntu-24.04-Mcc-Converted.vhdx）してから、実行アカウントの環境に「Ubuntu-24.04-Mcc」としてとしてインポートされ、Microsoft Connected Cache for E/Eのコンポーネント（前提コンポーネントであるDockerやAzure IoT Edge、およびコンテナー）がインストールされ、動作確認が行われます。そして、インストールの最後に、ログオン中のユーザー環境から「Ubuntu-24.04-Mcc」が登録解除（--unregister）されてクリーンアップされます（実際にはエクスポート直後の時点で削除済み）。
展開が完了すると、Microsoft Connected Cache for E/EのLinuxディストリビューション「Ubuntu-24.04-Mcc」は、実行アカウントのコンテキストで実行されます。そのために、実行アカウントには「バッチジョブとしてログオン」のユーザーの権利が必要です。これにより、デバイスを使用するユーザーのログオン/ログオフ状態に関係なく、Microsoft Connected Cache for E/Eのサービスを提供できます。
ログオンユーザーと実行アカウントが同じ場合、エクスポートされたものが、同じユーザー（ログオンユーザー）の環境に再び「Ubuntu-24.04-Mcc」としてインポートされ、インストールの最後の段階でログオンユーザー環境のクリーンアップの一環として、ログオンユーザーにインポートされた「Ubuntu-24.04-Mcc」の登録が解除（削除）されてしまいます。結果として、キャッシュ機能をテストしても、接続先が存在しないため失敗します。
展開コマンドのコンソール出力は、ログオンユーザーと実行アカウントが別の場合でも、同じ場合でも、以下のように出力します。ログオンユーザーと実行アカウントが同じ場合、「Unregistered base Ubuntu image version: Ubuntu-24.04-Mcc after successful install of MCC」（※Linuxディストリビューションが既に存在しない場合でも「登録解除。」と出力します）のところでインポートされたLinuxディストリビューション「Ubuntu-24.04-Mcc」がログオンユーザーの環境から削除されてしまいます。Azureポータルにはしばらく「Healthy」の状態が報告されますが、これは「Successfully verified MCC is installed, running and responding to requests!」の確認時点での状態を示すものであり、いずれ「Unhealty」の状態に切り替わります。
|
･･･ トランスクリプトが停止されました。出力ファイル：... |
画面8 インストールログもAzureポータルの表示も正常に終わったように見えるが、ログオンユーザーと実行ユーザーが同じ場合、せっかくセットアップされた「Ubuntu-24.04-Mcc」が最後にクリーンアップされてしまう
ホストOSのメンテナンスは必要ですか？
OSおよびその他のソフトウェアの脆弱性を放置しないためにも、ホストOSのメンテナンス更新を実施することを強くお勧めします。
Microsoft Connected Cache for E/Eのソフトウェアは、キャッシュノードの構成の「Fast」または「Slow」更新サイクルで、Azure IoT Edgeの展開サービスを通じて自動管理されます。また、Microsoft Connected Cache for E/Eの関連のコンポーネント（Dockerエンジン、Azure IoT関連）については、rootのCronジョブに登録された「hostupdate.sh」スクリプトにより4時間ごとに確認されるようです（sudo crontab -lで確認可能）。
Linuxのその他のパッケージの更新については、次のコマンドを定期的に実行することで、確認、インストールすることができます。Linuxの場合、OSの再起動が要求されることはめったにありません。
| ~$ sudo apt-get udpate ~$ sudo apt-get upgrade |
Windowsキャッシュノードの場合は、Microsoft Connected Cache for E/Eが動いているLinuxディストリビューション「Ubuntu-24.04-Mcc」が実行アカウントのコンテキストで動作していることに注意してください。実行アカウントでローカルログオンするか、SSH接続*1してWSLのシェルに切り替え、Linuxシェルに入って作業することになます（画面9）。
*1 メモ. 安全なリモート管理用にOpenSSH Serverを構成する方法｜Windows Server 2025大特集（おまけ）
Windowsキャッシュノードの場合は、Linuxディストリビューション内のパッケージの更新だけでなく、Windowsオペレーティングシステムの毎月の更新があります。Windows Updateによる毎月の更新は、確実に再起動が要求されます（ホットパッチを利用しているのでない限り）。
画面9 Windowsキャッシュノードの場合、ホストであるWindowsと、Linuxディストリビューション（rootで接続できるため、sudoは不要）の両方のソフトウェアの更新が必要
・・・
「Microsoft Connected Cache for E/E 完全導入ガイド」連載シリーズの目次 |
