こんにちは。WSUS サポート チームです。

今回のポストでは、WSUS サーバーのバージョン番号についてご紹介いたします。
2016/2/16 時点において、サポートされている WSUS は、WSUS 3.0 SP2、Windows Server 2012 / 2012 R2 WSUS がありますが、内部的なバージョン番号はそれぞれ異なります。
以下の表にまとめましたので、お使いの WSUS サーバーのバージョン番号をご確認いただく際にお役立てください。

WSUS 3.0 SP2

※ WSUS 3.0 SP2 で Windows 8 / Windows Server 2012 以降を管理するためには、KB2720211 以降の更新プログラムの適用が必要です。なお、WSUS 3.0 SP2 の更新プログラムは累積ですので、最新の更新プログラムを適用すれば、以前の修正内容も含まれます。

Windows Server 2012 WSUS

Windows Server 2012 R2 WSUS

※ KB3095113 は、Windows 10 の機能アップグレードを配信するために必要です。詳しくはこちらのブログ記事をご確認ください。なお、Windows Server 2012 / 2012 R2 の WSUS の更新プログラムは累積ではありませんので、それぞれ適用してください。
また、Windows Server 2012 R2 WSUS においては、Windows Server 2012 R2 用の 2014 年 11 月のロールアップ KB3000850 にも WSUS の問題に対する修正が含まれています。KB3000850 を適用しても、バージョン番号は変わりません。KB3000850 で修正された問題については、こちらのブログ記事をご確認ください。

WSUS のバージョン番号は WSUS 管理コンソールの以下の箇所からご確認いただけます。

 
※ WSUS 3.0 SP2 では、メニュー バーの [ヘルプ] – [Update Services のバージョン情報] から確認できるバージョンは KB を適用しても、3.2.7600.226 のままとなりますので、バージョン情報は上記箇所よりご確認ください。

みなさま、こんにちは！WSUS サポートの本田です。

私も WSUS のサポートをはじめてから今では 4 年が経過しましたが、今回は WSUS に関するエラーの中で最もお問い合わせが多いものをご紹介させていただきます。

それは、このエラーです！

「みたことある！」という方も非常に多いのではないでしょうか。特に長期間運用している環境においては、起動するたびに発生するといったことも少なくないかと思います。
このエラーは単純に「接続エラー」を示すものですので、以下のように発生パターンによって、異なる対処方法を検討する必要があります。

パターン 1. WSUS 管理コンソールを起動すると、必ずエラーが発生する。
パターン 2. 毎回ではないが、WSUS 管理コンソールの起動時や「すべての更新プログラム」ビューを開くときに、エラーが発生しやすい。

パターン 1. の場合は、WSUS 管理コンソールが永続的にデータを参照できない状況に陥っています。WSUS 管理コンソールは WSUS に対して、HTTP/HTTPS で通信しますので、ネットワーク障害が要因である可能性も考えられますが、多くの場合は以下の状況に起因しています。

1. WSUS が使用する IIS アプリケーション プール WsusPool が停止している。
2. WSUS データベース (SUSDB) をホストする SQL のサービス (Windows Internal Database、もしくは SQL Server) が停止している。

そのため、永続的に接続エラーが発生する場合は、まず IIS のサービス (World Wide Web Publishing Service) や SQL のサービスの再起動を試してください。

さて、最も多いのがパターン 2. ですが、これは障害というより「パフォーマンス不足」に起因しております。
WSUS 管理コンソールは、WSUS の Web サービスを通して、SUSDB より情報を取得し、管理コンソール上に表示しておりますが、その情報の取得に時間がかかる場合に、接続エラーとなってしまい表示できないことがあります。
この場合、何度か試みることで表示されるようになることもありますが、パフォーマンスを改善しない限り、表示が不安定な状況が続きます。

「パフォーマンス不足」に起因するこの状況に対して残念ながら根本的な対処策はありませんが、パフォーマンスを改善するための手段はいくつかあります！
ここでは、「WSUS 管理コンソールにつながらない！」を解消するための 6 つのワザと題して、当サポート部門が蓄積しているワザをご紹介しちゃいます。

まずは基本ワザから・・・

1.「インデックスの再構築」を実施する

本ブログの読者の皆様やサポートに問い合わせていただいたことがある方は、ご存知の方も多いと思いますが、WSUS を運用する上で、このメンテナンスは必要不可欠です！
WSUS は残念ながら、独自に SUSDB をメンテナンスする機能を有していないので、長期運用を続けることで SUSDB にデータの登録や削除が繰り返されると、インデックスの断片化が進みます。インデックスが断片化した状態においては、構築当初と比較してクエリ パフォーマンスが劣化し、動作遅延や接続エラーの多発につながります。そのため、弊社では月に 1 回は定期的に「インデックスの再構築」を実施いただくことをお勧めしております。詳しい手順は、こちらのブログ記事にて紹介しておりますので、ご確認ください。(スクリプト内では、インデックスの断片化比率に応じて、インデックスの再構築や統計情報の更新を行っています。)

2.「WSUS サーバー クリーンアップ ウィザード」を実施する

こちらも「インデックスの再構築」と同じく定期的な実施をお勧めしています。WSUS は同期した更新プログラムの情報を蓄積し続けるシステムです。そのため、一度データベースに格納された更新プログラムの情報は、基本的に削除できません。但し、唯一削除可能な方法として「WSUS サーバー クリーンアップ ウィザード」があります。
「WSUS サーバー クリーンアップ ウィザード」は、左ペインのオプションを選択すると、中央ペインに表示される一覧より選択できます。ウィザードでは 5 つのオプションを選択可能ですが、データベースから更新プログラムの情報を削除するオプションは、一番上の「不要な更新プログラムと更新プログラムのリビジョン」です。そのため、データベースからできる限り不要な更新プログラムの情報を減らしたい場合は、「不要な更新プログラムと更新プログラムのリビジョン」を選択して、ウィザードを実行してください。

その他のオプションも不要な情報を減らすという観点では有効ですが、たまに発生する接続エラーの改善という観点では大きな効果を得られないことが多いです。そのため、ここでは言及いたしません。

ちなみに、「WSUS サーバー クリーンアップ ウィザード」を実施する前には、上述の「インデックスの再構築」を実施することをお勧めします。これもインデックスが断片化しており、クエリ パフォーマンスが劣化している状態では、クリーンアップ ウィザードもタイムアウトで失敗することが多いため、事前にタイムアウトによる失敗を緩和することが目的です。それでもウィザードが最後まで終わらない場合は、「インデックスの再構築」->「クリーンアップ ウィザードの実行」の繰り返しです。

3. WSUS 管理コンソールのキャッシュを削除する

WSUS 管理コンソールは MMC の上で動作していますが、以下にキャッシュ ファイルが存在しています。

%appdata%\Microsoft\MMC\wsus

このキャッシュ ファイルを削除すると、これまで作成した更新ビューも削除されますが、”気持ち” 早くなります。なので、あまり大きな効果は得られませんが、できる限り早くしたい！というときにお使いください。。。

続いて応用ワザ！ここからは、パフォーマンス チューニングを含みます。

4. 不要な更新プログラムをできる限り「拒否済み」にする

上述の通り、WSUS は更新プログラムのデータを蓄積し続けるシステムですので、過去に同期対象としてチェックした後、現在はチェックを外した製品であっても、SUSDB に格納された更新プログラムは残存します。(クリーンアップ ウィザードで削除されるものもあります。) このような配信が不要な更新プログラムが「未承認」や「インストール承認」の状態であった場合、WSUS クライアントが「更新プログラムの確認」を行う処理において検出対象となり、スペックが低い PC の場合は確認処理の完了までに時間がかかるといった事象が発生することがあります。(※)
また、サーバー側においても、クライアントから「更新プログラムの確認」の要求を受けて、クライアント側に返す更新プログラムの情報量が多くなるため、処理負荷がかかります。

そのため、配信が不要となった更新プログラムが「未承認」や「インストール承認」の状態のままである場合は、「拒否済み」のステータスに変更することで、WSUS クライアントの検出対象から外して、処理負荷を軽減することができます。不要な更新プログラムの判断方法としては、下記のような例があります。

1. 現在は使用していない製品に該当する更新プログラム (Windows XP、Office XP など)
2. Itanium ベース システム用の更新プログラム (WSUS の管理対象に Itanium ベースの CPU を搭載したサーバーが含まれていない場合)
3. 置き換えられた更新プログラム

「3. 置き換えられた更新プログラム」については、WSUS 管理コンソール上で [すべての更新プログラム] などの更新ビューを開き、中央ペインの列名で右クリックして [優先] 列を表示させることで、「置き換えられた」更新プログラムかどうかを確認することができます。

「置き換えられた」更新プログラムの場合は、以下のアイコンが表示されます。

 : この更新プログラムが別の更新プログラムを置き換えた後に、さらに別の更新プログラムによって置き換えられていることを表しています。
 : この更新プログラムが置き換える更新プログラムはありませんが、別のプログラムによって置き換えられていることを表しています。

なお、 のアイコンやアイコンの表示がない更新プログラムについては、他の更新プログラムによって置き換えられておりませんので、こちらは「拒否済み」に設定しないようご注意ください

5. WsusPool の「プライベート メモリ制限」を引き上げる

リリースされた更新プログラムの数も多くなったからか、Windows Server 2012 WSUS 以降、この方法をご案内することも多くなりました。上述の通り、WSUS は IIS のアプリケーション プールとして WsusPool という独自のものを使用していますが、このアプリケーション プールがリサイクルするまでにワーカー プロセスが使用できるプライベート メモリの最大容量が、既定では 1843200 KB (約 1.8 GB) に設定されています。そのため、WSUS における同期や承認の設定、多数のクライアントからの更新プログラムの取得処理などが重なって、WsusPool が使用するメモリが多くなると、繰り返しリサイクルが発生し、動作が重くなることがあります。(場合によっては、WsusPool が停止することもあります。) 空きメモリに余裕があれば、この「プライベート メモリ制限」を引き上げることで、リサイクルが発生するまでの間隔が長くなり、動作が安定します。
設定箇所は、IIS マネージャーを起動して、左ペインから [アプリケーション プール] を選択してください。中央ペインの一覧から [WsusPool] を右クリックして [詳細設定…] をクリックすると、以下の箇所で設定を変更できます。当サポート部門の実績では 4000000 (4 GB) に設定いただくことで安定することが多く、それでも安定しない場合は 8000000 (8 GB) に設定いただくことも稀にあります。

6. SUSDB をホストする SQL インスタンスの最小サーバー メモリ、最大サーバー メモリを設定する。

SUSDB をホストする SQL も使用するメモリの最小値と最大値を設定することができますので、ここもパフォーマンス チューニングのポイントの 1 つです。最大サーバー メモリは空きメモリの状況に応じて設定していただきますが、最小サーバー メモリについては 1024 MB (1GB) に設定していただくことで安定したという実績があります。設定箇所は SQL Server Management Studio で SUSDB をホストする SQL インスタンスに接続します。左ペインから一番上のサーバー名を右クリックして [プロパティ] をクリックすると、以下の箇所で設定を変更できます。設定変更後は [OK] をクリックしてください。

なお、Windows Internal Database (WID) を使用している場合は、SQL Server Management Studio でプロパティを開こうとするとエラーが発生します。その場合は、以下の手順で設定してください。

- 事前準備
sqlcmd ユーティリティーをダウンロードし、WSUS サーバーにインストールします。[＋インストール方法] をクリックして、Microsoft SQL Server 2012 コマンド ライン ユーティリティより、「X64 パッケージ (SqlCmdLnUtils.msi)」をダウンロードして、インストールしてください。なお、sqlcmd ユーティリティーのインストールの前提条件として、SQL Server Native Client がインストールされている必要があります。

WID を利用する WSUS 環境においては、SQL Server Native Client はインストールされません。sqlcmd ユーティリティーをインストールする前に sqlncli.msi をダウンロードいただき、対象の WSUS サーバーにインストールしてください。

- 手順
例として最小サーバー メモリを 1024 MB に設定する手順を紹介します。

1. コマンドプロンプト を “管理者として実行” にて起動します。
2. sqlcmd で WID に接続します。

- WSUS 3.0 SP2 の場合
sqlcmd -E -S \\.\pipe\mssql$microsoft##ssee\sql\query

- Windows Server 2012 / 2012 R2 WSUS の場合
sqlcmd -E -S \\.\pipe\MICROSOFT##WID\tsql\query

3. 以下のコマンドを実行します。

EXEC sp_configure 'show advanced options',1
GO
Reconfigure
GO
EXEC sp_configure 'min server memory',1024
GO
Reconfigure
GO

4. 以下のコマンドを実行し、run_value が設定された値になっていることを確認します

EXEC sp_configure 'min server memory'
GO

出力例)
name                                minimum     maximum     config_value run_value
———————————– ———– ———– ———— ———–
min server memory (MB)                        0  2147483647         1024        1024

5. exit を入力し、sqlcmd を終了します。

※ 最大サーバー メモリを設定する場合は min server memory を max server memory に置き換えてください。

いかがだったでしょうか。このようなワザは TechNet などの公開情報では紹介されておりませんが、運用中のお客様に対して我々サポート部門からご提案することが非常に多いものばかりですので、是非とも WSUS の安定運用を図るためにも取り入れることをご検討ください！

皆さま、こんにちは。WSUS サポート チームです。

WSUS で更新プログラムを管理されている皆さまの中には、「間違った更新プログラムを配信してしまった！削除したい！」という状況になった方もおられるのではないでしょうか。
そのような状況において、WSUS で有効な機能が「削除の承認」です。この機能はあまり知られていませんが、WSUS で配信した更新プログラムをクライアント PC からアンインストールすることができます。
更新プログラムの中には「削除の承認」ができないものもありますが、更新プログラムを削除する方法の 1 つとして有効です。

KB3139940を例として WSUS より「削除の承認」を行う手順を以下にご紹介します。WSUS で配信した更新プログラムを削除したいときに、是非ご活用ください！

手順

1. WSUS サーバーにログインします。
2. [スタート] – [管理ツール] – [Windows Service Update Services] をクリックします。
3. WSUS 管理コンソールが起動しますので、左画面から、[セキュリティ更新プログラム] をクリックします。
4. 中央画面の上部から、”承認” を [拒否された更新以外のすべて]、”状態” を [すべて] に設定し、[最新の情報に更新] をクリックし画面を更新します。
5. 中央画面のリストから、削除対象とする更新プログラムである KB3139940を見つけます。
6. 対象の更新プログラムを右クリックして、[承認] をクリックします。
7. “更新の承認” 画面が起動しますので、更新プログラムを削除したい PC を含むグループのドロップダウンから、[削除の承認] をクリックします。

8. [OK] をクリックして、画面を閉じます。

9. WSUS クライアントは定期的に WSUS サーバーへ接続を行いますので、そのタイミングで自動更新の設定に基づいてアンインストールを行います。
(「削除の承認」が行われた場合、グループ ポリシー「自動更新を構成する」のオプション 4 番「自動ダウンロードしインストール日時を指定」で設定した日時にアンインストールされます。)

なお、「削除の承認」に対応していない場合は、手順 7. の [削除の承認] がグレーアウトして選択することができません。そのため、[削除の承認] がグレーアウトしているかどうかをご確認いただくことで、WSUS で対象の更新プログラムを削除できるかどうかご判断いただけます。

(補足)
手順 1. ～ 5. の更新プログラムを見つける手順は、以下の手順でも代用可能です。

1. WSUS 管理コンソールを起動して、左ペインのツリーより [更新] をクリックします。
2. 右ペインの [検索…] をクリックします。
3. 検索ボックスに KB3139940と入力して、[検索] をクリックします。
4. 検索結果に KB3139940 に一致する更新プログラムが表示されますので、削除対象とする更新プログラムを見つけます。

みなさま、こんにちは。WSUS サポート チームです。

今回は最近お問い合わせが増えてきた「Windows Update がなかなか終わらない！」「Windows Update の実行が重い！」問題について紹介します。

Windows Update を実行すると下記の「更新プログラムを確認しています…」の画面のままで、数十分 ～ 数時間も結果が返ってこないような場合には是非ご一読ください！

この問題は更新プログラムが多くリリースされている Windows 7 の環境で多くの報告がされています。特に OS インストール直後に Windows Update を実行すると数時間なんの応答もない！といったお問い合わせがあります。

Windows Update による更新プログラムの処理対象が多い環境では、どうしても処理対象の件数が多く、処理が長くなってしまうのですが、それにしても「うわっ…私の Windows Update、長すぎ…？」と思ったら、まずは Windows Update を実行する前に、下記に 2 つの更新プログラムを手動で先に適用してみてください。

- 最新の WUA (Windows Update Agent) の更新プログラム

- 最新の IE (Internet Explorer) の累積的なセキュリティ更新プログラム

- (補足) WSUS 環境の場合に、さらに時間を短縮するためのワザ

Windows Update 環境では、上記の 2 つの更新プログラムを適用を行った後に Windows Update を実行すると、数時間なんの応答もなかった環境でも 20 分程度で処理を完了出来たとの報告も多くあります。

なお、WSUS を利用している環境の場合には、WSUS サーバー側で公開する更新プログラムの数を絞ることで、処理時間を短縮することが可能ですので、こちらの方法も補足として紹介します。

最新の WUA (Windows Update Agent) の更新プログラム

WUA のパフォーマンスは日々改善を行ってますので、最新の WUA に更新することで、Windows Update の実行速度を上げることが出来ます。本ブログ執筆時点での最新の WUA の更新は下記ですので、まずは下記の更新プログラムが適用されていない場合には、下記を適用しましょう。

- Windows 7 および Windows Server 2008 R2 用 Windows Update クライアント : 2016 年 3 月
https://support.microsoft.com/ja-jp/kb/3138612

- Windows 8.1 のクライアントと Windows Server 2012 R2 の更新: 2016 年 3 月
https://support.microsoft.com/ja-jp/kb/3138615

※ WSUS 3.0 SP2 環境をご利用の場合の注意点 ※

WSUS のバージョンが「3.2.7600.226」の 場合、上述の WUA の最新の更新をクライアントへ適用するとWUS サーバーとクライアントの通信に問題が発生しますため、ご注意ください。本問題については、下記のブログにて紹介をしております。

- WSUS クライアントがエラー 0x800B0001 で更新プログラムの検出に失敗する
https://blogs.technet.microsoft.com/jpwsus/2012/07/05/wsus-0x800b0001-22833/

本問題を避けるためには、WUA の更新を行う前に WSUS サーバーへ更新プログラムを適用する必要がございます。WSUS の最新の更新プログラムの情報やご利用いただいているバージョンの確認方法は、下記のブログにて紹介しておりますため、もし WSUS のバージョンが「3.2.7600.226」の 場合には、下記ブログを参照の上、最新の WSUS の更新を適用してください。(2016/4/26 時点で最新の WSUS 3.0 SP2 用更新プログラムは、KB2938066 です。)

- WSUS サーバーのバージョン番号について
https://blogs.technet.microsoft.com/jpwsus/2016/02/16/wsus-18/

最新の IE (Internet Explorer) の累積的なセキュリティ更新プログラム

次に Windows Update の中でも、特に処理が重くなり易い IE の累積的なセキュリティ更新プログラムを先にクライアントに適用します。下記の手順にて月々リリースされる IE の累積的なセキュリティ更新プログラムの中から、最新のものを探し出しインストールをします。

– 手順 –

1. 下記のサイトに IE で接続します。
   – Microsoft Update カタログ
   http://catalog.update.microsoft.com/
   ※ なお、Microsoft Update カタログに初回にアクセスする際、ブラウザに ActiveX コントロールのインストールが必要になりますので、ご注意ください

2. 検索ボックスで「“<利用している IE バージョン>” “<利用している OS バージョン>” 累積」で検索します。例えば Windows 7 の環境で Internet Explorer 11 を利用している場合は、下記の通り入力し、検索をします。

3. 検索結果の一覧にて [最終更新日時] をクリックして、結果をソートします。

4. [最終更新日時] の順にソートされた結果の中から、今回利用している IE バージョンおよび利用している OS バージョンに沿ったものを選択し、[追加] をクリックします。

5. [バスケットの表示] をクリックして、[ダウンロード] をクリック、対象の更新プログラムを任意のフォルダにダウンロードします。

上記の手順でダウンロードした更新プログラムを Windows Update を実施する前に適用します。

ちなみに「なんで IE の累積的なセキュリティ更新プログラムを適用すると Windows Update の実行が早くなるの？」と疑問に思われた方は、下記ブログの「発生要因」の項目を読んでください。下記のブログ自体は WSUS 環境に向けて公開しているブログですが、WUA の仕組みは同じなので IE の累積的なセキュリティ更新プログラムを先行してインストールすることが Windows Update の実行時間を短縮するためには効果的です。

- 古い「IE の累積的なセキュリティ更新プログラム」が承認されていると、更新プログラムの検出処理時に WSUS クライアントの CPU 使用率が高くなる
https://blogs.technet.microsoft.com/jpwsus/2015/04/27/ie-354/

(補足) WSUS 環境の場合に、さらに時間を短縮するためのワザ

さてここからは WSUS 環境の場合にのみ使えるワザを紹介します。

WSUS の環境であれば、クライアントへ公開する更新プログラムの数自体を減らしてしまえば、Windows Update の処理時間を短縮することが可能です。このため、対処として WSUS サーバー上の不要な更新プログラムを「拒否済み」という、クライアントから完全に参照出来ない状態にすれば、さらに Windows Update の処理時間が短くなります。

この対処の方法については、下記ブログの ”4. 不要な更新プログラムをできる限り「拒否済み」にする” にて紹介していますので、WSUS 環境で Windows Update がなかなか完了しないと思ったら、この対処を実施してみてください！

- 「WSUS 管理コンソールにつながらない！」を解消するための 6 つのワザ
https://blogs.technet.microsoft.com/jpwsus/2016/02/24/wsus-1-2/

いかがだったでしょうか。上記の対処は技術的な裏付けもあり、弊サポート チームで多くの実績がある方法ですので、Windows Update の実行が終わらないと思ったら、是非とも試してみてください！

皆さま、こんにちは。WSUS サポート チームです。

今回は 2016/5/4 にリリースされた Windows Server 2012 / 2012 R2 WSUS 用の更新プログラム KB3159706 についてご紹介いたします。KB3159706 は Windows Update に公開されている WSUS 用の更新プログラムですが、適用後に手動の手順が必要となる更新プログラムです。必要となる手動の手順は KB3159706 内でもご紹介しておりますが、適用後手動の手順を行わなかった場合に、WSUS 管理コンソールに接続できない、WSUS Service が起動しないという事象が発生しますので、本ブログ記事においても詳細にご説明いたします。なお、KB3159706 は、WSUS 3.0 SP2 には提供されておりませんので、WSUS 3.0 SP2 環境に適用されることはありません。

KB3159706 について

Windows 10 の機能アップグレード (WSUS では “Upgrades” に分類される更新プログラム) は、暗号化されたパッケージの形式で実際のリリースより前に Windows Update に公開されます。これは、すべての地域に対して同時にリリースできるようにすることを目的としています。Windows 10 のクライアントは、最初にリリースされたバージョンから暗号化されたパッケージを復号することができましたが、WSUS では復号する機能を有しておりませんでした。そのため、今まで機能アップグレードを WSUS に公開するに当たり、暗号化されたパッケージを手動で復号して WSUS 用に公開しておりましたが、このプロセスは時間を要する作業であり、エラーが発生する要因となっておりました。KB3159706 は、Windows Server 2012 / 2012 R2 の WSUS に暗号化されたパッケージを復号する機能を追加した更新プログラムです。この KB3159706 を適用しない場合、2016 年夏にリリース予定の Windows 10 Anniversary Update など、2016 年 5 月以降に WSUS に公開される機能アップグレードについて、WSUS で配信することができません。(注 : Windows Server 2016 では、リリース時から本機能を組み込む予定です。)

KB3159706 の展開方法について

KB3159706 は、WSUS や Microsoft Update カタログに公開されておりますので、KB3159706 が同期済みか、手動で KB3159706 をインポートしていれば、WSUS を利用して展開することができます。また、WSUS を利用して展開できない方々に向けて、Windows Update に対しても KB3159706 を公開しております。もし Windows Update から KB3159706 を適用する場合は、オプションに KB3159706 が表示されますので、チェックをオンにしてインストールしてください。

KB3159706 を適用した後に必要な手動手順について

KB3159706 は適用した後に、手動の手順を実施することでインストールが完了します。手動の手順を実施していない場合、WSUS 管理コンソールに接続できない、WSUS Service が起動しないという事象が発生します。そのため、意図せず KB3159706 が適用された場合は、お手数をおかけしますが、以下の適用後に必要な手動手順の実施をお願いします。(KB3159706 内でもご紹介している手順です。)

この更新プログラムのインストールを完了するために必要な手動の手順
WSUS サーバーで以下の手順を実施してください。なお、本手順はシステム ボリュームが C ドライブであることを前提としています。
(本記事内のコマンドをコピー ペーストすると、ダブル クォーテーションが全角に変換されますので、半角に修正してください。)

1. 以下のコマンドを実行します。
(データベースに Windows Internal Database (WID) を利用している場合)
“C:\Program Files\Update Services\Tools\wsusutil.exe” postinstall /servicing
(データベースに SQL Server を利用している場合)
“C:\Program Files\Update Services\Tools\wsusutil.exe” postinstall SQL_INSTANCE_NAME=<インスタンス名> /servicing

※ 以下のレジストリ値が MICROSOFT##WID となっていれば、WID であると判断できます。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup!SqlServerName

2. コマンドの実行が完了した後、サーバー マネージャーを起動します。

3. ダッシュボードより [役割と機能の追加] をクリックします。

4. ウィザードを進め [機能] ページで以下の機能を追加して [次へ] をクリックしていきます。

[.NET Framework 4.5 Features] – [WCF サービス] – [HTTP アクティブ化]

5. ウィザードを完了後、サーバー マネージャーを閉じます。

6. [管理ツール] – [サービス] より WSUS Service を再起動します。

7. WSUS 管理コンソールに接続可能か確認します。

SSL 構成の WSUS の場合は、以下の手順を実施してください。

1. コマンド プロンプトを “管理者として実行” で起動して、以下のコマンドを実行します。

takeown /f web.config /a

icacls “C:\Program Files\Update Services\WebServices\ClientWebService\Web.config” /grant administrators:f

2. 次のパスに web.config ファイルが存在することを確認します。

C:\Program Files\Update Services\WebServices\ClientWebService\Web.Config

3. 太字部分について変更します。

<services>
<service
name=”Microsoft.UpdateServices.Internal.Client”
behaviorConfiguration=”ClientWebServiceBehaviour”>
                <!–
                  These 4 endpoint bindings are required for supporting both http and https
                –>
                <endpoint address=””
                        binding=”basicHttpBinding”
                        bindingConfiguration=”SSL”
                        contract=”Microsoft.UpdateServices.Internal.IClientWebService” />
                <endpoint address=”secured”
                        binding=”basicHttpBinding”
                        bindingConfiguration=”SSL”
                        contract=”Microsoft.UpdateServices.Internal.IClientWebService” />
<endpoint address=””
binding=”basicHttpBinding”
bindingConfiguration=”ClientWebServiceBinding”
contract=”Microsoft.UpdateServices.Internal.IClientWebService” />
<endpoint address=”secured”
binding=”basicHttpBinding”
bindingConfiguration=”ClientWebServiceBinding”
contract=”Microsoft.UpdateServices.Internal.IClientWebService” />
</service>
</services>

4. 続けてファイルの末尾にある以下の太字部分を変更して、web.config ファイルを上書き保存します。

</bindings>
<serviceHostingEnvironment aspNetCompatibilityEnabled=”true” multipleSiteBindingsEnabled=”true” />
</system.serviceModel>

～ 参考情報 ～
(英語) Update enables ESD decryption provision in WSUS in Windows Server 2012 and Windows Server 2012 R2
https://support.microsoft.com/en-us/kb/3159706
(日本語) 更新により、Windows Server 2012 と Windows Server 2012 R2 での WSUS の ESD 復号化の準備
https://support.microsoft.com/ja-jp/kb/3159706

(英語) The long-term fix for KB3148812 issues
https://blogs.technet.microsoft.com/wsus/2016/05/05/the-long-term-fix-for-kb3148812-issues/

みなさま、こんにちは。WSUS サポート チームです。

WSUS 3.0 SP2 は既に延長サポート期間を迎えており、2017 年 7 月 11 日にサポートが終了します。

しかしながら、現在も WSUS 3.0 SP2 の環境をご運用され続けている方は多くいらっしゃると思います。

今回はそのような方達に向けて、弊社米国の開発部門が公開したブログ記事を翻訳いたしましたのでご紹介いたします。サポート期間の終了に伴って WSUS 3.0 SP2 の環境からの移行をご検討されている方は、是非ともご一読ください。

—————————————————–

このポストは、1 月 22 日に投稿された For those on WSUS 3.0 SP2 (or SBS 2011) の翻訳です。

<<https://blogs.technet.microsoft.com/wsus/2016/01/22/for-those-on-wsus-3-0-sp2-or-sbs-2011/>>

著者: Steve Henry

WSUS 3.0 SP2（またはSBS 2011）をご利用中のみなさま

以前の記事で紹介したように、Windows 10 サービス エクスペリエンスを円滑に提供できるよう、Windows Server 2012 以降の WSUSに対しては、新たな更新プログラムを提供しております。しかし、WSUS 3.0 SP2 は既に延長サポート期間を迎えており (2017 年 7 月にはサポート期間が完全に終了)、これらの更新を WSUS 3.0 SP2 に対してリリースする予定はございません。そのため、この機会に WSUS の移行についてもご検討いただけますと幸いです。

また、併せて Windows 10 の展開をご検討中のみなさまに、導入における考慮事項が記載されたガイダンスをいくつか紹介いたします。

WSUS 3.0 SP2 のスタンドアロン環境

本シナリオでは、Windows Server 2012 R2 サーバーまたは Windows Server 2016 サーバーに WSUS を新しく構築し、既存 SUSDB を移行することを推奨します。WSUS の移行方法については、TechNet ガイダンスをご参照ください。新しい WSUS を導入することで、Windows 10 の最新の機能やサービスをご利用いただけます。

Configuration Manager と WSUS 3.0 SP2 環境

機能アップグレードを配布する際に、タスクシーケンスや MDT またはその他メディアベースの展開ツールではなく WSUS を利用したい場合には、前述のスタンドアロン シナリオと同様に、Windows Server 2012 以降の WSUS に移行することを推奨します。

もし、機能アップグレードの展開にメディア ベース配布ツールのを利用する場合には、運用を変える必要はありません。ただし、WSUS 3.0 SP2 の環境に向けて Windows 10 のサービシングに対応する更新プログラムを提供する予定はございませんことを、ご留意いただけますようお願いいたします。

WSUS 3.0 SP2 を使用している SBS 2008 と SBS 2011 環境

この場合の推奨は他の環境と少し異なります。サードパーティー ソフトウェアに対してアップデート管理が必要な場合、 WSUS を Windows Server 2012  やそれ以降のメンバーサーバーに移行することで、現在ご利用の環境で Windows 10 サービス エクスペリエンスをご利用いただけます。また、WSUS によるサードパーティーソフトウェアのアップデート配布が不要な場合、Windows Update for Business で Windows 10 の更新プログラムを管理するようグループポリシーを設定することもできます。Windows Update for Business は、最初に設定を行っていただければ、ほとんど運用管理をする必要がないため、日々の運用の手間を最小限にすることができます。また、Windows Update for Business  では Windows 10 の最新ビルドや累積的な更新プログラムを、常に容易に最新の状態を維持することができます。

まとめ

私たちは、現在ご利用いただいているツールを用いて新しいサービス モデルをサポート出来るよう、主なシナリオに対応する追加機能を提供し、次期リリースの改善を続けてまいります。

WSUS 3.0 SP2 では新しいサービスモデルは提供されません。技術的には Windows 10 向けのセキュリティ更新プログラムの同期や配布といった最低限の機能は提供されますが、あくまでも最低限の機能となるため、今後 WSUS 3.0 SP2 上で、Windows 10 マシンが “Windows Vista” と表示されるような不具合が発生する可能性がございます。

これからも、新しいサービシング モデルをご利用していただくために、既存ガイダンスの更新や、ベスト プラクティスの提供を継続してまいります。

みなさま、こんにちは。WSUS サポート チームです。

前回ご案内したブログ記事の通り、WSUS 3.0 SP2 は 2017 年 7 月 11 日にサポートが終了しますので、次期バージョンへの移行を検討されている方も多いかと思います。
WSUS 3.0 SP2 の次期バージョンとしては、現時点で Windows Server 2012 WSUS と Windows Server 2012 R2 WSUS がありますが、WSUS 3.0 SP2 からの移行手順としては、以下の TechNet 情報にてご紹介しております。

Windows Server 2012 への Windows Server Update Services の移行
https://msdn.microsoft.com/ja-jp/library/hh852339(v=ws.11).aspx

こちらのページでは、移行の準備や実際の移行手順が紹介されておりますが、WSUS が使っているデータベースによっては、一部のコマンドが異なるなど補足が必要な点もございます。そこで今回は当サポート部門にてご案内した実績のある WSUS の移行手順をご紹介します！

第 1 回である本ポストでは、サポートされている移行シナリオのご紹介とともに WSUS のデータベースとして Windows Internal Database (WID) を使っている場合の移行手順をご紹介します。移行元と移行先の WSUS に WID を使用することを予定されている方は是非ともご一読ください。

移行シナリオについて

サポートされている移行シナリオとサポートされていない移行シナリオとしては、以下の TechNet 情報にて紹介しております。

手順 1:WSUS の移行を計画する
https://msdn.microsoft.com/ja-jp/library/hh852352(v=ws.11).aspx

主なポイントとしては以下の通りですので、移行を計画する際はご注意ください。

・WSUS 3.0 SP2 から Windows Server 2012 / Windows Server 2012 R2 WSUS への移行がサポートされます。(WSUS 3.0 SP1 は不可)
・WID を実行している移行元サーバーから、SQL Server 2008 R2 SP1 を実行している移行先サーバーへの移行はサポートされます。
・ドメインからワークグループへの移行、またはワークグループからドメインへの移行はサポートされます。但し、移行元サーバーで SQL Server がリモートの場所から実行されている場合、ドメインからワークグループへの移行はサポートされません。
・SQL Server を実行している移行元サーバーから、WID を実行している移行先サーバーへの移行はサポートされません。

WSUS 移行手順について (WID -> WID)

– 前提条件
移行元 サーバー : WSUS 3.0 SP2 環境
移行先 サーバー : Windows Server 2012 R2 の WSUS 環境
WSUS は移行元も移行先もデータベースに Windows Internal Database (WID) を利用していることを前提とします。

– 手順
Windows Server 2012 R2 の WSUS のインストールとデータ移行の手順は以下の通りです。

1. Windows Server 2012 R2 の WSUS のインストール
2. データ移行
2.1. WSUS 更新プログラム バイナリを移行する
2.2. WSUS セキュリティ グループを移行する
2.3. WSUS データベースをバックアップする
2.4. WSUS データベースのバックアップを移行先サーバーで復元する
2.5. WSUS サーバー ID を変更する
(任意) 2.6. ポート番号を変更する
(任意) 2.7. インデックスを再構成する
(任意) 2.8. 不足ファイルをダウンロードする
3. 完了確認

各手順の詳細は以下に記載いたします。

1. Windows Server 2012 R2 の WSUS のインストール

Windows Server 2012 R2 の WSUS のインストールは、サーバー マネージャーから[役割と機能の追加] をクリックして、インストールする手順となります。こちらの手順は以下の TechNet 情報をそのままご利用いただけます。

– 手順 2: WSUS サーバーの役割をインストールする
http://technet.microsoft.com/ja-jp/library/hh852338.aspx

WSUS サーバーの役割のインストールが正常に完了すると、Windows Server Update Services 設定ウィザードが自動的に起動しますが、このウィザードは閉じてください。

2. データ移行

2.1. WSUS 更新プログラム バイナリを移行する

移行元のコンテンツ フォルダー「\\<移行元サーバー名>\WsusContent」の内容を、移行先のコンテンツ フォルダー「\\<移行先サーバー名>\WsusContent」へコピーします。エクスプローラー、xcopy コマンド、robocopy コマンド等を利用し、コピーすることが可能です。robocopy コマンドを利用する場合は、以下の通りです。

例) 移行元が WSUSOld で、移行先が WSUSNew の場合
robocopy \\WSUSOld\WsusContent \\WSUSNew\WsusContent /E /COPYALL

2.2. WSUS セキュリティ グループを移行する

WSUS Administrators ローカル セキュリティ グループと WSUS Reporters ローカル セキュリティ グループのみ手動で移行することを選択できます。

この手順を実行する前に、ローカル グループのメンバーであるドメイン ユーザーの名前を、移行先サーバーでも解決できることを確認します。移行元サーバーと移行先サーバーの属するドメインが異なる場合は、移行元ドメインのユーザー アカウントがあるフォレストのグローバル カタログ サーバーに移行先サーバーがアクセスできる必要があります。

WSUS Administrators ローカル セキュリティ グループと WSUS Reporters ローカル セキュリティ グループに手動でユーザーを移行するには、移行先サーバーで次の手順を実行します。

– 手順
1. スタート画面で lusrmgr.msc と入力して、Enter キーを押します。
2. ローカル ユーザーとグループ MMC スナップインのコンソール ツリーで、[ユーザー] をダブルクリックします。
3. 移行元サーバーの WSUS Administrators グループと WSUS Reporters グループに存在したユーザーを手動で作成します。
4. ローカル ユーザーとグループ MMC スナップインのコンソール ツリーで、[グループ] をダブルクリックします。
5. 移行元サーバーの WSUS Administrators グループと WSUS Reporters グループに存在したユーザーを移行先サーバーの WSUS Administrators グループと WSUS Reporters グループに手動で追加します。

2.3. WSUS データベースをバックアップする

移行元 WSUS サーバーにおいて以下の手順を実施し、WSUS データベース (SUSDB) をバックアップします。

1. 下記 URL より SQL Server Management Studio Express をダウンロードし、WSUS サーバーにインストールします。

Microsoft SQL Server Management Studio Express
http://www.microsoft.com/ja-jp/download/details.aspx?id=8961
(.NET Framework 2.0, MSXML 6.0 のインストールが必要となります。もし未導入の場合にはページ内のリンクからインストールを行って下さい)

※ OS が Windows Server 2008, Windows Server 2008 R2 の場合は、こちらもお使いいただけます。
Microsoft SQL Server 2008 R2 RTM – Management Studio Express
http://www.microsoft.com/ja-jp/download/details.aspx?id=22985

2. SQL Server Management Studio を起動して、以下の接続文字列は指定してインスタンスに接続します。

サーバーの種類 : データベース エンジン
サーバー名 : \\.\pipe\mssql$microsoft##ssee\sql\query
認証 : Windows 認証

3. [データベース] を展開し、[SUSDB] データベースを選択します。
4. データベースを右クリックし、[タスク] をポイントして、[バックアップ] をクリックします。[データベースのバックアップ] ダイアログ ボックスが表示されます。
5. [データベース] ボックスの一覧で、データベース名を確認します。
6. [バックアップの種類] ボックスの一覧で、[完全] をクリックします。
7. [コピーのみのバックアップ] を選択します。コピーのみのバックアップとは、定期的に実行される一連の SQL Server バックアップとは別の SQL Server バックアップです。
8. [バックアップ コンポーネント] で [データベース] をクリックします。
9. [名前] ボックスに表示されている既定のバックアップ セット名をそのまま使用するか、バックアップ セットの別の名前を入力します。
10. オプションで、[説明] ボックスに、バックアップ セットの説明を入力します。
11. 必要に応じてバックアップ セットの有効期限を指定します。有効期限データの検証を明示的に省略せずに、どの時点でバックアップ セットが期限切れになり上書きできるようにするかを指定します。
12. [ディスク] をクリックして、バックアップ先を選択します。
13. [ページの選択] ウィンドウの [オプション] をクリックして、詳細オプションを表示または選択します。
14. [メディアに上書きします] オプションで、次のいずれかをクリックします。
・[既存のメディア セットにバックアップする]: このオプションでは、[既存のバックアップ セットに追加する] または [既存のすべてのバックアップ セットを上書きする] をクリックします。必要に応じて、次の操作を行います。
・[メディア セット名とバックアップ セットの有効期限を確認する] をクリックすることで、メディア セットおよびバックアップ セットの有効期限が切れる日時をバックアップ操作で確認できます。
・[メディア セット名] ボックスに名前を入力します。名前を指定しないと、メディア セットは空白の名前で作成されます。メディア セット名を指定すると、メディア (テープまたはディスク) が検査され、名前がここで入力した名前と一致するかどうかが確認されます。
・ [新しいメディア セットにバックアップし、すべての既存のバックアップ セットを消去する]: このオプションでは、[新しいメディア セット名] ボックスに名前を入力し、オプションで [新しいメディア セットの説明] ボックスにメディア セットの説明を入力します。
15. [信頼性] セクションで、必要に応じて、次のチェック ボックスをオンにします。
・[完了時にバックアップを検証する]
・[メディアに書き込む前にチェックサムを行う]
・[エラーのまま続行する]
16. [OK] をクリックして、バックアップを作成します。
17. バックアップ完了後、指定したバックアップ先に作成されたバックアップ ファイルを移行先 WSUS サーバーの任意の場所にコピーします。

2.4. WSUS データベースのバックアップを移行先サーバーで復元する

移行先 WSUS サーバーにおいて以下の手順を実施し、WSUS データベース (SUSDB) を復元します。

1. 下記 URL より SQL Server Management Studio Express をダウンロードし、WSUS サーバーにインストールします。

Microsoft SQL Server 2012 Express
http://www.microsoft.com/ja-jp/download/details.aspx?id=29062
※ ダウンロードするプログラムの中から JPN\x64\SQLManagementStudio_x64_JPN.exe を選択します。

2. SQL Server Management Studio を起動して、以下の接続文字列は指定してインスタンスに接続します。

サーバーの種類 : データベース エンジン
サーバー名 : \\.\pipe\Microsoft##WID\tsql\query
認証 : Windows 認証

3. [新しいクエリ] をクリックし、次の SQL コマンドをコピーして [実行] をクリックしてクエリを実行します。WSUS データベースを削除します。

—————————————-
USE master
GO
ALTER DATABASE SUSDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
DROP DATABASE SUSDB
GO
—————————————-

4. [実行] をクリックしてクエリを実行します。

5. 続けて、次の SQL コマンドをコピーして [実行] をクリックしてクエリを実行します。WSUS データベースをバックアップから復元します。

例) バックアップ ファイルを C:\SUSDB.bak に配置している場合
RESTORE DATABASE [SUSDB] FROM DISK = N’C:\SUSDB.bak’ WITH FILE = 1, MOVE N’SUSDB’ TO N’c:\Windows\WID\Data\susdb.mdf’, MOVE N’SUSDB_log’ TO N’c:\Windows\WID\Data\SUSDB_log.ldf’, NOUNLOAD, STATS = 10

6. この結果として、次のエラー メッセージが表示される場合があります。エラー メッセージを無視して、続行してください。

メッセージ 3605、レベル 16、状態 1、行 1
データベース ‘SUSDB’ のスキーマの検証が失敗しました。
メッセージ 3013、レベル 16、状態 1、行 1
RESTORE DATABASE が異常終了しています。

7. 移行先 WSUS サーバー (Windows Server 2012 R2) でコマンド プロンプトを [管理者として実行] にて開き、次のコマンドを実行します。

例) WSUS のインストール フォルダーが D:\WSUS の場合
cd %programfiles%\Update Services\Tools
wsusutil postinstall content_dir=D:\WSUS

2.5. WSUS サーバー ID を変更する

移行先サーバーの WSUS サーバー ID は変更する必要があります。この手順を実行すると、移行プロセス中に WSUS 管理のクライアントは影響を受けなくなります。移行元サーバーと移行先サーバーが同じ ID を使用して実行されている場合、サーバーの一方に対して変更を行うと、クライアントとサーバー間の通信は失敗します。

1.移行先サーバーで、Windows PowerShell を [管理者として実行] にて開き、次のスクリプトを実行します。

$updateServer = get-wsusserver
$config = $updateServer.GetConfiguration()
$config.ServerId = [System.Guid]::NewGuid()
$config.Save()

2.サーバー ID が変更されたら、すぐにコマンド プロンプトを [管理者として実行] にて開き、次のコマンドを実行して新しい暗号化キーを生成します。

cd %programfiles%\Update Services\Tools
wsusutil.exe postinstall

(任意) 2.6. ポート番号を変更する

Windows Server 2012 R2 の WSUS で使用される既定のポートは 8530 となりますが、ポート番号を 80 に変更する場合は、以下の手順を実施します。

WSUS 4.0 (Windows Server 2012) ポート番号変更について
http://blogs.technet.com/b/jpwsus/archive/2014/04/03/wsus-4-0-windows-server-2012.aspx

(任意) 2.7. インデックスを再構成する

移行前の WSUS データベースにてインデックスの再構成を定期的に実施していない場合は、インデックスの断片化が発生しており、クエリ パフォーマンスが劣化している可能性がございます。その場合は、インデックスを再構成することで、クエリ パフォーマンスを改善することができます。

コマンドを使ってインデックスの再構成を行う場合には、インデックス再構成用のスクリプトを sql ファイルに保存した上で、以下のコマンドを実行します。

例) C:\Temp\WsusDBMaintenance.sql に実行する SQL 文を保存しており、C:\Temp 配下に実行結果ログを出力する場合
sqlcmd -E -S <インスタンス名> -i C:\Temp\WsusDBMaintenance.sql -o C:\Temp\WsusDBMaintenance.out -f 65001
※ WSUS データベースに WID をご利用の場合、<インスタンス名> は、以下を指定します。

– Windows Server 2008 R2 以前
\\.\pipe\mssql$microsoft##ssee\sql\query
– Windows Server 2012 / 2012 R2
\\.\pipe\Microsoft##WID\tsql\query

出力ファイルに “Statistics for all tables have been updated” または”全テーブルの統計が更新されました” というメッセージが 表示されていれば、インデックスの再構成は完了しています。

～ 参考情報 ～
sqlcmd ユーティリティ
https://msdn.microsoft.com/ja-jp/library/ms162773.aspx

WSUS DB インデックスの再構成の手順について
http://blogs.technet.com/b/jpwsus/archive/2014/03/06/wsusdb.aspx

(任意) 2.8. 不足ファイルをダウンロードする

手順 2.1. でバイナリ ファイルは移行元からコピーされていますが、もし移行元で承認されていたにも関わらず、バイナリが不足している場合は、wsusutil reset コマンドで不足ファイルのみをダウンロードすることができます。もし、クライアントの接続確認の際に 80244019 エラー (HTTP status 404 File Not Found) が発生した場合は、サーバー側の WsusContent フォルダー配下に必要なファイルが不足している可能性がございますので、以下のコマンドの実行をお試しください。

cd /d “C:\Program Files\Update Services\Tools”
wsusutil reset

コマンド ラインからの WSUS の管理
https://technet.microsoft.com/ja-jp/library/cc720466(v=ws.10).aspx
—– 抜粋ここから —–
reset
データベースのすべての更新メタデータ行に、ファイル システムに格納されている対応する更新ファイルが含まれていることを確認します。更新ファイルが不足していたり壊れていた場合、WSUS は更新ファイルをもう一度ダウンロードします。
– WSUS データベースを復元した後
– トラブルシューティング時
—– 抜粋ここまで —–

3. 完了確認

移行先サーバーで WSUS 管理コンソールを起動し、初回の設定を必要に応じて行います。WSUS 管理コンソール起動後、更新プログラムの情報や承認情報、グループ情報が移行されていることをご確認ください。また、ダウンストリーム サーバーの接続や WSUS クライアントを移行先の WSUS サーバーと接続できるかどうか確認するためには、以下の内容をご確認ください。

3.5.セキュリティ設定を適用する
– ダウンストリーム サーバーを新しい WSUS サーバーに接続する
– WSUS クライアントを新しい WSUS サーバーに接続する
https://technet.microsoft.com/ja-jp/library/hh852349.aspx#BKMK_3_5

みなさま、こんにちは。WSUS サポート チームです。

WSUS 3.0 SP2 から Windows Server 2012 / 2012 R2 WSUS への移行手順について、前回のポストでは、移行元と移行先の WSUS のデータベースに Windows Internal Database (WID) を使用している場合の移行手順でしたが、今回は SQL Server を使用している場合の手順についてご紹介いたします。
本手順も前回と同じように、以下の TechNet 情報を基に作成しています。

Windows Server 2012 への Windows Server Update Services の移行
https://msdn.microsoft.com/ja-jp/library/hh852339(v=ws.11).aspx

WID 版との違いとしては、実行するコマンドが一部異なりますが、その他の部分は同じものとなります。違いについてはわかりやすいように、赤字で記載しましたので、ご注目くださいませ。

また、前回のポストでも触れましたが、SQL Server を実行している移行元サーバーから、WID を実行している移行先サーバーへの移行はサポートされません。そのため、SQL Server から WID への乗り換えをご検討されている場合は、残念ながら本手順はご利用いただけず、新規構築が必要となりますので、ご注意ください。

WSUS 移行手順について (SQL -> SQL)

– 前提条件
移行元 サーバー : WSUS 3.0 SP2 環境
移行先 サーバー : Windows Server 2012 R2 の WSUS 環境
WSUS は移行元も移行先もデータベースに SQL Server を利用していることを前提とします。

– 手順
Windows Server 2012 R2 の WSUS のインストールとデータ移行の手順は以下の通りです。

1. Windows Server 2012 R2 の WSUS のインストール
2. データ移行
2.1. WSUS 更新プログラム バイナリを移行する
2.2. WSUS セキュリティ グループを移行する
2.3. WSUS データベースをバックアップする
2.4. WSUS データベースのバックアップを移行先サーバーで復元する
2.5. WSUS サーバー ID を変更する
(任意) 2.6. ポート番号を変更する
(任意) 2.7. インデックスを再構成する
(任意) 2.8. 不足ファイルをダウンロードする
3. 完了確認

各手順の詳細は以下に記載いたします。

1. Windows Server 2012 R2 の WSUS のインストール

Windows Server 2012 R2 の WSUS のインストールは、サーバー マネージャーから[役割と機能の追加] をクリックして、インストールする手順となります。こちらの手順は以下の TechNet 情報をそのままご利用いただけます。

– 手順 2: WSUS サーバーの役割をインストールする
http://technet.microsoft.com/ja-jp/library/hh852338.aspx

WSUS サーバーの役割のインストールが正常に完了すると、Windows Server Update Services 設定ウィザードが自動的に起動しますが、このウィザードは閉じてください。

2. データ移行

2.1. WSUS 更新プログラム バイナリを移行する

移行元のコンテンツ フォルダー「\\<移行元サーバー名>\WsusContent」の内容を、移行先のコンテンツ フォルダー「\\<移行先サーバー名>\WsusContent」へコピーします。エクスプローラー、xcopy コマンド、robocopy コマンド等を利用し、コピーすることが可能です。robocopy コマンドを利用する場合は、以下の通りです。

例) 移行元が WSUSOld で、移行先が WSUSNew の場合
robocopy \\WSUSOld\WsusContent \\WSUSNew\WsusContent /E /COPYALL

2.2. WSUS セキュリティ グループを移行する

WSUS Administrators ローカル セキュリティ グループと WSUS Reporters ローカル セキュリティ グループのみ手動で移行することを選択できます。

この手順を実行する前に、ローカル グループのメンバーであるドメイン ユーザーの名前を、移行先サーバーでも解決できることを確認します。移行元サーバーと移行先サーバーの属するドメインが異なる場合は、移行元ドメインのユーザー アカウントがあるフォレストのグローバル カタログ サーバーに移行先サーバーがアクセスできる必要があります。

WSUS Administrators ローカル セキュリティ グループと WSUS Reporters ローカル セキュリティ グループに手動でユーザーを移行するには、移行先サーバーで次の手順を実行します。

– 手順
1. スタート画面で lusrmgr.msc と入力して、Enter キーを押します。
2. ローカル ユーザーとグループ MMC スナップインのコンソール ツリーで、[ユーザー] をダブルクリックします。
3. 移行元サーバーの WSUS Administrators グループと WSUS Reporters グループに存在したユーザーを手動で作成します。
4. ローカル ユーザーとグループ MMC スナップインのコンソール ツリーで、[グループ] をダブルクリックします。
5. 移行元サーバーの WSUS Administrators グループと WSUS Reporters グループに存在したユーザーを移行先サーバーの WSUS Administrators グループと WSUS Reporters グループに手動で追加します。

2.3. WSUS データベースをバックアップする

移行元 WSUS サーバーにおいて以下の手順を実施し、WSUS データベース (SUSDB) をバックアップします。

1. 下記 URL より SQL Server Management Studio Express をダウンロードし、WSUS サーバーにインストールします。

Microsoft SQL Server Management Studio Express
http://www.microsoft.com/ja-jp/download/details.aspx?id=8961
(.NET Framework 2.0, MSXML 6.0 のインストールが必要となります。もし未導入の場合にはページ内のリンクからインストールを行って下さい)

※ OS が Windows Server 2008, Windows Server 2008 R2 の場合は、こちらもお使いいただけます。
Microsoft SQL Server 2008 R2 RTM – Management Studio Express
http://www.microsoft.com/ja-jp/download/details.aspx?id=22985

2. SQL Server Management Studio を起動して、以下の接続文字列は指定してインスタンスに接続します。

サーバーの種類 : データベース エンジン
サーバー名 : localhost
認証 : Windows 認証

3. [データベース] を展開し、[SUSDB] データベースを選択します。
4. データベースを右クリックし、[タスク] をポイントして、[バックアップ] をクリックします。[データベースのバックアップ] ダイアログ ボックスが表示されます。
5. [データベース] ボックスの一覧で、データベース名を確認します。
6. [バックアップの種類] ボックスの一覧で、[完全] をクリックします。
7. [コピーのみのバックアップ] を選択します。コピーのみのバックアップとは、定期的に実行される一連の SQL Server バックアップとは別の SQL Server バックアップです。
8. [バックアップ コンポーネント] で [データベース] をクリックします。
9. [名前] ボックスに表示されている既定のバックアップ セット名をそのまま使用するか、バックアップ セットの別の名前を入力します。
10. オプションで、[説明] ボックスに、バックアップ セットの説明を入力します。
11. 必要に応じてバックアップ セットの有効期限を指定します。有効期限データの検証を明示的に省略せずに、どの時点でバックアップ セットが期限切れになり上書きできるようにするかを指定します。
12. [ディスク] をクリックして、バックアップ先を選択します。
13. [ページの選択] ウィンドウの [オプション] をクリックして、詳細オプションを表示または選択します。
14. [メディアに上書きします] オプションで、次のいずれかをクリックします。
・[既存のメディア セットにバックアップする]: このオプションでは、[既存のバックアップ セットに追加する] または [既存のすべてのバックアップ セットを上書きする] をクリックします。必要に応じて、次の操作を行います。
・[メディア セット名とバックアップ セットの有効期限を確認する] をクリックすることで、メディア セットおよびバックアップ セットの有効期限が切れる日時をバックアップ操作で確認できます。
・[メディア セット名] ボックスに名前を入力します。名前を指定しないと、メディア セットは空白の名前で作成されます。メディア セット名を指定すると、メディア (テープまたはディスク) が検査され、名前がここで入力した名前と一致するかどうかが確認されます。
・ [新しいメディア セットにバックアップし、すべての既存のバックアップ セットを消去する]: このオプションでは、[新しいメディア セット名] ボックスに名前を入力し、オプションで [新しいメディア セットの説明] ボックスにメディア セットの説明を入力します。
15. [信頼性] セクションで、必要に応じて、次のチェック ボックスをオンにします。
・[完了時にバックアップを検証する]
・[メディアに書き込む前にチェックサムを行う]
・[エラーのまま続行する]
16. [OK] をクリックして、バックアップを作成します。
17. バックアップ完了後、指定したバックアップ先に作成されたバックアップ ファイルを移行先 WSUS サーバーの任意の場所にコピーします。

2.4. WSUS データベースのバックアップを移行先サーバーで復元する

移行先 WSUS サーバーにおいて以下の手順を実施し、WSUS データベース (SUSDB) を復元します。

1. 下記 URL より SQL Server Management Studio Express をダウンロードし、WSUS サーバーにインストールします。

Microsoft SQL Server 2012 Express
http://www.microsoft.com/ja-jp/download/details.aspx?id=29062
※ ダウンロードするプログラムの中から JPN\x64\SQLManagementStudio_x64_JPN.exe を選択します。

2. SQL Server Management Studio を起動して、以下の接続文字列は指定してインスタンスに接続します。

サーバーの種類 : データベース エンジン
サーバー名 : localhost
認証 : Windows 認証

3. [新しいクエリ] をクリックし、次の SQL コマンドをコピーして [実行] をクリックしてクエリを実行します。WSUS データベースを削除します。

—————————————-
USE master
GO
ALTER DATABASE SUSDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
DROP DATABASE SUSDB
GO
—————————————-

4. [実行] をクリックしてクエリを実行します。

5. 続けて、次の SQL コマンドをコピーして [実行] をクリックしてクエリを実行します。WSUS データベースをバックアップから復元します。

例) バックアップ ファイルを C:\SUSDB.bak に配置している場合
RESTORE DATABASE [SUSDB] FROM DISK = N’C:\SUSDB.bak’ WITH FILE = 1, MOVE N’SUSDB’ TO N’C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\SUSDB.mdf’, MOVE N’SUSDB_log’ TO N’C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\SUSDB_log.ldf’, NOUNLOAD, STATS = 10
※ “C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\” のパスは SQL Server 2012 の既定のパスとなります。こちらは SUSDB の配置場所となりますので、お客様環境に応じてご変更ください。

6. この結果として、次のエラー メッセージが表示される場合があります。エラー メッセージを無視して、続行してください。

メッセージ 3605、レベル 16、状態 1、行 1
データベース ‘SUSDB’ のスキーマの検証が失敗しました。
メッセージ 3013、レベル 16、状態 1、行 1
RESTORE DATABASE が異常終了しています。

7. 移行先 WSUS サーバー (Windows Server 2012 R2) でコマンド プロンプトを [管理者として実行] にて開き、次のコマンドを実行します。

例) WSUS のインストール フォルダーが D:\WSUS で、WSUS 用 SQL サーバー名が WSUSSQL01、インスタンス名が SQLINSTANCE の場合
cd %programfiles%\Update Services\Tools
wsusutil postinstall sql_instance_name=WSUSSQL01\SQLINSTANCE content_dir=D:\WSUS
※ 既定のインスタンスを使用している場合は、WSUSSQL01\SQLINSTANCE の部分は WSUSSQL01 のみで問題ありません。

2.5. WSUS サーバー ID を変更する

移行先サーバーの WSUS サーバー ID は変更する必要があります。この手順を実行すると、移行プロセス中に WSUS 管理のクライアントは影響を受けなくなります。移行元サーバーと移行先サーバーが同じ ID を使用して実行されている場合、サーバーの一方に対して変更を行うと、クライアントとサーバー間の通信は失敗します。

1.移行先サーバーで、Windows PowerShell を [管理者として実行] にて開き、次のスクリプトを実行します。

$updateServer = get-wsusserver
$config = $updateServer.GetConfiguration()
$config.ServerId = [System.Guid]::NewGuid()
$config.Save()

2.サーバー ID が変更されたら、すぐにコマンド プロンプトを [管理者として実行] にて開き、次のコマンドを実行して新しい暗号化キーを生成します。

cd %programfiles%\Update Services\Tools
wsusutil.exe postinstall

(任意) 2.6. ポート番号を変更する

Windows Server 2012 R2 の WSUS で使用される既定のポートは 8530 となりますが、ポート番号を 80 に変更する場合は、以下の手順を実施します。

WSUS 4.0 (Windows Server 2012) ポート番号変更について
http://blogs.technet.com/b/jpwsus/archive/2014/04/03/wsus-4-0-windows-server-2012.aspx

(任意) 2.7. インデックスを再構成する

移行前の WSUS データベースにてインデックスの再構成を定期的に実施していない場合は、インデックスの断片化が発生しており、クエリ パフォーマンスが劣化している可能性がございます。その場合は、インデックスを再構成することで、クエリ パフォーマンスを改善することができます。

コマンドを使ってインデックスの再構成を行う場合には、インデックス再構成用のスクリプトを sql ファイルに保存した上で、以下のコマンドを実行します。

例) C:\Temp\WsusDBMaintenance.sql に実行する SQL 文を保存しており、C:\Temp 配下に実行結果ログを出力する場合
sqlcmd -E -S <インスタンス名> -i C:\Temp\WsusDBMaintenance.sql -o C:\Temp\WsusDBMaintenance.out -f 65001
※ WSUS データベースに WID をご利用の場合、<インスタンス名> は、以下を指定します。

– Windows Server 2008 R2 以前
\\.\pipe\mssql$microsoft##ssee\sql\query
– Windows Server 2012 / 2012 R2
\\.\pipe\Microsoft##WID\tsql\query

出力ファイルに “Statistics for all tables have been updated” または”全テーブルの統計が更新されました” というメッセージが 表示されていれば、インデックスの再構成は完了しています。

～ 参考情報 ～
sqlcmd ユーティリティ
https://msdn.microsoft.com/ja-jp/library/ms162773.aspx

WSUS DB インデックスの再構成の手順について
http://blogs.technet.com/b/jpwsus/archive/2014/03/06/wsusdb.aspx

(任意) 2.8. 不足ファイルをダウンロードする

手順 2.1. でバイナリ ファイルは移行元からコピーされていますが、もし移行元で承認されていたにも関わらず、バイナリが不足している場合は、wsusutil reset コマンドで不足ファイルのみをダウンロードすることができます。もし、クライアントの接続確認の際に 80244019 エラー (HTTP status 404 File Not Found) が発生した場合は、サーバー側の WsusContent フォルダー配下に必要なファイルが不足している可能性がございますので、以下のコマンドの実行をお試しください。

cd /d “C:\Program Files\Update Services\Tools”
wsusutil reset

コマンド ラインからの WSUS の管理
https://technet.microsoft.com/ja-jp/library/cc720466(v=ws.10).aspx
—– 抜粋ここから —–
reset
データベースのすべての更新メタデータ行に、ファイル システムに格納されている対応する更新ファイルが含まれていることを確認します。更新ファイルが不足していたり壊れていた場合、WSUS は更新ファイルをもう一度ダウンロードします。
– WSUS データベースを復元した後
– トラブルシューティング時
—– 抜粋ここまで —–

3. 完了確認

移行先サーバーで WSUS 管理コンソールを起動し、初回の設定を必要に応じて行います。WSUS 管理コンソール起動後、更新プログラムの情報や承認情報、グループ情報が移行されていることをご確認ください。また、ダウンストリーム サーバーの接続や WSUS クライアントを移行先の WSUS サーバーと接続できるかどうか確認するためには、以下の内容をご確認ください。

3.5.セキュリティ設定を適用する
– ダウンストリーム サーバーを新しい WSUS サーバーに接続する
– WSUS クライアントを新しい WSUS サーバーに接続する
https://technet.microsoft.com/ja-jp/library/hh852349.aspx#BKMK_3_5

みなさま、こんにちは。 WSUS サポート チームです。

Windows 10 の2 回目の機能アップグレードである Anniversary Update がリリースされ、本格的に Windows 10 の導入を進められているお客様も多いかと思います。

WSUS では Windows 10 に関する更新プログラムの同期対象をオプションで選択することができます。

この同期対象の項目については複数あり、同期対象を選択する上でどの項目を設定するべきか迷われることもあるかと思いますので、WSUS 管理コンソール 「製品と分類」で選択できる Windows 10 の更新プログラム関連の各項目についてご紹介いたします。

製品タブの各項目について

– Windows 10 and later drivers

Windows 10 端末のドライバ関連の更新プログラムが含まれます。

– Windows 10 and later upgrade & servicing drivers

Windows 10 端末のドライバ関連の更新プログラムが含まれます。

ドライバが「Windows 10 and later drivers」か「Windows 10 and later upgrade & servicing drivers」の、どちらに所属するかも各ハードウェアメーカー様によって異なりますので、もしドライバを配布する場合は、どちらもチェックする必要があります。

– Windows 10 Anniversary Update and Later Servicing Drivers

Anniversary Update (1607) のドライバ関連の更新プログラムが含まれます。

– Windows 10 Dynamic Update

Windows 10 をセットアップする時に自動的に適用される更新プログラムが含まれます。Dynamic Update については後述の “「GDR-DU」について” をご確認ください。

– Windows 10 Feature On Demand

Windows 10 のオンデマンド機能 (Features On Demand) で取得する更新プログラムが含まれます。オンデマンド機能では、Windows 10 に .NET Framework 3.5 などの機能を追加する際に、インストール モジュールを Windows Update から入手して、機能追加を行います。

オンデマンド機能は、Windows 10 の [設定] – [システム] – [アプリと機能] より [オプション機能の管理] をクリックし、[機能の追加］をクリックすることで、使用することができます。

– Windows 10 GDR-DU LP

Windows 10 をセットアップする時に自動的に適用される Language Packが含まれます。

– Windows 10 GDR-DU

Windows 10 をセットアップする時に自動的に適用される更新プログラムが含まれます。

通常の更新プログラムは、“Windows 10 がインストールされた状態で、Windows Update 実行時、もしくは WSUS からインストール指示があったとき” に検出・適用されます。

– Windows 10 Language Interface Packs

Language Interface Packs は特定の地域で使用される言語の表記をするために使用されます。

例えば、フランス語・スペイン語が親言語としてインストールされている環境では、バスク語を Language Interface Packs でインストールすることができます。

日本語の Language Interface Packs はございませんので、ご安心ください。

Language Interface Packs (言語インターフェイス パック) としてインストールできる言語の一覧は、以下の技術情報に公開されております。

「利用可能な言語パック」

http://technet.microsoft.com/ja-jp/library/cc722435(v=ws.10).aspx

※ Windows Vista の情報となりますが、参考までにご確認ください。

– Windows 10 Language Packs

Language Packs は、特定の言語およびロケールをサポートできるようにするために使用されます。Windows 10 の英語環境で日本語を有効とするような、“言語パック” が含まれます。

「言語パックとは」

http://technet.microsoft.com/ja-jp/library/cc766472(v=ws.10).aspx

※ Windows Vista の情報となりますが、参考までにご確認ください。

– Windows 10 LTSB

Windows 10 LTSB に適用可能な更新プログラムです。月例のセキュリティ更新プログラムや、重要な更新などが含まれます。

Windows 10 LTSB は、Windows 10 へ新機能を追加することなく、長期間、同じ機能構成を維持したまま、ご利用いただくことが可能なエディションとなります。

「Windows 10 のサービス オプション」

https://technet.microsoft.com/ja-jp/library/mt574263(v=vs.85).aspx

– Windows 10

Windows 10 に適用可能な更新プログラムです。月例のセキュリティ更新プログラムや、重要な更新などが含まれます。

■「GDR-DU」について

GDR-DU は General Distribution Release Dynamic Update の略語です。

General Distribution Release (GDR) は 広範囲のお客様を対象とした更新プログラムとなります。それに対し Limited Distribution Release (LDR) はある特定の問題を解決するために修正が行われた。特定の環境、お客様を対象とした更新プログラムとなります。

GDR と LDR の詳細につきましては下記 URL のブログに記載がございますのでご紹介いたします。

– 修正プログラムにまつわるお話 –

https://blogs.msdn.microsoft.com/japan_platform_sdkwindows_sdk_support_team_blog/2012/01/26/233/

Dynamic Update (動的更新)は、 OS インストールの初期セットアップ最中に、重要なドライバー、コンポーネント、およびセットアップの機能強化を取得するために使用されます。

対話的なインストール プロセスの途中で指定したり、マスターイメージによる OS 自動展開を行う際に、当機能を有効にした応答ファイルを用意しておくことにより、OS セットアップが完了した際には、元のメディア等に含まれていない修正プログラムやドライバが適用された状態となります。つまり、OS セットアップ完了前に適用しておいた方がよい更新プログラムをインストールすることができます。

「Dynamic Update」にチェックを入れていただくことで、OS セットアップ時（正確には OS アップグレード時）に WSUS サーバーから該当の重要なドライバー、コンポーネント、およびセットアップの機能強化を含む、更新プログラムを入手することができます。

こんにちは。WSUS サポート チームです。

本ポストでは、WSUS で更新プログラムを配信する運用をしている中で、管理者が予期しない更新プログラムを展開してしまったときの対応方法をご紹介いたします。

WSUS で更新プログラムを展開する場合、手動で更新プログラムを承認して配信する方法と、自動承認規則を使用して配信する方法の 2 種類があります。誤って予期しない更新プログラムを配信する問題が生じた場合の多くが後者の自動承認規則によって、管理者が予期していない更新プログラムが自動承認規則の条件に含まれてしまい展開されるケースです。

万が一、予期しない更新プログラムが適用されてしまった場合は、更新プログラムのアンインストールが必要です。ただし、ここでいきなりクライアント側のアンインストール作業をしてはいけません。なぜなら WSUS サーバー側で対象の更新プログラムが「インストール承認」されている限り、アンインストールした後再びクライアントが WSUS サーバーに更新プログラムの確認を行うことで、同じ更新プログラムをインストールされてしまいかねないからです。2 次被害を出さないためにも、ここでは作業の順番が大切です。はじめに、WSUS サーバー側で、予期しない更新の配信を停止した後、各クライアントでアンインストールの作業を進めるようにしてください。この手順で進めていただくことで、2 次被害の発生を防ぐことができます。 

1.  更新プログラムを「拒否済み」または「削除の承認」にする

アンインストールしたい対象の更新プログラムを右クリックして [拒否] をクリックすることで、更新プログラムが「拒否済み」となり、クライアントへの配信が停止します。もしくは、[削除の承認] を設定することによってクライアントへの配信を停止し、既に適用済みのコンピューターから予期しない更新プログラムをアンインストールすることが可能です。

「拒否済み」に設定する手順

1. WSUS サーバーにログインします。
2. [スタート] – [管理ツール] – [Windows Service Update Services] をクリックします。
3. WSUS 管理コンソールが起動しますので、左画面から、[すべての更新プログラム] をクリックします。
4. 中央画面の上部から、”承認” を [承認済み]、”状態” を [任意] に設定し、[最新の情報に更新] をクリックし画面を更新します。
5. 中央画面のリストから、問題の更新プログラムを右クリックして、[拒否] をクリックします。
6. ダイアログが表示されますので、.[はい] をクリックして、画面を閉じます。
7. 承認の状態が「拒否済み」となったことを確認します。
8. WSUS クライアントは定期的に WSUS サーバーへ接続を行いますので、そのタイミングで「拒否」の設定を受け取り、配信が停止します。

「削除の承認」に設定する手順

「削除の承認」については、次のブログ記事でご紹介していますので、ご確認ください。

“WSUS で「削除の承認」を行い、更新プログラムを削除する”

https://blogs.technet.microsoft.com/jpwsus/2016/03/29/delete_updates/

「削除の承認」が実施できた場合は、ここで手順は終了です。「削除の承認」ができず、「拒否済み」に設定した場合の更新プログラムのアンインストール方法について次に記載します。

2. 「削除の承認」ができない更新プログラムをアンインストールする

「削除の承認」に対応していない更新プログラムについては、各クライアントで個別にアンインストールが必要となります。台数が多く、手動では実施できない場合は、コマンドをご利用いただく方法も有効です。Windows OS の更新プログラムにつきましては、基本的には wusa.exe を利用して、次のコマンドでインストールされている更新プログラムを削除することが可能です。

削除コマンド

wusa.exe /uninstall /kb:<KB 番号> /quiet /norestart

例) 削除したい KB 番号を指定してください。

wusa.exe /uninstall /kb:1234567 /quiet /norestart

サイレントでアンインストールした後、再起動を抑制するために、/quiet と /norestart を付与しています。再起動を抑制するオプション /norestart を付与した場合は、コマンドの実行が行われた後、再起動されることで正常に削除が完了します。

Windows の Windows Update スタンドアロン インストーラーについて

https://support.microsoft.com/kb/934307/ja

こちらは AD のログオフ スクリプト等の手段で実施することも可能ですので、もし AD 環境で、多数のクライアントに配布されてしまった可能性がある場合には、ログオフ スクリプトをご検討ください。

(参考情報)

一例ではありますが、シャットダウン スクリプト内で上記コマンドを実行する手順について、ご紹介します。

まず上記のコマンドを含む BAT ファイルを作成し、ドメインに割り当てられたグループポリシーのシャットダウンスクリプトに指定します。作成した BAT ファイルはあらかじめ、ドメインコントローラーの以下のパスに配置しておきます。

<SysVol 共有フォルダ>\<ドメイン名>\Policies\<GUID>\Machine\Scripts\Shutdown

＜GUID＞は グループポリシーのGUIDになります。

グループポリシー管理エディタで対象のGPOに接続し、以下を選択します。

[コンピューターの構成] – [ポリシー] – [Windows の設定] – [スクリプト（スタートアップ/シャットダウン）]

詳細ペインより「シャットダウン」のプロパティを開き、「追加」－「参照」より先のパスに配置した BAT ファイルをスクリプトとして選択します。

シャットダウンスクリプト設定後、コンピューターポリシーは、最大で 120 分以内に各クライアントに反映されます。以降各コンピューターがシャットダウンする際に、予期しない更新プログラムが適用されて、再起動待ちとなっている状況から更新プログラムを削除できます。

3. 該当する自動承認規則を無効にする

自動承認規則を有効にすると、その規則に合致した更新プログラムであれば、自動的に承認されることになります。そのため、規則に指定した製品や分類に意図しない更新プログラムが含まれた場合の配信を防ぎたい場合には、自動承認規則を無効にしていただくことをお勧めします。

WSUS 管理コンソールの [オプション] より [自動承認] をクリックします。[更新規則] タブに表示されている規則のチェックをオフにすることで、自動的に実行されることはなくなります。

免責事項

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

みなさま、こんにちは。WSUS サポート チームです。
2016 年 8 月 16 日に、Windows 7 SP1 / 8.1、Windows Server 2008 R2 / 2012 / 2012 R2 において 2016 年 10 月以降ロールアップ モデルに移行することを、以下のブログにて発表いたしました。

Windows 7 および Windows 8.1 のサービス モデルをさらにシンプルに
https://blogs.technet.microsoft.com/jpsecurity/2016/08/16/further-simplifying-servicing-model-for-windows-7-and-windows-8-1/

ロールアップ モデル移行後、第2 火曜日(米国時間) に2 つのロールアップをリリースします。2 つのロールアップはいずれも WSUS から配信が可能ですので、ご運用に合わせて必要なものを選択していただくことが出来ます。

1. セキュリティのみの品質更新プログラム

その月のすべてのセキュリティ修正プログラムを 1 つの更新プログラムにまとめたものです。セキュリティのみの更新プログラムにはその月にリリースされる新規のセキュリティ修正プログラムのみ含まれます。
セキュリティのみの更新プログラムは、WSUS および Microsoft Update カタログで入手可能です。
WSUS 管理コンソールでは、以下のタイトルで表示されます。

日本語 : YYYY 年 MM 月 [OS] 向けセキュリティのみの品質更新プログラム (KB #)
英語　 : [Month, Year] Security Only Quality Update for [OS] (KB #)

2. セキュリティ マンスリー品質ロールアップ

その月の新しいセキュリティ修正とともに前月までのセキュリティおよび非セキュリティの修正 (信頼性に関する修正、不具合の修正など) も含む更新プログラムをセキュリティ マンスリー品質ロールアップとしてリリースします。各月のロールアップは前月のロールアップを置き換えて、累積的にリリースを行っていきます。
セキュリティ マンスリー品質ロールアップは、Windows Update、WSUS および Microsoft Update カタログで入手可能です。
WSUS 管理コンソールでは、以下のタイトルで表示されます。

日本語 : YYYY 年 MM 月 [OS] 向けセキュリティ マンスリー品質更新ロールアップ (KB #)
英語　 : [Month, Year] Security Monthly Quality Rollup for [OS] (KB #)

ただし、以下のブログ記事で発表いたしましたとおり、上記 2 つのロールアップは、共に「セキュリティ問題の修正プログラム」の分類で配信されます。お客様によっては、累積のためサイズが大きく、非セキュリティの修正が含まれる「セキュリティ マンスリー品質ロールアップ」は配信せずに、「セキュリティのみの品質更新プログラム」だけを配信したいというご要望もあるかと思います。その場合、自動承認規則で「セキュリティ問題の修正プログラム」を特定のグループに承認するように設定していると、意図せず「セキュリティ マンスリー品質ロールアップ」がクライアントに配信されることになります。

More on Windows 7 and Windows 8.1 servicing changes
https://blogs.technet.microsoft.com/windowsitpro/2016/10/07/more-on-windows-7-and-windows-8-1-servicing-changes/

Windows 7 および Windows 8.1 のサービス モデル変更についての追加情報
https://blogs.technet.microsoft.com/jpsecurity/2016/10/11/more-on-windows-7-and-windows-8-1-servicing-changes/

そのため、「セキュリティ マンスリー品質ロールアップ」は配信しない運用とされる場合は、「セキュリティ問題の修正プログラム」を特定のグループに承認するように設定した自動承認規則を無効にして、必要な更新プログラムを手動承認する運用に変更することをご検討ください。

自動承認規則は、WSUS 管理コンソール内の [オプション] – [自動承認] より、対象の自動承認規則の横のチェック ボックスを外すことで無効化することが出来ます。

また、もし意図せず「セキュリティ マンスリー品質ロールアップ」が配信された場合は、お手数ですが、次のブログ記事の内容をご参考いただき、対処についてご検討賜りますようお願い申し上げます。

WSUS で予期しない更新プログラムを展開してしまったときの対応方法
https://blogs.technet.microsoft.com/jpwsus/2016/10/07/stop-unexpectedupdates/

なお、System Center Configuration Manager (SCCM) を利用して、更新プログラムを配信している場合は、次のブログ記事をご一読ください。

2016 年 10 月からのロールアップ リリースに伴う System Center Configuration Manager 運用の注意点
https://blogs.technet.microsoft.com/systemcenterjp/2016/10/10/rollup-configmgr-pointtonote/

(補足情報 1)

「セキュリティのみの品質更新プログラム」と「セキュリティ マンスリー品質ロールアップ」を同時に承認した場合、どちらの更新プログラムもクライアント端末に配信されることになります。同時に承認した場合の動作につきましては、次のブログ記事にて詳細に説明しておりますので、ご確認下さいませ。

Windows 7 および Windows 8.1 のサービス モデル変更についての追加情報
– 両方の更新プログラムをインストールした場合に予想されること
https://blogs.technet.microsoft.com/jpsecurity/2016/10/11/more-on-windows-7-and-windows-8-1-servicing-changes/

(補足情報 2)
ロールアップの更新プログラムの配信に起因して、下記のブログにて紹介している事象と類似の事象 (更新プログラムの検出処理によって CPU 使用率が高騰する事象) が発生したとの報告がございますため、対処方法をご案内いたします。

– 古い「IE の累積的なセキュリティ更新プログラム」が承認されていると、更新プログラムの検出処理時に WSUS クライアントの CPU 使用率が高くなる
https://blogs.technet.microsoft.com/jpwsus/2015/04/27/ie-354/

ロールアップの更新プログラム向けに、「拒否済み」に設定する対処方法の実施手順を改めてお纏めいたしました。もし類似の事象が発生した場合には、上から順に実施をご検討くださいますよう、お願いいたします。

– 「拒否済み」に設定する更新プログラムの確認方法
1. Microsoft Update カタログ サイトに接続します。
Microsoft Update カタログ
http://catalog.update.microsoft.com/v7/site/home.aspx
2. 画面右に表示されているテキストボックスに、配信対象のロールアップの KB 番号を入力して、[検索] をクリックします。
3. 表示された更新プログラムの一覧から、問題が発生している クライアントの OS  と アーキテクチャに対応するものをクリックします。
4. 追加で表示された画面から、[パッケージの詳細] タブを表示します。
[この更新プログラムは、次の更新プログラムを置き換えます] に表示されている更新プログラムが、検索したロールアップの更新プログラムが置き換えている更新プログラムとなります。
WSUS サーバー上で拒否済みの設定を行う対象となりますので控えておきます。

– 「拒否済み」の設定方法
1. WSUS 管理コンソールを起動し、[Update Services] – [<サーバー名>] – [更新] に移動します。
2. メニューバーから [操作] – [検索] の順に選択します。
3. 検索画面が表示されますので、「拒否済み」に設定する更新プログラムの KB 番号入力して [検索] をクリックします。
4. 検索結果が表示されますので、拒否に設定する更新プログラムを Shift キーを押下しながら複数一括選択します。
5. 選択した当該更新プログラム上で右クリックし、[拒否] を選択します。
6. メッセージが表示されますので [はい] を選択します。
7. 上記の手順を繰り返し、配信対象のロールアップによって置き換えられている更新プログラムを、すべて「拒否済み」に設定します。

みなさま、こんにちは。 WSUS サポート チームです。

本記事では、Windows 10 バージョン 1607 および Windows Server 2016 をご利用されている環境で、WSUS から更新プログラムをダウンロードしようとした際に、ダウンロードが途中から進まなくなる問題についてご案内いたします。本問題が発生したお客様には多大なご迷惑をおかけしておりますことを、深くお詫び申し上げます。

Windows 10 バージョン 1607 および Windows Server 2016 の WSUS クライアントが、WSUS から承認された更新プログラムをダウンロードしようとすると、以下のような画面のまま先に進まない事象が発生します。

※ 以下の画像では 0％ となっていますが、途中まで進む場合もあります。

Windows 10 バージョン 1607 および Windows Server 2016 のすべての WSUS クライアントでこの事象が確認されるわけではなく、通常の Windows Update の処理に比べて時間はかかりますが、最終的にはダウンロードやインストールが完了する場合もあります。この事象は既知の問題として、2016 年 9 月 20 日にリリースされた累積的な更新プログラム KB3193494 で修正されています。

このため、この問題に該当する WSUS クライアントに対して、最新の累積的な更新プログラムのインストーラーをダウンロードし、クライアントごとに個別にインストールしていただくことが、この問題への対処方法になります。

更新プログラムのインストーラーは、弊社の Microsoft Update カタログ から個別に入手することができますので、その方法についてご案内いたします。

更新プログラムのインストーラーを入手する方法
Microsoft Update カタログより更新プログラムのインストーラーをダウンロードすることができます。
最新の累積的な更新プログラムを Microsoft Update カタログ 内で検索し、対象 OS 用の更新プログラムのインストーラーをダウンロードしてください。

– Microsoft Update カタログ
<http://catalog.update.microsoft.com/v7/site/Home.aspx>

※ Windows 10 および Windows Server 2016 の累積的な更新プログラムのリリース情報ついては、こちらからご確認いただけます。

– Windows 10 の更新履歴
<https://support.microsoft.com/ja-jp/help/12387/windows-10-update-history>
また、Microsoft Update カタログからインストーラーをダウンロードする手順については、以下のページをご参照ください。

– Windows 10 – Microsoft Update カタログから更新プログラムを手動でインストールする方法
<https://answers.microsoft.com/ja-jp/windows/forum/windows_10-update/windows-10-microsoft-update/244791a1-a157-4b0e-88e3-2e20a3ac235a>

みなさま、こんにちは。WSUS サポートチームです。

本記事では WSUS API を利用したスクリプトを用いて、ロールアップの更新プログラムをより快適に配信する方法について、ご案内いたします。

以前の記事で紹介した通り、Windows 7 SP1 / 8.1、Windows Server 2008 R2 / 2012 / 2012 R2 において 2016 年 10 月以降ロールアップ モデルへの移行を行っております。

しかし、「セキュリティのみの品質更新プログラム」も「セキュリティ マンスリー品質ロールアップ」も、いずれも「セキュリティ問題の修正プログラム」としてリリースされるため、WSUS の自動承認規則では、片方だけを自動で承認するということは出来ません。

このような場合には、WSUS API を用いたスクリプトを作成すると、より細かな制御を行うことが可能です。本記事では、ロールアップの更新プログラムを「セキュリティのみの品質更新プログラム」に限定して配信するために有効な、下記の 2 種類のサンプル スクリプトについて紹介をいたします。

1. 「セキュリティ マンスリー品質ロールアップ」を拒否済みに設定するスクリプト
2. 自動承認規則の「規則の実行」を行うスクリプト

なお、いずれのスクリプトも弊社内の環境にて正常に動作することを確認しておりますが、ご利用の際には、念のため事前にご検証くださいますようお願いいたします。

1.「セキュリティ マンスリー品質ロールアップ」を拒否済みに設定するスクリプト

こちらにて「セキュリティ マンスリー品質ロールアップ」を拒否済みに設定するスクリプトを提供しております。ダウンロードいただいたスクリプトの名前を DeclineSecurityMonthlyQualityRollup.ps1 と DeclineSecurityAndQualityRollup.ps1 に変更してお使いください。

本スクリプトを利用すると、各 OS 向けのセキュリティ マンスリー品質ロールアップおよび .Net Framework 向けのセキュリティおよび品質ロールアップを拒否済みに設定することが可能です。誤って「セキュリティのみの品質更新プログラム」以外を配信することを抑止したい場合には、本スクリプトをタスク スケジューラー等を用いて定期的に自動実行することで、「セキュリティ マンスリー品質ロールアップ」を自動で拒否に設定することが可能です。

[実行例]

– 下記のスクリプトを実行することで、各 OS 向けのセキュリティ マンスリー品質ロールアップを拒否に設定します。

DeclineSecurityMonthlyQualityRollup.ps1

– 下記のスクリプトを実行することで、.Net Framework 向けのセキュリティおよび品質ロールアップを拒否に設定します。

DeclineSecurityAndQualityRollup.ps1

(補足情報 : 「セキュリティ マンスリー品質ロールアップ」を配信する場合)

「セキュリティ マンスリー品質ロールアップ」を配信する場合には、こちらにて「セキュリティのみの品質更新プログラム」を拒否済みに設定するスクリプトを提供しておりますため、ダウンロードいただいたスクリプトの名前を DeclineSecurityOnlyQualityUpdate.ps1 と DeclineSecurityOnlyUpdate.ps1 に変更してお使いください。

[実行例]

– 下記のスクリプトを実行することで、各 OS 向けのセキュリティのみの品質更新プログラムを拒否に設定します。

こちらはタイトルに「Security Only Quality Update」を含む更新プログラムが拒否済みの対象です。

DeclineSecurityOnlyQualityUpdate.ps1

– 下記のスクリプトを実行することで、.Net Framework 向けのセキュリティのみの更新プログラムを拒否に設定します。

こちらはタイトルに「Security Only Update」を含む更新プログラムが拒否済みの対象です。

DeclineSecurityOnlyUpdate.ps1

2. 自動承認規則の「規則の実行」を行うスクリプト

こちらにて自動承認規則の「規則の実行」を行うスクリプトを提供しております。ダウンロードいただいたスクリプトの名前を Apply-InstallApprovalRules.ps1 に変更してお使いください。

本スクリプトを用いますと自動承認規則の「規則の実行」をスクリプトから行うことが可能です。自動承認規則では拒否に設定されていない更新プログラムが自動承認の対象となります。このため、上述の「1」のスクリプトにて「セキュリティ マンスリー品質ロールアップ」を拒否済みに設定した後に、本スクリプトを実行することで、「セキュリティ マンスリー品質ロールアップ」以外の「セキュリティのみの品質更新プログラム」を含む更新を、全て自動で承認することが出来ます。

[事前準備]

本スクリプトを利用する場合には、対象の自動承認規則の下記のチェック ボックスを事前に外しておきます。チェック ボックスを外さないとスクリプトの実行のタイミングと関係なく、更新プログラムが同期されたタイミングで規則に合致する更新プログラムが承認されてしまいます。

[実行例]

– 下記のスクリプトを実行することで、対象の自動承認規則の「規則の実行」を行ないます。

Apply-InstallApprovalRules.ps1 -TargetApprovalRule <承認をスクリプトから実行する自動承認規則名 (例 : “既定の自動承認規則” )>

いかがでしたでしょうか。スクリプトを改修すると上記よりもさらに細かく制御を行うことも可能です。WSUS API の詳細については下記の公開情報に纏まっておりますので、興味のある方は是非ご参考にしてください。

– Windows Server Update Services 3.0 Class Library

https://msdn.microsoft.com/en-us/library/ms744624(v=vs.85).aspx

– 注意事項

サンプル スクリプトは弊社環境で検証した上でご案内しておりますが、弊社にてその動作を保証するものではございません。ご使用の際は、お客様の環境に合わせて変更いただき、十分にテストした上で、ご利用くださいますようお願いいたします。

こんにちは。WSUS サポート チームの柴谷です。

本日は、Windows 10 1607 (Anniversary Update) バージョンにおける Windows Update for Business と WSUS の関係についてご紹介します。

最近のお問い合わせで、上記タイトルの通り Windows 10 の WSUS クライアントが Windows Update から更新プログラムを取得するようになってしまうという事象が複数報告されております。

また、そのような動作を行った結果、プロキシー サーバー等でインターネットへの接続を制限している環境においては、Update の適用に失敗するという事象として報告いただくこともあります。

このような動作は、Windows 10 1607 バージョンで変更された Windows Update for Business の影響で発生している可能性があります。

Windows Update for Business では、サービス オプションの選択や各更新プログラムの適用時期をコントロールするなどの機能が提供されており、1607 バージョンではこの機能と WSUS からの展開を組み合わせて利用できるようになりました。

詳細は以下の技術情報をご参照いただきたいと思いますが、大きなポイントとしては、Windows Update for Business のポリシーを構成した場合、その構成によって Windows Update および WSUS の両方から更新プログラムを受け取るようになることです。

Windows Update for Business の管理ソリューションとの統合

以下は上記技術情報で紹介されている一例を抜き出したものですが、Windows の更新をインターネット上の Windows Update から取得し、それ以外の更新を WSUS から取得している点に注目してください。

このように、更新プログラムを WSUS および Windows Update の双方から取得するような構成はこれまではありませんでした。

Windows Update for Business のポリシーにて更新プログラムの延期設定を構成することで、WSUS 側での承認管理を行うことなく、クライアント側で更新プログラムの延期をコントロールすることができます。

しかし一方で、WSUS クライアントであるにも関わらず、自動更新で Windows Update から更新プログラムを取得する、という側面もあるため、WSUS 管理者の目線からすると注意が必要です。

具体的には、以下の Windows Update for Business 関連のポリシーを一つでも Windows 10 1607 バージョンで構成をした場合、この Windows 10 は更新プログラムを Windows Update から取得するようになります。

もちろん、WSUS クライアントであることを指定する、[イントラネットの Microsoft 更新サービスの場所を指定する] の設定を行っている環境においてのお話です。WSUS クライアントであることを示す本ポリシーを設定していても、Windows Update for Business のポリシーの動作が優先されるとお考えいただくと分かりやすいと思います。

GPO: HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

「WSUS クライアントに対しては WSUS からのみ更新プログラムを展開したいため、Windows Update から取得されては困る」、という場合の対応としては、上記ポリシーを設定しないことです。これは、各ポリシーをレジストリで直接指定した場合も同様です。

なお、上記ポリシーの中に BranchReadinessLevel という、CB か CBB かを選択するポリシーがあります。この CB/CBB の選択は、Windows 10 の [設定] – [更新とセキュリティ] – [Windows Update] – [詳細オプション] 内の [機能の更新を延期する] の設定と連動しています。従って、本オプションのチェックを入れて CB から CBB に変更した場合も、「Windows Update for Business のポリシーが設定されている」とみなされ、Windows Update から Windows の更新プログラムを取得するようになります。結果的に、現状では CBB 環境に対しては WSUS から Windows の更新プログラムを展開することはできません。WSUS クライアントはすべて CB として運用する必要があります。

また、ユーザーが [機能の更新を延期する] のチェックを入れられないように、BranchReadinessLevel を 16 に固定するように設定をした場合も、同様に「Windows Update for Business のポリシーが設定されている」とみなされ、Windows Update から Windows の更新プログラムを取得するようになります。

以上の通り、WSUS 環境においてクライアントが Windows Update から更新プログラムを取得しないように構成したい場合には注意が必要となります。

もし、意図せず Windows Update から更新が配布されているような状況でお困りの場合には、Windows Update for Business のポリシーが適用されていないか確認してみてください。

なお、この部分の動作については私たちサポート部門としても以前のバージョンとの動作の差異、影響が非常に大きいと感じており、何らかの対応ができないか、開発部門への確認を行っております。進展が得られ次第本ブログを更新する予定です。

みなさま、こんにちは。WSUS サポート チームです。

本記事では、Windows Vista から Windows Update サイトへアクセスした際に Windows Update がなかなか終わらないという問題についてご紹介します。

Windows Vista にて Windows Update を実行すると、下記の「更新プログラムを確認しています…」の画面のままで、数時間経過しても検出が完了しないことがあります。

この問題は、更新プログラムの検出処理にて検出対象の更新プログラムが過去に置き換えた更新プログラムを 1 つ 1 つ遡って評価する処理に起因して発生しています。
リリース年数が長い製品では評価対象となる情報量が多いため、この問題が発生しやすくなります。

この問題に対処する方法としましては、下記ブログにてご紹介しています。

– 「Windows Update がなかなか終わらないな…」と思ったら
<https://blogs.technet.microsoft.com/jpwsus/2016/04/26/never-end-wu/>

上記ブログでは、Windows 7 の環境に対して最新の Windows Update Agent を適用する対処方法をご案内していますが、Windows Vista ではこの問題を改善した Windows Update Agent はリリースされていません。

そのため、置き換え関係の評価処理にてこの問題が発生した場合には置き換え関係の多い更新プログラムを事前に適用することで、検出対象から外し、置き換え関係の評価処理にかかる時間を短縮します。
どの更新プログラムの置き換え関係が多く存在しているかについては、リリースされた後に Microsoft Update カタログより Windows Vista 向けにリリースされた更新プログラムそれぞれの置き換え情報を確認する必要があります。
更新プログラムの検出処理に時間がかかる状況の場合には、都度カタログ サイトの確認が必要となりますが、下記手順にて置き換え情報を確認してください。

Vista の更新プログラムの置き換え情報の確認方法

1. 下記 URL にアクセスし、Microsoft Update カタログを開きます。

– MicrosoftUpdate カタログ
<http://catalog.update.microsoft.com/v7/site/Home.aspx>

2. 右上の検索窓より “Vista” というキーワードで検索します。

3. [最終更新日時] でソートし、リリースされた更新プログラムを確認します。

4. 対象の更新プログラムをクリックし、更新プログラムの詳細を開きます。

5. [パッケージの詳細] タブを開きます。

6. “この更新プログラムは、次の更新プログラムを置き換えます” に記載されている更新プログラムが対象の更新プログラムにより置き換えられた更新プログラムです。

置き換えた更新プログラムの数が多い更新プログラムを手動で適用する方法

1. 下記 URL にアクセスし、Microsoft Update カタログを開きます。

– MicrosoftUpdate カタログ
<http://catalog.update.microsoft.com/v7/site/Home.aspx>

2. 右上の検索窓より置き換えられた更新プログラムの数が多い更新プログラムの KB 番号で検索します。

3. 対象の更新プログラムの “追加” ボタンをクリックします。

4. “バスケットの表示” をクリックします。

5. “ダウンロード” をクリックします。

6. 任意の保存先を指定し、”続行” をクリックします。

7. ダウンロードが開始されますので、完了することを確認します。

8. ダウンロードした更新プログラムを Windows Update を実行する前に適用します。

11 月 29 日 (米国時間) に、Windows 10 バージョン 1607 の Current Branch for Business (CBB) が宣言されました。マイクロソフト、独立したソフトウェア ベンダー (ISVs) 、パートナー、およびお客様は、このリリースについて幅広い展開のための準備が整っている状態にあると考えていると思います。本日、Windows 10 バージョン 1607 (Windows 10 Anniversary Update として知られています) のために更新されたメディアを、Windows Update for Business、Windows Server Update Services (WSUS)、MSDN Subscriptions にリリースします。また 2017 年 1 月 26 日 (米国時間) に、Windows 10 バージョン 1607 のために更新され新しくなったメディアを、Volume Licensing Service Center (VLSC) にリリースする予定です。

11 月 29 日のブログ記事 で触れたとおり、多くの組織にとって特別な対応は不要です。もし 12 月の累積的な更新プログラム (KB 3201845) 、もしくはそれ以降の累積的な更新プログラムをすでにインストールしている場合、そのデバイスはすでに CBB として宣言されたものと同等の機能を有しています。

Windows 10 バージョン 1507 のサービス終了について

1 月 26 日 (米国時間) に Windows 10 バージョン 1607 が VLSC で利用可能となることに伴い、Windows 10 バージョン 1507 の 60 日の猶予期間が開始されます。つまり 2017 年 3 月 26 日 以降、Windows 10 バージョン 1507 はもはやサポートされません。2 つのもっとも新しい CBB バージョンのみがアクティブにサポートされます。

追加情報

Windows 10 機能更新プログラムとサービス オプションごとの現在のバージョンに関する最新のリストについては、Windows 10 release information のページをご参照ください。もし Windows 10 のサービス ストラテジーについて決めかねているようなら、Windows as a service の 5 分間の短いビデオを視聴するか、この quick guide をご覧ください。

みなさま、こんにちは。WSUS サポート チームです。

WSUS 3.0 SP2 は既に延長サポート期間を迎えており、2017 年 7 月 11 日にサポートが終了します。

しかしながら、現在も WSUS 3.0 SP2 の環境をご運用され続けている方は多くいらっしゃると思います。

今回はそのような方達に向けて、弊社米国の開発部門が公開したブログ記事を翻訳いたしましたのでご紹介いたします。サポート期間の終了に伴って WSUS 3.0 SP2 の環境からの移行をご検討されている方は、是非ともご一読ください。

—————————————————–

このポストは、1 月 22 日に投稿された For those on WSUS 3.0 SP2 (or SBS 2011) の翻訳です。

<<https://blogs.technet.microsoft.com/wsus/2016/01/22/for-those-on-wsus-3-0-sp2-or-sbs-2011/>>

著者: Steve Henry

WSUS 3.0 SP2（またはSBS 2011）をご利用中のみなさま

以前の記事で紹介したように、Windows 10 サービス エクスペリエンスを円滑に提供できるよう、Windows Server 2012 以降の WSUSに対しては、新たな更新プログラムを提供しております。しかし、WSUS 3.0 SP2 は既に延長サポート期間を迎えており (2017 年 7 月にはサポート期間が完全に終了)、これらの更新を WSUS 3.0 SP2 に対してリリースする予定はございません。そのため、この機会に WSUS の移行についてもご検討いただけますと幸いです。

また、併せて Windows 10 の展開をご検討中のみなさまに、導入における考慮事項が記載されたガイダンスをいくつか紹介いたします。

WSUS 3.0 SP2 のスタンドアロン環境

本シナリオでは、Windows Server 2012 R2 サーバーまたは Windows Server 2016 サーバーに WSUS を新しく構築し、既存 SUSDB を移行することを推奨します。WSUS の移行方法については、TechNet ガイダンスをご参照ください。新しい WSUS を導入することで、Windows 10 の最新の機能やサービスをご利用いただけます。

Configuration Manager と WSUS 3.0 SP2 環境

機能アップグレードを配布する際に、タスクシーケンスや MDT またはその他メディアベースの展開ツールではなく WSUS を利用したい場合には、前述のスタンドアロン シナリオと同様に、Windows Server 2012 以降の WSUS に移行することを推奨します。

もし、機能アップグレードの展開にメディア ベース配布ツールを利用する場合には、運用を変える必要はありません。ただし、WSUS 3.0 SP2 の環境に向けて Windows 10 のサービシングに対応する更新プログラムを提供する予定はございませんことを、ご留意いただけますようお願いいたします。

WSUS 3.0 SP2 を使用している SBS 2008 と SBS 2011 環境

この場合の推奨は他の環境と少し異なります。サードパーティー ソフトウェアに対してアップデート管理が必要な場合、 WSUS を Windows Server 2012  やそれ以降のメンバーサーバーに移行することで、現在ご利用の環境で Windows 10 サービス エクスペリエンスをご利用いただけます。また、WSUS によるサードパーティーソフトウェアのアップデート配布が不要な場合、Windows Update for Business で Windows 10 の更新プログラムを管理するようグループポリシーを設定することもできます。Windows Update for Business は、最初に設定を行っていただければ、ほとんど運用管理をする必要がないため、日々の運用の手間を最小限にすることができます。また、Windows Update for Business  では Windows 10 の最新ビルドや累積的な更新プログラムを、常に容易に最新の状態を維持することができます。

まとめ

私たちは、現在ご利用いただいているツールを用いて新しいサービス モデルをサポート出来るよう、主なシナリオに対応する追加機能を提供し、次期リリースの改善を続けてまいります。

WSUS 3.0 SP2 では新しいサービスモデルは提供されません。技術的には Windows 10 向けのセキュリティ更新プログラムの同期や配布といった最低限の機能は提供されますが、あくまでも最低限の機能となるため、今後 WSUS 3.0 SP2 上で、Windows 10 マシンが “Windows Vista” と表示されるような不具合が発生する可能性がございます。

これからも、新しいサービシング モデルをご利用していただくために、既存ガイダンスの更新や、ベスト プラクティスの提供を継続してまいります。

11 月 29 日 (米国時間) に、Windows 10 バージョン 1607 の Current Branch for Business (CBB) が宣言されました。マイクロソフト、独立したソフトウェア ベンダー (ISVs) 、パートナー、およびお客様は、このリリースについて幅広い展開のための準備が整っている状態にあると考えていると思います。本日、Windows 10 バージョン 1607 (Windows 10 Anniversary Update として知られています) のために更新されたメディアを、Windows Update for Business、Windows Server Update Services (WSUS)、MSDN Subscriptions にリリースします。また 2017 年 1 月 26 日 (米国時間) に、Windows 10 バージョン 1607 のために更新され新しくなったメディアを、Volume Licensing Service Center (VLSC) にリリースする予定です。

11 月 29 日のブログ記事 で触れたとおり、多くの組織にとって特別な対応は不要です。もし 12 月の累積的な更新プログラム (KB 3201845) 、もしくはそれ以降の累積的な更新プログラムをすでにインストールしている場合、そのデバイスはすでに CBB として宣言されたものと同等の機能を有しています。

Windows 10 バージョン 1507 のサービス終了について

1 月 26 日 (米国時間) に Windows 10 バージョン 1607 が VLSC で利用可能となることに伴い、Windows 10 バージョン 1507 の 60 日の猶予期間が開始されます。つまり 2017 年 3 月 26 日 以降、Windows 10 バージョン 1507 はもはやサポートされません(※1)。2 つのもっとも新しい CBB バージョンのみがアクティブにサポートされます(※2)。

追加情報

Windows 10 機能更新プログラムとサービス オプションごとの現在のバージョンに関する最新のリストについては、Windows 10 release information のページをご参照ください。もし Windows 10 のサービス ストラテジーについて決めかねているようなら、Windows as a service の 5 分間の短いビデオを視聴するか、この quick guide をご覧ください。

(※1)
3/26 以降、Windows 10 1507 バージョンのサポートが行われなくなることにより、セキュリティを含むサービス更新プログラムがリリースされなくなります。最新の更新を受け取るために、1511 以上にアップグレードする必要があります。

(※2)
Windows 10 の CBB は、同時期に二つの CBB ビルドがサポートされます。1607 の CBB ビルドがリリースされたことにより、サポートされる CBB ビルドは 1607 および一つ前の 1511 のみとなります。1507 はサポートされないことになりますが、ユーザー様の移行期間として、60日の猶予期間を設けております。従って、1607 の CBB ビルドがすべてリリースされた 1/26 を起点に猶予期間がスタートし、3/26 に終了します。
詳細は以下の技術情報をご参照ください。

サービスとしての Windows の概要

みなさま、こんにちは。WSUS サポート チームです。

WSUS 3.0 SP2 は既に延長サポート期間を迎えており、2017 年 7 月 11 日にサポートが終了します。

しかしながら、現在も WSUS 3.0 SP2 の環境をご運用され続けている方は多くいらっしゃると思います。

今回はそのような方達に向けて、弊社米国の開発部門が公開したブログ記事を翻訳いたしましたのでご紹介いたします。サポート期間の終了に伴って WSUS 3.0 SP2 の環境からの移行をご検討されている方は、是非ともご一読ください。

—————————————————–

このポストは、1 月 22 日に投稿された For those on WSUS 3.0 SP2 (or SBS 2011) の翻訳です。

<<https://blogs.technet.microsoft.com/wsus/2016/01/22/for-those-on-wsus-3-0-sp2-or-sbs-2011/>>

著者: Steve Henry

WSUS 3.0 SP2（またはSBS 2011）をご利用中のみなさま

以前の記事で紹介したように、Windows 10 サービス エクスペリエンスを円滑に提供できるよう、Windows Server 2012 以降の WSUSに対しては、新たな更新プログラムを提供しております。しかし、WSUS 3.0 SP2 は既に延長サポート期間を迎えており (2017 年 7 月にはサポート期間が完全に終了)、これらの更新を WSUS 3.0 SP2 に対してリリースする予定はございません。そのため、この機会に WSUS の移行についてもご検討いただけますと幸いです。

また、併せて Windows 10 の展開をご検討中のみなさまに、導入における考慮事項が記載されたガイダンスをいくつか紹介いたします。

WSUS 3.0 SP2 のスタンドアロン環境

本シナリオでは、Windows Server 2012 R2 サーバーまたは Windows Server 2016 サーバーに WSUS を新しく構築し、既存 SUSDB を移行することを推奨します。WSUS の移行方法については、TechNet ガイダンスをご参照ください。新しい WSUS を導入することで、Windows 10 の最新の機能やサービスをご利用いただけます。

Configuration Manager と WSUS 3.0 SP2 環境

機能アップグレードを配布する際に、タスクシーケンスや MDT またはその他メディアベースの展開ツールではなく WSUS を利用したい場合には、前述のスタンドアロン シナリオと同様に、Windows Server 2012 以降の WSUS に移行することを推奨します。

もし、機能アップグレードの展開にメディア ベース配布ツールを利用する場合には、運用を変える必要はありません。ただし、WSUS 3.0 SP2 の環境に向けて Windows 10 のサービシングに対応する更新プログラムを提供する予定はございませんことを、ご留意いただけますようお願いいたします。

WSUS 3.0 SP2 を使用している SBS 2008 と SBS 2011 環境

この場合の推奨は他の環境と少し異なります。サードパーティー ソフトウェアに対してアップデート管理が必要な場合、 WSUS を Windows Server 2012  やそれ以降のメンバーサーバーに移行することで、現在ご利用の環境で Windows 10 サービス エクスペリエンスをご利用いただけます。また、WSUS によるサードパーティーソフトウェアのアップデート配布が不要な場合、Windows Update for Business で Windows 10 の更新プログラムを管理するようグループポリシーを設定することもできます。Windows Update for Business は、最初に設定を行っていただければ、ほとんど運用管理をする必要がないため、日々の運用の手間を最小限にすることができます。また、Windows Update for Business  では Windows 10 の最新ビルドや累積的な更新プログラムを、常に容易に最新の状態を維持することができます。

まとめ

私たちは、現在ご利用いただいているツールを用いて新しいサービス モデルをサポート出来るよう、主なシナリオに対応する追加機能を提供し、次期リリースの改善を続けてまいります。

WSUS 3.0 SP2 では新しいサービスモデルは提供されません。技術的には Windows 10 向けのセキュリティ更新プログラムの同期や配布といった最低限の機能は提供されますが、あくまでも最低限の機能となるため、今後 WSUS 3.0 SP2 上で、Windows 10 マシンが “Windows Vista” と表示されるような不具合が発生する可能性がございます。

これからも、新しいサービシング モデルをご利用していただくために、既存ガイダンスの更新や、ベスト プラクティスの提供を継続してまいります。

11 月 29 日 (米国時間) に、Windows 10 バージョン 1607 の Current Branch for Business (CBB) が宣言されました。マイクロソフト、独立したソフトウェア ベンダー (ISVs) 、パートナー、およびお客様は、このリリースについて幅広い展開のための準備が整っている状態にあると考えていると思います。本日、Windows 10 バージョン 1607 (Windows 10 Anniversary Update として知られています) のために更新されたメディアを、Windows Update for Business、Windows Server Update Services (WSUS)、MSDN Subscriptions にリリースします。また 2017 年 1 月 26 日 (米国時間) に、Windows 10 バージョン 1607 のために更新され新しくなったメディアを、Volume Licensing Service Center (VLSC) にリリースする予定です。

11 月 29 日のブログ記事 で触れたとおり、多くの組織にとって特別な対応は不要です。もし 12 月の累積的な更新プログラム (KB 3201845) 、もしくはそれ以降の累積的な更新プログラムをすでにインストールしている場合、そのデバイスはすでに CBB として宣言されたものと同等の機能を有しています。

Windows 10 バージョン 1507 のサービス終了について

1 月 26 日 (米国時間) に Windows 10 バージョン 1607 が VLSC で利用可能となることに伴い、Windows 10 バージョン 1507 の 60 日の猶予期間が開始されます。つまり 2017 年 3 月 26 日 以降、Windows 10 バージョン 1507 はもはやサポートされません(※1)。2 つのもっとも新しい CBB バージョンのみがアクティブにサポートされます(※2)。

追加情報

Windows 10 機能更新プログラムとサービス オプションごとの現在のバージョンに関する最新のリストについては、Windows 10 release information のページをご参照ください。もし Windows 10 のサービス ストラテジーについて決めかねているようなら、Windows as a service の 5 分間の短いビデオを視聴するか、この quick guide をご覧ください。

(※1)
3/26 以降、Windows 10 1507 バージョンのサポートが行われなくなることにより、セキュリティを含むサービス更新プログラムがリリースされなくなります。最新の更新を受け取るために、1511 以上にアップグレードする必要があります。

(※2)
Windows 10 の CBB は、同時期に二つの CBB ビルドがサポートされます。1607 の CBB ビルドがリリースされたことにより、サポートされる CBB ビルドは 1607 および一つ前の 1511 のみとなります。1507 はサポートされないことになりますが、ユーザー様の移行期間として、60日の猶予期間を設けております。従って、1607 の CBB ビルドがすべてリリースされた 1/26 を起点に猶予期間がスタートし、3/26 に終了します。
詳細は以下の技術情報をご参照ください。

サービスとしての Windows の概要