SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

WSUS 配下の Windows 10 における CB / CBB の適用制御の検証 (2016/8 時点)

leave a comment

Windows 10 に、1607 (Anniversary Update : Redstone 1 (RS1)) がリリースされ、バージョン番号が変わる CB/ CBB の検証ができるようになりましたので自分の理解の整理を兼ねて。

関連情報の整理

かなり、情報が出てきましたので最初に関連情報の整理を。
直近の情報となると、赤間さんが公開された エンタープライズ企業における Windows 10 導入と WaaS 適用の要点? の一連のシリーズが必読のドキュメントになるかと。
企業内の展開のリリースサイクルを考える場合には、Part 3. WaaS の正しい理解 のサイクルを理解する必要があります。
リリースについて
リリースについての基本的な情報については、以下を参照することになるかと思います。

更新用の ISO の入手
各クライアントが直接アップグレードを行う場合は、以下のモジュールを使用することになるかと。
Windows 10 のダウンロード
Windows 10 のディスク イメージ (ISO ファイル) のダウンロード
 
WSUS を使用してた Upgrade の配信
WSUS を使用する場合、WSUS サーバーからの Windows 10 へのアップグレードの配信 に記載されているように、

が必要となります。
# KB3159706 は情報の公開当初なかった記憶があるのですが、追加されたみたいですね。
私が使用しているのは Windows Server 2016 TP4 の WSUS なのですが、こちらを使用している場合は、自分の検証シナリオの範囲では、特に追加の KB を導入することなくアップグレードができていそうではありました。
Windows Update for Business (W4B)
通常、CB → CBB へは 4 か月の猶予期間がありますが、Windows Update for Business (W4B) の仕組みを使用することで、各適用期間を以下のように延長することができます。
# 「アップグレードを延期する」の設定と併用が必要かは、要調査。

  • アップグレード (機能更新 (TH2 → RS1 というような変更) の適用) は最長 8 か月延長可能
  • アップデート (更新プログラムの適用) は最長 4 週間延長可能

実際の設定については、グループポリシーで制御を行う必要があり、これについては セットアップと展開 に記載されていますので、使用する場合にはこの情報を確認します。
グループポリシーについては、Windows 10 1511 向けのグループポリシーテンプレートに含まれていますので、使用する場合にはこのポリシーテンプレートの利用を行います。
Administrative Templates (.admx) for Windows 10 – 日本語
試してみた感じでは、設定は 1511 以降の環境でのみ使用できていそうですので、RTM 直後の 1507 だと動作しなさそうでした。
当初、W4B は WSUS 等の、Windows Update を直接使用する仕組み以外とは、組み合わせないとい仕様になっていたかと思います。
Windows Update for Businessってどうなったの? (1/2)
その後、山市さんが RS1 がリリースされた後に検証された結果を、Windows 10 の更新方法、WSUS と Windows Update for Business は共存できるかも で公開してくださっていますが、実際に検証してみた際には、WSUS でも W4B の設定を利用して制御ができていたようですので、「Windows Update 以外の更新機構 + W4B」 については引き続き情報のウォッチが必要となるかと。
KMS を使用している場合
MAK ではなく、KMS を使用して認証をしている場合は、レジストリの設定をしないとアップグレードが認識しないことがあるそうですので、KMS を使用している場合には、 Windows 10 Enterprise で Windows Update を開くと、Windows 10 version 1511 が検出されない場合の設定について も確認をしておく必要があります。
 

検証実施時のメモ

こちらは私が検証を実施した際のメモですが。
Windows Update のキャッシュについて
クライアント側の Windows Update で認識する更新プログラムですが、たしか、キャッシュがされており即時には適用対象を認識できないというような挙動をすることがあったはずです。
検証を実施する際にはキャッシュされていることを意識し、数10分の間隔をあえて再度確認や、Windows Update クライアントの情報をクリアにする手順 によるキャッシのクリアについても検討した方がよかったかと。
スナップショットを組み合わせて検証している場合は、初回の認識からのタイムラグが吸収できることもあるようですので、「いつ初回の同期が行われたと記憶されている端末か」は意識の片隅に置いておくと、
設定の切り替えのスクリプト
以下は自分が使っていたものとして。

# アップグレードを延期する (CB → CBB への変更)
Set-ItemProperty  -Path "registry::\HKLM\software\microsoft\windowsupdate\UX\Settings" -Name "DeferUpgrade" -Value 1
# W4B の設定 (アップグレード (機能更新) を 8 か月延長する)
New-Item "registry::\HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate"
Set-ItemProperty  -Path "registry::\HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate" -Name "DeferUpgradePeriod" -Value 8

 

リリースタイミングの把握

CB / CBB のリリースサイクルを把握するためには各製品のリリースのタイミングを把握しておく必要があります。
正式な情報としては、Windows 10 のリリース情報? を確認していただければ。

  • Windows 10 1507 (10240) : Threshold 1 (TH1)
    • 2015/7/29 リリース
      • 2015/7/29 リリース時点で、CB でもあり、CBB でもあるがこれは例外
  • Windows 10 1511 (10586) : Threshold 2 (TH2)
    • 2015/11/12 リリース
      • TH1 リリースの 4 か月後にリリースされたバージョン
    • リリース 4 か月後の、2016/4/8 CBB となる
  • Windows 10 1607 (14393) : Redstone 1 (RS1)
    • 2016/8/2 リリース
      • TH2 リリースの 約 8 (とみるか 9 とみるか) か月後にリリースされたバージョン
    • リリース 4 か月後の2016/12 ごろに CBB となる予定

詳しくは冒頭で紹介した赤間さんのブログを参照していただければと思いますが、2016/8 時点では、

  • CB : 1607 (Redstone 1)
  • CBB : 1511 (Threshold 2)

となっているかと。
 

Windows 10 1507 を起点とするとどうなるか

今回の検証環境では、WSUS では以下の 2 種類の機能更新を承認済みの状態にしています。
image
2016/8 時点では、

  • CB : 1607 (Redstone 1)
  • CBB : 1511 (Threshold 2)

となっていますので、「アップグレードを延期する」の設定によって、適用される対象が変わってきます。

  • 設定が無効 (CB の状態) : 1607 が適用対象として選択される
  • 設定が有効 (CBB の状態) : 1511 が適用対象として選択される

となり、WSUS で両方のアップグレードが承認されていても、クライアントの設定によって、適用対象として認識されるものが変わってきます。
# Windows Update を直接使用している場合は、どちらの設定でも、1507 → 1511 というアップグレードの認識となっていましたが、RS1 がリリースされたばかりなので、この辺は今後変わってきそうな気がしますが。
1607 が CBB となると想定される 2016/12 になると、この動作が変更され、どちらの設定にしても 1607 がダウンロードされるようになるのかと。
2016/8 時点では、「アップグレードを延期する」が有効な場合は、1511 のアップグレード後に WSUS に対して更新プログラムの取得を行っても、1607 は適用対象となりません。
「アップグレードを延期する」を無効にすることで、適用対象が CB となるため、1607 が適用対象となります。
CB / CBB の運用が想定通りに実施できている形になるかと。
動作を見ていると WSUS 運用では以下のような形となるのでしょうか??(未確認ですが)

  • DeferUpgrade : 使用可能
  • DeferUpgradePeriod : 使用不可
  • DeferUpdatePeriod : 使用不可
  • PauseDeferrals : 使用不可

Windows Update 時のレジストリのアクセスを見ていると、WSUS 配下の場合も「DeferUpgrade」へのアクセスが行われているのは確認できたのですが、他のアクセスについては確認できませんでした。
# WSUS ではなく、Windows Update に接続している場合も確認できなかったので、調べ方が悩ましいですが。
 
WSUS で運用をした場合、WSUS 側で Upgrade のカテゴリを承認しなければ特定のバージョンで使用するということもできるはずですが、Part 3. WaaS の正しい理解? に記載されている

各機能アップグレード(TH1, TH2, RS1, RS2,…)に対するパッチ提供は、n+2 バージョンの CBB がリリースされるまで行われる

  • よって、どんなに遅くても n+2 バージョンの CBB がリリースされるまでに(脆弱性パッチが提供されなくなるので)アップグレードを行う必要がある。

の制約にかかるはずですので、n+2 バージョンの CBB リリース (RS1 の CBB が該当するのかと思いますが) されたタイミングで、1507 に対しての修正プログラムの公開が行われなくなり、セキュリティを考慮すると 1511 or 1607 にアップグレードせざるを得なくなるかと。
Windows 10 向けの更新プログラムは、1507 / 1511 / 1607 ようにわかれているのもこの辺の動作に起因しているのかと。
1607 へのアップグレードですが、KB3159706? のインストールと KB に書かれている手動ステップを実行しないと、「更新プログラムをインストールする準備をしています」が 0% の状態から進まず「0xC1800118」のエラーが発生してしまい、更新プログラムとして認識はしているのですが適用ができない状態となってしまっています。
# WSUS 側の設定が正常にできていれば、「更新プログラムをインストールする準備をしています」のステップで進捗が進み、Modern Setup Host によるインストールが開始されました。
# 0% から 1% に進むのが時間がかかりますが。
image
エラー発生時には、WindowsUpdate.log には、以下のような出力がされます。
# esd の展開ができないというエラーが出力されます。

2016/08/22 19:26:42.5581008 4544  396   Handler         * START *   Windows Setup Install
2016/08/22 19:26:42.5581016 4544  396   Handler         Updates to install = 1
2016/08/22 19:26:42.5599229 4544  396   Handler         Loaded state. m_dwState now: Setup360_CompatToolPhase2(9)
2016/08/22 19:26:42.5603211 4544  396   Handler         Starting Windows Setup with command line = C:\Windows\SoftwareDistribution\Download\238a3c748411624b8ed7072edcaec42d\WindowsUpdateBox.exe" /ClassId 255e1b29-ec74-4640-be55-ac3ebb481221 /ReportId {1608C0BB-6A75-4D24-BEEE-211416C19F42}.201 /Install /Update /ClientId f6708f8c-f8b7-481b-b327-4d6d37f4a55f"
2016/08/22 19:26:42.5603219 4544  396   Handler         HandlerSecsInADay = 86400.
2016/08/22 19:26:42.5603224 4544  396   Handler         Registering WinSetup COM server as CLSID {255E1B29-EC74-4640-BE55-AC3EBB481221} and APPID {8D1E441A-877C-4E14-846F-359386A4CADB}
2016/08/22 19:26:42.5613679 4544  396   Handler         Successfully registered WinSetup COM server as CLSID {255E1B29-EC74-4640-BE55-AC3EBB481221}
2016/08/22 19:26:44.0947568 800   2972  Misc            Got WSUS Reporting URL: http://10.198.0.1:8530/ReportingWebService/ReportingWebService.asmx""
2016/08/22 19:26:44.0948255 800   2972  WebServices     Auto proxy settings for this web service call.
2016/08/22 19:26:44.6595197 4544  4896  Handler         Requested file 14393.0.160715-1616.rs1_release_CLIENTPRO_RET_x64fre_ja-jp.esd has no decrypt information
2016/08/22 19:26:46.9507488 4544  4896  Handler         Deleting setup file '14393.0.160715-1616.rs1_release_CLIENTPRO_RET_x64fre_ja-jp.esd'
2016/08/22 19:26:56.5285285 4544  396   Handler         Installer completed. Process return code = 0x80248008, result = 0x80248008, callback pending = False
2016/08/22 19:26:56.5285699 4544  396   Handler         Handler: Setup360 returned unknown error 80248008 for state 9, resetting state to Unknown
2016/08/22 19:26:56.5285708 4544  396   Handler         State changed. was: Setup360_CompatToolPhase2(9), now: <invalid>(0)
2016/08/22 19:26:56.5287933 4544  396   Handler         Saved state. m_dwState: <invalid>(0)
2016/08/22 19:26:56.5289815 4544  396   Handler         Exit code = 0x80248008
2016/08/22 19:26:56.5289830 4544  396   Handler         * END *   Windows Setup Install

 
関連する情報としては以下のようなものが。
WSUSを使って1511から1607へアップグレードするとエラー(0xc1800118)となる
Anniversary 1607 update error 0xc1800118
私の環境では、WSUS 側で以下の対応をすることで 1607 の配信を実施することができました。

  1. KB3095113 をインストール
  2. esd の MIME (application/octet-stream) を追加
  3. KB3159706 をインストール
    https://catalog.update.microsoft.com/v7/site/Search.aspx?q=KB3159706 から入手したモジュールをインストール
  4. KB3159706 の手動ステップを実施し、WSUS のサービスを再起動
  • “C:\Program Files\Update Services\Tools\wsusutil.exe” postinstall /servicing の実行
  • HTTP Activation の追加
  • WSUS のサービスの再起動
    • Restart-Service WsusService
  • Upgrade のカテゴリから 1607 を承認しダウンロード
    • KB3159706 の対応を実施してから 1607 を承認し、ダウンロードしないと、上述のエラーが発生した状態を解消できなかった。
Share

Written by Masayuki.Ozawa

8月 22nd, 2016 at 11:40 am

Posted in Windows Client

Tagged with

Leave a Reply