(13) 久しぶりにCB 上げるよ。
よっぽど気が向かないと行わない MCM(SCCM) CB のリリースアップですが。ぼやぼやしているうちにSystem Centerのかげも形もなくなって Intune一族入りし、盃を交わしたので名前が Microsoft Configuration Manager になったそうです。やれやれ。
今回は CB 2207から、WS2012R2 では最後となる 2309 への更新を行います。
次はベースOSを更新する作業になりますね。
Yutaro Tamai 氏の記事を参考にさせていただきます。
まずは前提条件チェック。OSとSQLサーバのバージョンが「終わってる」話はひとまずおいといて。
Microsoft ODBC driver 18 for SQL が必須コンポーネントになったことと、生HTTP接続がこの先(CB 2403以後)非サポートになるというのが重要です。
なお、氏のブログで示されている early update ring 対応ですが、これはCBリリース直後に更新を行いたいまじめな管理者にのみ必要な作業で、「管理」→「概要」→「更新とサービス」にターゲットリリースがすでに表示されている場合には作業不要という認識でよいみたいです。
ODBCはまあインストールするだけなのですが、外部公開していないSCCM/MCMサーバもHTTPSが必須なの?と思ったら、意外にも(失礼)MSさんは血の通った構成案を提示してくれています。まあ、日本語訳の品質がアレなのですが。ちょっとこの話を掘り下げてみましょう。
画面の下にあるリンクから当該記事を開くとこちら。
https://learn.microsoft.com/ja-jp/mem/configmgr/core/servers/deploy/install/list-of-prerequisite-checks#enable-site-system-roles-for-https-or-enhanced-http
つまりは、
これをOKするだけのように見える。よく同僚の担当外サーバ管理者を連れてきて「OK押すだけやから、簡単やから」と、いかがわしい冗談をやっている場面にしか見えません(←筆者の心が汚れているだけ)
そもそも拡張HTTPとは何ぞやという話ですが。解説がこちら。
https://learn.microsoft.com/ja-jp/mem/configmgr/core/plan-design/hierarchy/enhanced-http
ちゃんとしたサーバ証明書を発行するのが理想ではありますが、「PKI 証明書を管理するオーバーヘッドのため、一部のお客様にとっては困難です」。ブラボー。拍手喝采。
Certificate Authority を真面目に運用しようとしたらどれだけ手間がかかるか。「そんなん簡単やろ」というのはエアプ勢ばっかりです。
しかも。オレオレ証明書ベースなので、EntraID (旧称:Azure AD。未だにAADと書いた資料はネット上あちこちあります)と相互干渉しないので安心してハイブリット認証できますとのこと(もちろん注意は払う必要がある。特にIntune連携を考えている場合は)。
ざっとまとめると、オンプレADを思い浮かべれば(EntraIDしかない環境だとこんなこと考える必要は普通はない)、コンピュータアカウントに紐づくような管理作業にはEntraID + 拡張HTTPで対処可能。ユーザに紐づく情報は、トークンを発行して通信を保護。ただし、以下の通信(これで全部とは言ってないが)は拡張HTTPによる偽物サーバ排除の恩恵は受けないとのこと(言い換えれば、今まで通り)
- コンテンツのクライアント ピア ツー ピア通信 (WindowsUpdateやアプリケーション配布のBranch Cache)
- 状態移行ポイント
- リモート ツール (SCCM リモートコントロールなど)
- Reporting Services ポイント
作業としてはさっきのチェックボックスをONにするだけなんだけど、オレオレ証明書が発行されたかどうかなどは確認しておく必要がありますね。と、なんか自動でいくつか発行されています。ま、設定日以後の変化を確認するのが大事ということで。
さて、ついでに通知も確認しておきますか。
「新機能があるんで金、払ってくださいよぉ」というSPAMばっかりと思ってたら大事なものが紛れ込んでいたというと怖いですしね。上2つは「わかっとるわい」ということで、3つ目から。
「UUPを使うならCB 2203以降に更新してね」
はて、UUPとは?
いわゆるWindows Updateの輻輳防止技術になるのですが、単体のWindows PCがWindows Updateを行う分にはもうすでに実装済みで何も気にしなくてよいようです(Windows11は登場当初から装備)。
問題はMCM/SCCM環境やWSUS環境の場合です。差分の持ち方が変わることで、クライアント側の処理の軽減が行われるのは大歓迎だが、WSUSでのダウンロード時間やストレージ使用量は逆に増大化する可能性があるとのこと(@ITの記事より。要登録)。
なお、UUPのFAQがなかなかの情報量で、英語でボリュームが多いので読むのが大変だが、超訳要約しておきます。間違ってたらごめんなさい。
Q1.UUPテクノロジに対応したパッチは CB2111以前でも適用可能ですか?
A1. 2203以後に上げろっつってんだろ。クライアントがWindows11 22H2(以降)でCB更新後すぐに UUP を使いたいのであれば、MCMのDD(Delta Download)を有効にしておくのがよい(ただし2111以前の状態だとUUP形式のパッチを使うわけではなく、MCMのDD機能で負荷軽減を図る)
Q2. ADR(MCMの自動展開規則)を使っている場合のカテゴリは?
A2. "Security Update"の項目を見てくだされ。
Q3. Adaptiva integrated solutions との互換性は?
A3. Adaptiva 側でパッチがあるのでご確認を。
Q4. WS2012R2上のコンソールでUUPテクノロジパッチを適用すると電子署名の確認エラーになる。
A4. とりま、サーバで2023年4月累積パッチを適用すること。
Q5. *.psf ファイルの検証エラーでパッチダウンローダがエラーを吐く。
A5. CB 2111以前の環境から同期された場合にこの現象が起こる場合がある。簡易検査SQLを実行して問題があればサポートにコンタクト。
Q6 タスクシーケンスのInstall Software Updates ステップで適用するUUPパッチが意図しないタイミングで実行される。
A6 不具合です。CB 2309 で修正されました。
Q7 offlineServicing を有効にしたWindows11イメージで UUP パッチは適用できますか?
A7 ムリです。
Q8 DO(配信の最適化)とDD(Delta download)って何が違うの?
A8 DOはWindowsの機能、DDはMCMの機能です。Windows更新は WUA(Windows Update Agent) → DO → DD の順に命令がいき渡ります。ちなみにグループポリシーでDOを使う構成にしていなくても、MCMでDDが構成されていれば自動的にDOも有効になりMCMの制御下になります。
Q9 UUPパッチの置き換え期間(訳注:WSUSでの未承認期間閾値と思われる。これを過ぎると「置き換えられた更新プログラム」になる)が6か月に変更になったが、どういう影響があるか?
A9 詳細はこちら。この扱いになるのはUUPパッチだけで、それ以前のものには影響しない。
Q10 MCMのパッチ配布で重複排除ってできるの?
A10 いくつかのシナリオに沿う形でなら実現可能(詳細は原文を)。上手にフォルダ構成を作ればjunctionポイントを使ってくれるらしい。
Q11 FoDや言語パックをインストールしたいだけなのに、なんでUUP+WSUS環境だと3〜5GBものコンテンツを取ってくるの?
A11 ディスクには3〜5GBの容量が確保されますが、実際のダウンロードするデータ量はもっと小さいです。「ディスク上のサイズ」をご確認あれ。
Q12 配布ポイントの重複排除は?
A12 配布ポイントのコンテントマネージャにはすでに重複排除機構が実装済み。
話が長くなりました。通知に戻りましょう。
Starting 1st Jan 2024 Resource Access profiles will not function on all versions of Configuration Manager. Check FAQ for the impact based on your configuration.
これは前提条件チェックに出ていたやつでした。
Starting in version 2403, Configuration Manager upgrade will be blocked on Configuration manager hierarchy which are running on Windows server 2012/ 2012 R2 operating system. Upgrade your operating system immediately.
これも前提条件チェックに書いてました。
Your environment has the feature ''Allow Connection Fallback to NTLM'' enabled for client push installation. As a best practice, it is highly recommended to disable it for improved security.
うるせぇ、ほっとけ。イントラ通信でNTLMとめても何もセキュリティ向上にならんわ。
最後の、ここだけいやに日本語なマーケティングメッセージもさくっと無視。
サーバの方は、一度ADK,PEをアンインストールし、最新版を入れ直しして、ODBCドライバもインストールして再起動しておきます。
改めて事前確認を実施。
よし、エラーは消えました。では実行しましょう。
検証用の貧弱なスペックのサーバですが、1時間弱で更新が終わりました。
あとはクライアントのバージョンアップですね。
← 1つ前へ ** 目次に戻る ** 1つ先へ →