Winodws Update (Intune) + 配信の最適化
WSUSの廃止
色々なところで記事になっておりますが、WSUSが廃止となります。一応Windows Server 2025では機能追加が可能なものの、移行を考える必要があります。
Intuneでの更新プログラム管理は昔からあったようですが、さらに自動化をするための仕組みとして近年登場したのが、Autopatchということになります。
Autopatch
まずはIntuneの画面からautopatchグループを作成する。展開リングを必要な数だけ作成する。
次に展開リングに適用するEntraグループを作成してコンピュータデバイスをメンバーとして登録する。セキュリティグループで作成するところがポイントのようです。作成したグループを、それぞれの展開リングの割り当て済みグループに指定します。
Windows Update設定を行います。デプロイリングの設定として延期期間、期限、猶予期間の設定をします。多分以下でよいはず。
延期期間:更新プログラムがリリースされてからダウンロードするまでの期間
期限:ダウンロード後インストールを行うまでの期間
猶予期間:インストール後再起動するまでの期間
ドライバー更新のリング設定を行う。
手動にすることで、特定のドライバーを展開することが可能。
機能更新プログラム タブで、Global DSS Policyが自動作成されているので「展開する機能更新プログラム」で指定したビルドが展開するビルドとなる。
autopatchの対象として、Officeを有効化すると自動的に構成プロファイルが作成されます。
セキュリティグループも自動的に作成されます
それぞれの構成プロファイルに、自動的に作成されたグループが適用されている
配信の最適化
一方、autopatchとセットで考える必要があるのが、配信の最適化となります。遍歴は以下リンク先が参考になります。
簡単に言うと、すでに更新プログラムをダウンロード済みのパソコンから、更新プログラムを取得することにより、インターネットアクセスを削減できるという仕組み。直近ではキャッシュサーバーという仕組みがプレビュー版になり、WSUSのようにサーバーから更新プログラムを配信することが出来るようになった。
最初に取得する先はローカルのピア、次にキャッシュサーバー、次にインターネットという順番が一番インターネットの負荷を下げられる構成になるかと思います。
項目 | 設定値 |
---|---|
ダウンロード モード | グループ (2) |
ピアの選択を制限する方法を選択します | ローカル ピア検出 |
キャッシュの最大有効期間 | 14日(or7日?) |
ピア キャッシュを使用できる最小 RAM (包括的) | 4GB |
ピア キャッシュを使用できる最小ディスク サイズ | 128GB |
最大キャッシュ サイズ | 10% |
ピア キャッシュ コンテンツ ファイルの最小サイズ | 1MB |
月間アップロード データ上限 | 1 |
最小バックグラウンド QoS | 64(or500?) |
デバイスが VPN 経由で接続している間にピア キャッシュを有効にする | 無効 |
設定されたバッテリ レベルの下でデバイスがバッテリに搭載されている間にアップロードを許可する | 40 |
HTTP からのバックグラウンドダウンロードを遅延する (秒) | 3600 |
HTTP からのフォアグラウンドダウンロードを遅延する (秒) | 60 |
バックグラウンド ダウンロード キャッシュ サーバー フォールバックを遅延する(秒) | 3600 |
フォアグラウンド ダウンロード キャッシュ サーバー フォールバックを遅延する (秒) | 60 |
※それぞれの詳細は以下リンクを参照
・「ダウンロードモード」と「ピアの選択を制限する方法」について
ADを構築している場合は、ダウンロードモードはグループ(2)モードが推奨。
グループ(2)モードにすることで「Active Directory Domain Services (AD DS) サイト、またはデバイスが認証されるドメインに基づいてグループが自動的に選択」される。
さらに、ピア制御選択で「サブネット」または「ローカルピア検出」を指定すればサブネット内でピアを探す動作となります。ローカルピア検出は以下のような効果があるようです。
「This is important as the DNS-SD option is used to allow local peer discovery, removing the clients need to contact the backend Microsoft Delivery Optimization service in order to be informed about the peers which have content.」
「so the is no seeding slot limits imposed and this can help you achieve much higher DO figures.」
・取得先の優先順位をつける
「ピアツーピアと接続済みキャッシュの両方が構成されている場合、ピアツーピア遅延設定がキャッシュ サーバーの遅延設定よりも優先されます。 この設定を使用すると、配信の最適化でピアを検出してから、接続キャッシュ キャッシュ サーバーのフォールバック設定を認識できます。 」
・配信の最適化が適用される対象
-- 一部抜粋 --
Windows Update (機能更新プログラム、品質更新プログラム、言語パック、ドライバー)
Microsoft 365 Appsと更新プログラム
Edge Browser Updates
Teams (MSIX インストーラー経由)
・配信の最適化のエンドポイント
*.prod.do.dsp.mp.microsoft.com
*.dl.delivery.mp.microsoft.com
*.windowsupdate.com
・配信の最適化で受信許可が必要なポート
TCP/UDP 7680
・配信の最適化をZscalerを使用するときの注意点
Microsoft Connect Cashe
MCCサーバーを用意することで、WSUSのように社内のサーバーから配信という構成にできる。社内ではMCCサーバー、社外ではhttpからダウンロードという構成にできる。また、更新プログラムだけでなく、Microsoft 365 Appsもキャッシュしてくれる。
サーバーマネージャーの役割と機能から、Windows Subusystem for Linuxをインストール。
その後、再起動。
Powershellを管理者モードで開きコマンドを実行。
WSL.exe --update
を実行。
wsl.exe --install --no-distribution
を実行し再起動。
以降のコマンドを実行する前にシステムロケールを英語(米国)に変更しておく。
多分英語環境以外?だとバグがあるっぽい。
以下を見るとprovisionmcconwsl.ps1
実行時のPowerShellが英語表示になっている
こちらでは日本語環境は失敗と書いてあります
こちらでも英語環境にしろという回答があります
以下コマンドを実行。
$User = "$env:computername\Administrator"
$myLocalAccountCredential = "$env:computername\Administrator"
次に、以下ページからコピーして実行
再起動しろと出てきたら再起動
無事インストール完了
しばらく待つとStatusが「Healthy」となる
インストールが完了後はロケールを戻しても大丈夫みたいです。ロケール変更後以下ページの確認方法で確認
クライアントでキャッシュサーバー指定してみる
キャッシュサーバーからデータを取得していることを確認
注意点
・検索欄でwinver
を実行。ビルドが20348.2227以降であることを確認。
・仮想ゲストOSの場合「入れ子の仮想化(Nested Virtualization)」対応をする必要あり
自分の環境はEsxiのため以下を有効化する
Hyper-Vの場合は以下コマンドらしい
Set-VMProcessor -VMName [VMname] -ExposeVirtualizationExtensions $true
Discussion