Microsoft Connected Cache は Windows Update などの更新プログラムをローカルでキャッシュするサーバーを展開できるソリューションです。
こちらは「配信の最適化」という機能のオプションとして使用することができます。
⇒ 数枚の概要スライドも作りましたのでよろしければどうぞ。
配信の最適化とは
Windows 10/11 以降では「配信の最適化」という機能があり、Windows Update などの更新プログラム ファイルを Windows Update サービスからダウンロードするのみではなく、P2P にてファイルのキャッシュを共有できます。
それ以前の Windows 7, 8, 8.1 ではキャッシュ共有機能として「BranchCache」という機能があり、その機能のクラウド対応版・更新プログラム特化型版として考えていただければ OK です。
もしもう少し「配信の最適化」や「BrachCache」など理解を深めたいようであれば、筆者が 5 年ほど前に行った下記のセッションなんかも参考にしていただけると嬉しい限りです！
Microsoft Connected Cache とは
Microsoft Connected Cache は配信の最適化の「キャッシュ」をクライアントだけではなくキャッシュ専用サーバーを作成する機能となります。
こちらの機能は以前から Configuration Manager 専用で提供されおり、今回紹介するものが長きに渡る開発期間を得てプレビューリリースされます。
つまり、Microsoft Connected Cache (MMC) には大きく 2 つのものがあります。
-
Microsoft Connected Cache with Configuration Manager
Configuration Manger 専用 Connected Cache -
Microsoft Connected Cache for Enterprise and Education
スタンドアロン型の Connected Cache
今回紹介するのは後者の「Microsoft Connected Cache for Enterprise and Education」(長いわ！) という独立型のタイプとなり、こちらの設定手順を記載したいと思います。
Windows Update の管理について
また昨今話題となりました WSUS の廃止 といった状況もありますので、必要に応じて今後の対策の一つとして検討をしていただければ幸いです。
またこちらも筆者のセッションで恐縮ですが、イマドキの Windows クライアントの更新管理について説明した内容となりますので参考としていただければ幸いです。
0. 前提条件
以下の前提条件があるのでご注意ください
- ライセンス
- キャッシュできるコンテンツ
- キャッシュ サーバー (キャッシュ ノード) の要件
ライセンス
前提ライセンス として Windows E3 または E5 (教育機関は A3 / A5) が必要なことにご注意ください。
また有効な Azure サブスクリプションが必要ですが、現状料金は発生しません。
キャッシュできるコンテンツ
- Windows 更新プログラム: Windows の機能と品質の更新プログラム
- Office クイック実行アプリ: Microsoft 365 Appsと更新プログラム
- クライアント アプリ: Intune、ストア アプリ、および更新プログラム
- エンドポイント保護: Windows Defender 定義の更新
キャッシュ サーバー (キャッシュ ノード) の要件
また、Connected Cache のノード (サーバー) となれるのは以下の OS です。
- Windows 11 OS ビルド 22631.3296 以降
- Windows Server 2022 OS ビルド 20348.2227 以降
- Ubuntu 22.04
- Red Hat Enterprise Linux (RHEL) 8.* または 9.*
Windows に関しては Windows Subsystem for Linux (WSL) を使って Linux コンテナ上で動くイメージです。詳細が必要であれば推奨スペックなどもありますので以下の Learn を参照ください。
なお、今回の手順では Windows Server に対して展開したいと思います。
1. Azure リソースノードとキャッシュ ノードを作成する
まずは Azure 上で 「Microsoft Connected Cache for Enterprise and Education」を構成する必要があります。Azure ポータルからの作業となります。
-
管理者権限を持つユーザーにて Azure ポータル (https://portal.azure.com/) にアクセス
-
上部の検索ウインドウで「Microsoft Connected」で検索し Marketplace の 「Microsoft Connected Cache for Enterprise and Education」 をクリック
-
「サブスクリプション」「リソース グループ」「場所」を選択
※ 「場所」に関してはプレビュー段階では (Europe) North Europe, (Asia Pacific) Korea Central, and (US) West US となります。
-
内容を確認し [Create] をクリック
-
デプロイが完了したら [リソースに移動] をクリック
-
Connected Cache のページより [Cache Nodes] をクリック
-
[+ Create Cache Node] をクリック
-
「Chacne Node Name」 と OS の種類を選択。今回は Windows Server に展開します。
その後 [Create] をクリック
-
[Refresh] をクリックすると作成したノードが表示されるため、ノード名をクリック
-
[Cache drive size (GB)] を指定し、上部の [Save] をクリック
-
[2. Provisionig] のタブに移動し今回はローカルアカウントで展開するため [Using Local Account] をクリックし、表示されている PowerShell をコピー
-
[Update] のタブに移動し、ノードのアップデート周期を任意で選択。ここでは Fast を選択
-
[Download provisionig package] をクリックし 「MCC-WSL-Installer.zip」を入手
以上です。上記の作業の結果、以下の 2 つがあることをご確認を！
- MCC-WSL-Installer.zip ファイル
- プロビジョニングの際に使用する PowerShell のコピー
2. Windows Server に展開する
以下、Windows Server に管理者権限があるユーザーでリモートデスクトップで接続し、作業を行います。
-
作業用の PC より Windows Server にリモートデスクトップで接続
-
前項で入手した「MCC-WSL-Installer.zip」をコピーし展開
-
PowerShell を管理者権限で起動し、以下のコマンドで Windows Subsystem for Linux (WSL) をインストール
wsl.exe --install --no-distribution
その後再起動をします
- 再度 PowerShell を管理者権限で起動し、前項でコピーした PowerShell を実行。
※ 実行の際には使うユーザーアカウントに応じて$User変数を設定します。
gMSA の場合 には"Domain\Username$"ローカル ユーザーの場合は"LocalMachineName\Username"で指定します。
また、ローカル ユーザーの場合は$myLocalAccountCredentialという PowerShell を実行する資格情報も設定します。以下、環境に合わせて資格情報を変更してください。
$User = "$env:computername\takuyaot"
$myLocalAccountCredential = "$env:computername\takuyaot"
上記の環境変数を設定後、前項でコピーした PowerShell を実行
./provisionmcconwsl.ps1 -installationFolder c:\mccwsl01 -customerid 83035019-3247-46df-b559-295ef702c979 -cachenodeid a70ab939-55de-4395-a6b6-b9dab02bfab2 -customerkey 21179639-a494-42b5-ac4f-8e1a30d1e410 -registrationkey 7caa41c7-9d8c-40f5-bd32-bfc7bbf5f8f1 -cacheDrives "/var/mcc,500" -mccRunTimeAccount $User -mccLocalAccountCredential $myLocalAccountCredential
以上でキャッシュ ノードの展開が完了です！
3. キャッシュ ノードの動作確認
ここでは正常にキャッシュ ノードが動作してるか確認してみましょう。
以下の 3 つのパターンで確認ができます。
- キャッシュ ノード上での確認
- Azure ポータル上での確認
- 接続するクライアントからの確認
キャッシュ ノード上での確認
Connected Cache を設定したサーバーにて管理者権限で PowerShell を起動し以下を実行します。
wget http://localhost/filestreamingservice/files/7bc846e0-af9c-49be-a03d-bb04428c9bb5/Microsoft.png?cacheHostOrigin=dl.delivery.mp.microsoft.com
StatusCode 200 で応答が帰ってくれば OK です！
Azure ポータル上での確認
Azure Portal の設定を行った 「Connected Cache for Enterprise & Education」の Cache Node を確認すると "Healthy" のステータスであることが確認可能です。
接続するクライアントからの確認
クライアントからは Web ブラウザーで Connected Cache のサーバーに接続できるかをチェックします。以下の URL をブラウザーに入力してください
http://[HostMachine-IP-address]/filestreamingservice/files/7bc846e0-af9c-49be-a03d-bb04428c9bb5/Microsoft.png?cacheHostOrigin=dl.delivery.mp.microsoft.com
実際にアクセスが可能だと Microsoft のロゴの png ファイルが降ってきます。
4. クライアントへのポリシーの適用
クライアント OS に対して Connected Cache を使用するように設定します。キャッシュ ノードの FQDN や IP アドレスを指定すれば OK です。
※ 「配信の最適化」そのものは有効にした上で行ってください
以下の 3 パターンが一般的です
- Microsoft Intune
- オンプレミス AD
- DHCP オプション
Microsoft Intune
Microsoft Intune を使用する場合は以下の構成プロファイルを使用します。
[構成] - [Windows 10 以降] - [テンプレート] - [配信の最適化] - [キャッシュ サーバーの完全修飾ドメイン名 (FQDN) または IP アドレス]
オンプレミス AD
オンプレミス AD のグループ ポリシーでは以下を設定します。
[管理用テンプレート] - [Windows コンポーネント] - [配信の最適化] - [キャッシュ サーバーのホスト名]
DHCP オプション
DHCP のオプションとして、クライアントが IP アドレスを取得する際にキャッシュ サーバーの指定が可能です。DHCP オプション ID 235 を使用します。
5. キャッシュ使用状況の確認
実際に上記ポリシー (キャッシュ サーバーの指定) が設定されたクライアントから Windows Update を行います。結果として更新プログラムが見つかればダウンロードが開始されますが、使用状況は以下から確認可能です。
- クライアント OS 上から
- Azure ポータルから
クライアント OS 上から
Windows の設定メニューから確認可能です
[設定] - [Windows Update] - [詳細オプション] の先の・・・
[配信の最適化] の先の・・・
[アクティビティ モニター]
これは設定前なので「Microsoft キャッシュ サーバーから」が 0% の状態
Windows Update をすると「Microsoft キャッシュ サーバーから」のダウンロード量が増加しました！
めでたしめでたし。
Azure ポータルから
Azure ポータル (https://portal.azure.com/) から「Connected Cache for Enterprise and Education」をクリック
「概要」画面で確認が可能です。
こちらで組織全体で使われてる様子が確認できます！
いかがでしたでしょうか。
こちらの機能、アナウンスから数年にわたり開発に時間がかかってしまいましたが、ネットワーク帯域が厳しい環境での新たなソリューションの一つになるかと思います！
Discussion