Quantcast
Channel: Japan WSUS Support Team Blog
Viewing all 179 articles
Browse latest View live

WSUS からエクスポートしたカタログファイルが 0KB になる事象について - 続報

$
0
0

皆さま こんにちは。 マイクロソフトの香取です。

 

先日の投稿にて、WSUS からエクスポートしたカタログファイルが 0KB になる事象についてご紹介しましたが、この事象を解決するプログラムがリリースされております。

現時点での最新情報をまとめましたので、WSUS 管理者の方は、是非ご一読ください。

************************************************************

< ! 注意事項 2015 7 1 日 追記>

こちらの記事で紹介しております更新プログラム : KB2828185 はエクスポート元、インポート先の両方に適用が必要です。

KB2828185 の適用により gz 形式のカタログ ファイル圧縮、解凍に対応するため、例えばインポート先に KB2828185 が未適用である場合、 wsusutil.exe import import.xml.gz コマンドを実行すると以下のエラーが発生しますので必ず両方に適用してください。

致命的なエラー: Unable to uncompress package

なお、2015/07/01 現在 WSUS サーバー用の最新の更新プログラムは以下が公開されております。

An update to harden Windows Server Update Services

http://support.microsoft.com/en-us/kb/2938066

 

KB2938066 は過去の修正内容を包括しておりますので、現時点で適用される際はこちらをご検討ください。

 

************************************************************


  

WSUS 4.0 (Windows Server 2012) の場合

CAB file that is exported by using the Wsusutil.exe command is displayed as 0 KB on a Windows Server 2012-based WSUS server
http://support.microsoft.com/kb/2819484/en-us

 ※ 修正プログラムとしてのリリースとなります。適用の注意点につきましては以下のサイトを参照ください。

Hotfix Online Submission – 修正プログラムの入手に関するご案内とご注意
http://support.microsoft.com/gp/HotfixNotice

  

WSUS 3.0 SP2 (Windows Server 2003 R2, Windows Server 2008, or Windows Server 2008 R2) の場合

An update for Windows Server Update Services 3.0 SP2 is available (KB2828185)
http://support.microsoft.com/kb/2828185/en-us 

 

WSUS サーバーに上述の修正プログラムを適用したうえで、エクスポート / インポート時に実行するコマンドを、以下例のように変更することにより、問題を回避できます。

  wsusutil.exe export export.xml.gz export.log
  wsusutil.exe import import.xml.gz import.log
  

なお適用後はサーバーを再起動してください。

 

また KB2828185 には KB2734608 が含まれております。 適用する際にはご留意くださいますようお願いいたします。

KB2734608 の詳細につきましては以下のサイトをご参照ください。

<重要> WSUS の更新プログラムは確実に最新版の適用を行ってください
http://blogs.technet.com/b/jpwsus/archive/2013/03/13/lt-gt-wsus.aspx

  

WSUS 親子構成されている環境の場合、または WSUS NLB を構成されている場合には、手順上の留意点があります。

この点は 上記 KB2828185 上に記載されておりますが、若干わかりづらいため、以下の blog をあわせてご参照ください。blog の内容は KB2734608 を対象としておりますが、今回の更新プログラムについても同様です。

WSUS 3.0 SP2 の Windows 8 / Windows Server 2012 対応について (KB2734608)
http://blogs.technet.com/b/jpwsus/archive/2012/09/05/kb2734608.aspx

 ---------一部抜粋---------

親子構成の WSUS サーバーへ KB2734608 を適用する際には、下記の順で適用をお願いします。

1. 親の WSUS サーバーを Microsoft Update サイトと同期させる

2. KB2734608 を適用する

3. 再度 Microsoft Update サイトと同期させる

4. 同期が完了するまで待つ

5. 子の WSUS サーバーへ KB2734608 を適用し、親の WSUS サーバーと同期させる

NLB 構成の WSUS サーバーを運用されている場合には、KB2734608 "How to upgrade NLB on all computers" セクション内手順をご確認ください。

ちなみに、ステップ 2 と 3 は記載が曖昧なため、下記操作であるとご理解ください。

2. すべてのフロント エンド WSUS サーバーで、下記コマンドを実行し IIS と WSUS のサービスを停止します。

iisreset /stop
net stop wsusservice

3. すべてのフロント エンド WSUS サーバーで、nlb.exe disable コマンドを実行します。

※コマンド実行例
nlb.exe disable all

もし KB2734608 の適用前に Windows 8 / Windows Server 2012 を WSUS 3.0 SP2 サーバーへ接続した場合には、KB2734608 の適用後に WSUS クライアント上で下記手順を実施してください。

1. 管理者権限のコマンドプロンプトを起動します

2. 下記のコマンドを順に実行します

> Net stop wuauserv
> rd /s %windir%\softwaredistribution\
> Net start wuauserv

3. 次回の WSUS サーバー接続時には、正しく処理が行われます

---------------------------

 


親子構成の WSUS でサポートされるバージョンについて

$
0
0

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

Windows Server 2003 のサポート終了に伴い、WSUS 3.0 SP2 から Windows Server 2012 の WSUS (WSUS 6.x) へ移行を検討されている方も多いかと思います。
本記事では親子構成の WSUS において、サポートされるバージョンについてご案内いたします。

親子構成ではアップストリーム WSUS サーバーとダウンストリーム WSUS サーバーを構成することになりますが、アップストリーム WSUS サーバーのバージョンが、ダウンストリーム WSUS サーバーのバージョン以上である構成のみサポートされます。

例えば、以下のような構成はサポートされます。

1. アップストリーム > ダウンストリーム
アップストリーム WSUS サーバー : WSUS 6.x
ダウンストリーム WSUS サーバー : WSUS 3.0 SP2

2. アップストリーム = ダウンストリーム
アップストリーム WSUS サーバー : WSUS 6.x
ダウンストリーム WSUS サーバー : WSUS 6.x

または

アップストリーム WSUS サーバー : WSUS 3.0 SP2
ダウンストリーム WSUS サーバー : WSUS 3.0 SP2

一方以下のような構成についてはサポートされません。

3. アップストリーム < ダウンストリーム
アップストリーム WSUS サーバー : WSUS 3.0 SP2
ダウンストリーム WSUS サーバー : WSUS 6.x

サポートされない構成をご利用いただいていても製品仕様・設計上の観点からは問題なく動作すると考えられますが、弊社開発部門にて出荷時検証を経ておりませんので、何らかの問題が発生する可能性がございます。
今後、親子構成を組んでいる WSUS のバージョンアップや移行をご検討されている場合は、何卒ご留意賜りますようお願い申し上げます。

Windows 10 の Windows Update の自動更新設定

$
0
0

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

 

7 月 29 日に、ついに Windows 10 がリリースされましたが、みなさまもうアップグレードはされましたでしょうか?!

このブログ記事では、読者のみなさまが気になっているであろう Windows 10 における Windows Update の自動更新設定についてご紹介します。Windows 10 の環境では、Windows Update の自動更新の設定方法が大きく変わりました。下記の順にご案内していきます。

 

・ Windows Update 関連の設定箇所について

・ 自動更新の設定について

 

Windows Update 関連の設定箇所について

Windows 10 からは、コントロール パネルの Windows Update の項目がなくなり、自動更新を含む Windows Update 関連の設定は、すべて 「設定」から行うようになりました。

 

下記の手順にて Windows Update 関連の設定画面を開けます。

 

[スタート] - [設定] を選択します。

 

[更新とセキュリティ] をクリックします。

 

Windows 10 の Windows Update 画面が表示されます。

 

自動更新の設定について

自動更新の設定は、上記画面内にある、[詳細オプション] をクリックすると下記の 2 種類から選択することができます。

- 自動 (推奨)

- 再起動の日時を設定するように通知する

 

*補足*

- 自動 (推奨)

更新プログラムのインストール、再起動まで自動で行えます。

 

- 再起動の日時を設定するように通知する

更新プログラムのインストール完了後、再起動のタイミングを選択することが  可能です。

 

また、Windows 10 以前の OS では、[コントロールパネル] - [システムとセキュリティ] - [Windows Update] から、以下の設定を行うことができました。

 

a) 更新プログラムを自動的にインストールする (推奨)

b) 更新プログラムをダウンロードするが、インストールを行うかどうかは選択する

c) 更新プログラムを確認するが、ダウンロードとインストールを行うかどうかは選択する

d) 更新プログラムを確認しない (推奨されません)

 

Windows 10 では、このうち b) ~ d) の設定を [Windows Update] から行うことができなくなり、既定では a) と同等の動作です。

但し、Windows Update のグループ ポリシーについては、Windows 10 以前の OS のように、構成することができます。たとえば、[自動更新を構成する] ポリシーにて、更新プログラムの検出、ダウンロード、インストール タイミングを構成した際の [Windows Update] 画面は、以下のようになります。(スクリーンショット内の、[一部の設定は組織によって管理されています。] と記載されている環境は、グループ ポリシーによって自動更新の設定が行われていることを示します。)

 

[自動更新を構成する] ポリシーが「無効」の場合

 

[自動更新を構成する] ポリシーにて、「2 – ダウンロードとインストールを通知」が有効となっている場合

 

[自動更新を構成する] ポリシーにて、「3 - 自動ダウンロードしインストールを通知」が有効となっている場合

 

[自動更新を構成する] ポリシーにて、「4 - 自動ダウンロードしインストール日時を指定」が有効となっている場合

 

[自動更新を構成する] ポリシーにて、「5 - ローカルの管理者の設定選択を許可」が有効となっている場合

 

Windows 10 環境向けの WSUS / Windows Update に関する情報は、これからも順次公開していきますので、乞うご期待ください!

 

 

 

WSUS で不要な更新プログラムのインストーラーを削除する

$
0
0

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

WSUS サーバーを長期間運用している、または自動承認規則で製品などにフィルターをかけずに運用していると、知らない間に更新プログラムのインストーラー (コンテンツ ファイル) が多くダウンロードされており、「ディスク サイズの空き容量がない!」といったトラブルが発生することがあります。WSUS は自動でメンテナンスを行う機能を持っておりませんので、ディスク サイズの空き容量が少なくなった場合は、「サーバー クリーンアップ ウィザード」を実行して、不要なファイルを削除する必要があります。

でも、「サーバー クリーンアップ ウィザードを実行しても、あまり不要なファイルが削除されない!空き容量が増えない!」という結果になったことはありませんしょうか。

そこで今回は、WSUS で不要な更新プログラムのインストーラーを確実に削除するためのポイントについてご紹介いたします。

・「サーバー クリーンアップ ウィザード」で WSUS で不要な更新プログラムのインストーラーを削除する
・「サーバー クリーンアップ ウィザード」実行後も 更新プログラムのインストーラーが削除できない場合

「サーバー クリーンアップ ウィザード」で WSUS で不要な更新プログラムのインストーラーを削除する
サーバー クリーンアップ ウィザード項目で「不要な更新ファイル」を実行することで、不要な更新ファイルを削除することができますが、削除対象となる更新プログラムは「拒否済み」のステータスとなっている必要があります。
そのため、以下の流れで不要な更新プログラムのインストーラーを削除します。

(作業の流れ)
STEP1 : 更新プログラムを「拒否済み」とする

STEP2 : サーバー クリーンアップ ウィザードで「不要な更新ファイル」を実行する


「サーバー クリーンアップ ウィザード」実行後も更新プログラムのインストーラーが削除できない場合
上記流れで「サーバー クリーンアップ ウィザード」を実行した場合でも、更新プログラムのインストーラーが削除できないことがあります。代表的な要因は以下の通りです。

<要因 1 : WSUS オプション設定が既定から変更されている>
WSUS オプションの「更新ファイルと更新言語」にて、「更新プログラムが承認されている場合にのみ、更新ファイルをこのサーバーにダウンロードします」のチェックが既定では「オン」です。この設定が、「オフ」の構成の場合には、このままクリーンアップを実行しても「拒否済み」の更新プログラムのインストーラーを削除することは出来ません。このような構成の場合には、既定の「オン」に変更し、クリーンアップウィザード実施後に、再度、「オフ」に戻します。
  


<要因 2 : 「拒否済み」とした更新プログラムのインストーラーが他の更新プログラムで利用されており、かつ、インストール承認を行っている>
例として、以下の更新プログラムは、同一のインストーラーを利用しています。このような更新プログラムは、一方を「拒否済み」としても、もう一方で「インストール承認」済みの場合には、更新プログラムのインストーラーを削除することが出来ません。
Windows 7 for x64-based Systems 用の更新プログラム (KB974431)
Windows Server 2008 R2 x64 Edition 用の更新プログラム (KB974431)

見分け方としては、WSUS 管理コンソールで、「拒否済み」としても、ファイルの状態列はインストール承認ステータスのままとなります。
  


<要因 3 : 子 WSUS が「自律」の構成である もしくは 過去に「自律」の 子 WSUS が存在していた>
親子 WSUS 構成で、子 WSUS が「自律」の場合、子 WSUS 側で親 WSUS とは異なる承認情報を保持できます。たとえば、親 WSUS 側では未承認の更新プログラムも、子 WSUS が必要とすれば、親 WSUS は Microsoft Update カタログから更新プログラムのダウンロードを行います。このような処理に伴い、「子 WSUS の要求によりダウンロードした」ものであることを示すフラグを、データベース内のファイル情報に対して設定します。

このフラグが設定されたファイルは、親 WSUS 側でサーバー クリーン アップウィザードを実行しても削除されないよう設計されています。過去に子 WSUS が存在し、現在はすでに登録解除を行っている場合にもこの状態は変化いたしません。このため、サーバー クリーンアップ ウィザードでこのフラグが設定された不要な更新プログラムのインストーラーを削除できるようにするためには、データベースに対して SQL を発行し、フラグを解除する作業が必要になります。

子 WSUS 側で必要とした更新プログラムの有無の確認方法 と 設定されたフラグを解除する方法 (※)をご紹介します。
(※ 重要) データーベース内の情報を変更する操作となりますので、事前に必ず WSUS データーベースのバックアップをご実施ください。
WSUS 3.0 SP2 をデータベースごと移行する方法について
http://blogs.technet.com/b/jpwsus/archive/2012/09/20/wsus-sql-migration.aspx

<< 子 WSUS 側で必要とした更新プログラムの有無の確認 と 設定されたフラグを解除する方法>>
親 WSUS 側で子 WSUS によって必要とされている更新プログラムの有無は、WSUS 管理コンソールから目視で確認をすることができません。以下の手順にて、フラグが設定されている更新プログラムが存在するか確認します。

補足:
手順は、WSUS のデータベースが、SQL Server であるか Windows Internal Database (WID) で
あるかで異なります。どちらのデータベースを現在利用しているかにつきましては、WSUS サーバーの
以下のレジストリから判断できます。
%computername%\MICROSOFT##SSEE となっていれば、WID です。それ以外は SQL Server です。

******
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup]
- SqlServerName (REG_EXPAND_SZ)
******

SQL Server 環境の手順
1. SQL Server Management Studio を起動し、WSUS のデータベースを実行しているデータベース エンジンに接続します。
2. Microsoft SQL Server Management Studio 画面が起動したら、画面左ペインの[データベース] ツリーを展開します。
3. [SUSDB] を右クリックし [新しいクエリ] をクリックします。
4. 右ペインに表示された新しいクエリ画面に、以下のとおり入力し、ツールバーの [実行] をクリックするかもしくは F5 キーを押して、実行を開始します。
SELECT COUNT(DSSRequestedDownload) FROM dbo.tbFileOnServer WHERE DSSRequestedDownload = 1

※この結果、2 行目に表示される数値が 0 以外であれば、フラグの設定を持つ更新プログラムのが存在しています。
その場合は引き続き下記の手順をご実施します。

<手順>
5. 引き続き下記 2 件のコマンドを順に実行します。
update tbfileOnServer set actualstate=1 where (actualstate=8 or actualstate=9 or actualstate=10) and DSSRequestedDownload = 1
update tbFileOnServer set DSSRequestedDownload = 0 WHERE DSSRequestedDownload = 1

6. 正しく変更されたかの確認のために、下記コマンドを実行します。
SELECT COUNT(DSSRequestedDownload) FROM dbo.tbFileOnServer WHERE DSSRequestedDownload = 1

結果が 0 なら正しく変更されています。


WID 環境の手順
1. 管理者権限でコマンドプロンプトを起動します。
2. 下記コマンドにてフォルダを移動します。
cd /d %ProgramFiles%\Update Services\setup

3. 引き続き下記コマンドを実行します。executesql.exe は実行結果をプロンプト画面に表示しませんので、出力先ファイル名を指定し、その内容を確認する手順となります。「一行として」投入してください。

executesql.exe -S %computername%\MICROSOFT##SSEE -d "SUSDB" -Q "SELECT COUNT(DSSRequestedDownload) FROM dbo.tbFileOnServer WHERE DSSRequestedDownload = 1"  -l result1.txt

4. 以下のコマンドを実行して出力ファイル内容を確認します。
TYPE result1.txt

結果出力例)
<no name>
10591

※この結果、2 行目に表示される数値が 0 以外であれば、フラグの設定を持つ更新プログラムのが存在しています。
その場合は引き続き下記の手順をご実施します。

<手順>
5. 引き続き下記2件のコマンドを順に実行します。
executesql.exe -S %computername%\MICROSOFT##SSEE -d "SUSDB" -Q "update tbfileOnServer set actualstate=1 where (actualstate=8 or actualstate=9 or actualstate=10) and DSSRequestedDownload = 1"

executesql.exe -S %computername%\MICROSOFT##SSEE -d "SUSDB" -Q "update tbFileOnServer set DSSRequestedDownload = 0 WHERE DSSRequestedDownload = 1"

6. 正しく変更されたかの確認のため、下記コマンドを実行します。
末尾のファイル名 result2.txt は任意の名前で結構です。
executesql.exe -S %computername%\MICROSOFT##SSEE -d "SUSDB" -Q "SELECT COUNT(DSSRequestedDownload) FROM dbo.tbFileOnServer WHERE DSSRequestedDownload = 1" -l result2.txt

7. 以下のコマンドを実行してファイル内容を確認します。
2 行目に表示される数値が 0 なら正しく変更されています。

TYPE result2.txt

結果出力例)
<no name>
0

Office 2010 32 bit を使用している環境に、Office 2010 64 bit の更新プログラムが検出される

$
0
0

(2015 年 11 月 2 日 更新 - 修正完了し、解消いたしました。)

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

2015 年 10 月 28 日以降、Office 2010 の 32 ビット版を使用している環境において、64 ビット版 Office 2010 用の更新プログラムが検出されるとの報告がございます。この事象について詳細をお伝えいたします。
本事象は WSUS に接続するクライアントだけではなく、Microsoft Update や Microsoft Intune に接続する環境でも発生します。状況に進展があり次第、こちらの記事に情報を公開させていただきますので、今しばらくお待ちくださいますようお願いいたします。
本事象につきましては、2015 年 10 月 31 日 に Microsoft Update サイト側の修正が完了し、現時点では解消しております。解消前に適用されていた、64 ビット版の KB2687413 および KB2837582 につきましては、アンインストールせずにそのままご使用いただいても動作に問題はございません。解消前にご案内しておりました、事象について以下にご紹介させていただきます。

- 現象
2015 年 10 月 28 日以降、Office 2010 の 32 ビット版を使用している環境において、Microsoft Update による更新プログラムの検出を実行した際、以前は検出されなかった以下の 64 ビット版 Office 2010 用の更新プログラムが適用対象として検出される現象が確認されています。

KB2687413
MS13-075: Description of the security update for Microsoft Office IME (Chinese): September 10, 2013
https://support.microsoft.com/en-us/kb/2687413

KB2837582
October 14, 2014 update for Office 2010 (KB2837582)
https://support.microsoft.com/en-us/kb/2837582

KB2687455
Description of Office 2010 Service Pack 2
https://support.microsoft.com/en-us/kb/2687455

上記の更新プログラムのうち KB2687413 および KB2837582 については、64 ビット版の更新プログラムの適用を実行した場合、正常に適用が完了しますが、KB2687455 の 64 ビット版 Office 2010 SP2 の適用は失敗します。


注意:
1. KB2687413 は検出操作以前に適用されていた更新プログラムの種類に依存して、検出されない環境もあります。
2. 上述の他に、以下の 64 ビット版の更新プログラムも検出されますが、これは、10 月 28 日以前からの動作です。

KB2553347
July 14, 2015, update for Office 2010 (KB2553347)
https://support.microsoft.com/en-us/kb/2553347

3. WSUS を使用した更新プログラムの展開を行っている環境でも同事象が発生します。


- 状況
現在、Microsoft Update サイトの検出処理等、原因の調査を弊社開発部門と協業の上進めております。
本事象につきましては、Microsoft Update サイトに問題があったため、修正いたしました。


- 対処方法
Office 2010 の 32 ビット版を使用している場合、検出された 64 ビット版の更新プログラムは、適用の必要はございませんので、適用対象から除外くださいますようお願いいたします。
なお、すでに 64 ビット版の KB2687413 および KB2837582 が適用された環境につきましては、更新対象となる Office IME 2010 の動作には影響ございませんので、アンインストールせずそのままご使用いただいても動作に問題はございません。

動的メモリを有効にしている Hyper-V 仮想マシンで WSUS の同期が全く進まない / 完了しない現象

$
0
0

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

仮想環境上で WSUS サーバーをご運用されている方も、たくさんいらっしゃるかと思います。本記事では、動的メモリを有効にしている Hyper-V 仮想マシン上の WSUS サーバーで確認されている同期が全く進まない / 完了しない現象についてご紹介します。

まず仮想環境上で WSUS サーバーを動作させる構成は、非常に多くの実績がある構成ですので、ご安心ください。弊サポート チームにて受け付けるお問い合わせでも、いまやほとんどの WSUS サーバーが仮想環境上で動作しています。

しかし、残念ながら TechNet 上の技術情報では Hyper-V 等の仮想環境上で WSUS を動作させる際の注意点について記載はございません。これは、開発の段階にて動的メモリ等の仮想環境の固有の機能を意識した検証が充分に行われていないためです。仮想環境の固有の機能を利用している場合でも、ほとんどの場合には問題なく WSUS サーバーは動作しますが、該当の機能が問題となることもあります。

今回は仮想環境固有の問題として、動的メモリを有効にしている Hyper-V 仮想マシン上の WSUS サーバーで稀に発生する現象をご案内します。

 

動的メモリを有効にしている Hyper-V 仮想マシンで WSUS の同期が全く進まない / 完了しない現象 )

動的メモリの影響で、稀に WSUS の処理に上手くメモリが割り当てられず、同期処理が全く進まないという現象が確認されています。 動的メモリをご利用いただいている環境で、下記の同期画面から処理が全く進まない場合には、本現象に該当している可能性が非常に高いと考えられます。

 


 

この場合、下記のいずれかの対処をしていただくことで、現象を改善していただくことが可能です。

- 動的メモリではなく固定メモリに設定を変更していただく

- 動的メモリの設定にて、最小メモリをより大きな値に変更いただく

 

( 上記の現象に合致しているか、より詳細に判別する方法 )

下記の 2 点をご確認いただくと、上記の現象に合致しているか、より詳細に下記の 2 点をご確認いただくと、上記の現象に合致しているか、より詳細に判別することが可能です。

- WSUS が動作している Hyper-V 仮想マシンで、動的メモリが有効に設定されていること

- WSUS サーバー内のログ「%ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log」に

  下記のような記録が出力され続けていること

 

・ 出力例 1

---------------------------------

SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないかアクセスできません。インスタンス名が正しいこと、および SQL Server がリモート接続を許可するように構成されていることを確認してください。 (provider: 名前付きパイプ プロバイダ, error: 40 - SQL Server への接続を開けませんでした)

---------------------------------



・ 出力例 2

---------------------------------

Timeout に達しました。操作が完了する前にタイムアウト期間が過ぎたか、またはサーバーが応答していません。

---------------------------------

 

2015 年12 月に公開されたセキュリティ情報 MS15-135 について

$
0
0

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

本記事では  2015 年12 月に公開されたセキュリティ情報  MS15-135 についてご案内いたします。

 

弊社公開のセキュリティ情報を元に更新プログラムの展開を検討されているお客様から

2015 年12 月に公開された MS15-135について、次のようなご質問をいただきます。

・WSUS や MBSA を使っても検出されない。

・更新プログラムが適用されない。

・更新プログラムが見つからない。

・どうやったら適用できるのか?

 

結論から申しますと、MS15-135 に対応した更新プログラムはリリースしていない (MS15-128 にその内容を含んでいる) ことがその理由となります。

 

脆弱性の報告としてのMS15-135を公開させていただきましたが、当該脆弱性への対応として紐づく更新プログラムは存在せず、MS15-128で提供させていただく更新プログラム (KB3109094) にて脆弱性に対応することができます。

したがいまして、MS15-135 の更新プログラムは WSUS や MBSA を使っても検出されません。

こちらは想定する動作でありMS15-135が検出されないこと自体に問題はなく、MS15-128 (KB3109094) が検出、適用されていることをご確認いただければ問題ございませんので、どうぞご安心ください。

 

ご参考情報

以下は KB3109094 の公開ページとなります。

[MS15-128 と MS15-135] Windows カーネル モード ドライバーのセキュリティ更新プログラムについて (2015 年 12 月 8 日)

< https://support.microsoft.com/ja-jp/kb/3109094>

Windows Server 2012 / 2012 R2 の WSUS の重要な更新 (KB 3095113) について

$
0
0

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

先日 Windows Server 2012 / 2012 R2 の WSUS に適用可能な更新プログラム KB 3095113 がリリースされましたが、この更新プログラムは Windows 10 対応に関する修正が含まれております。

ただ、「Windows 10 に更新プログラムを配信するためには、この更新プログラムを適用しなければいけないのか?」「KB 3095113 はどういった修正が含まれるのか」といった疑問をお持ちの方も多いのではないでしょうか。

この疑問にお答えする記事が、弊社米国の開発部署が管理しているブログにて公開されましたので、日本の WSUS サポート チームでも、お客様のリクエストにお答えして、その記事を翻訳させていただきました。これから Windows 10 の更新プログラム管理をご検討されている管理者の皆様は、是非ともご一読ください。



このポストは、12 月 4 日に投稿された Important update for WSUS 4.0 (KB 3095113) の翻訳です。


著者
: Steve Henry   

既にご存知の方もおられるかもしれませんが、私たちは 今後数週間のうちに Windows 10 の最初のインプレース アップグレードである Windows 10 1511 への機能アップグレードを WSUS に向けてリリースする予定です。この展開シナリオに完全対応するために、Windows Server 2012 および Windows Server 2012 R2 の WSUS 用の更新プログラム (KB 3095113) を公開しました。この更新プログラムのリリース後、更新プログラムの適用に関して以下のような質問が寄せられています。:

・この更新プログラム (KB 3095113) は Windows 10 をサポートするために必要ですか?

・この更新プログラム (KB 3095113) をインストールしない場合、何が起こるのですか?

・修正プログラム (Hotfix) ではないダウンロード コンテンツ (DLC) 形式でのリリースまで待つべきですか?

・本リリースに関する既知の問題はありますか?



”Windows 10 サポート” に関する解説

WSUS で同期やインポートを行って、Windows 10 用の更新プログラムを配布するにあたり、更新プログラム (KB 3095113) を WSUS に適用する必要があるのか、気になる方もいるのではないでしょうか。 もしそれが気になる場合は、Windows 10 の更新プログラムを配布するために WSUS への適用が必要な更新プログラムはありませんのでご安心ください。Windows 10 自体はこれまでの歴史においても非常に大きなリリースとなりますが、WSUS の観点では、これまでリリースした製品の一部というだけに過ぎず、Windows 10 の更新プログラム (セキュリティ更新プログラムを含む) を配布するにあたって、WSUS 側での変更は必要ありません。そのため、WSUS 3.0 SP2 (SBS 2011 を含む) および更新プログラムを適用していない Windows Server 2012 / 2012 R2 の WSUS で、Windows 10 の更新プログラムを配布することができます。但し、機能アップグレードは配布することはできません。


”Windows 10 サポート” 
に関する推奨事項

Windows 10 を特別なものとしている機能の一つに、Windows as a Service (サービスとしての Windows) があります。WSUS や SCCM の管理者にとっては、これは Windows の新しいビルドへの機能アップグレードを可能にすることを意味します。これらのアップグレードは、通常の更新プログラムと同じように処理されますが、WSUS / SCCM によって管理される端末へのインストールが承認されると、そのバイナリだけではなく、ビルド全体がアップグレードされます。 もし Windows Insider Program のメンバーであれば、この機能をしばらくの間利用していることになります。(但し、WSUS 経由ではありません。) この機能を使用すれば、Windows のビルドをアップグレードするために、従来のワイプしてインストール イメージをロードする操作はもはや必要ありません。新しい Windows 10  のビルドはこれまでの慣用的な1 ~3 年のリリース サイクルよりもさらに早いサイクルでリリースされるので、この機能は特に役立ちます。この機能アップグレードをサポートするためには、WSUS に更新プログラム (KB 3095113) をインストールする必要があります。機能アップグレードでは、更新プログラムの新しいコンテンツ ファイルの形式と Upgrades という新しい分類が採用されています。これは WSUS 管理者の方はおわかりになるかと思いますが、企業ユーザーではない方々にもわかりやすいように詳細を説明しています。


修正プログラムの品質について

KB 3095113 のリリースに記載されている “この修正プログラムは、ここで説明する問題が発生しているコンピューターに対してのみ適用してください。” といった定型文の記載を見て、適用に慎重になる方もいらっしゃると思います。修正プログラム (Hotfix) は最も早く修正を提供可能にするプログラムのリリース方法ですが、今後WSUS から Windows 10 1511 への機能アップグレードを展開するために、私たちはできる限りの猶予期間を提供したいと考えました。更新プログラム (KB 3095113) についても他の Windows Update のリリースと同様にテストしておりますので、Windows Server 2012 / 2012 R2 の WSUS 環境へのインストールに慎重になる必要はありません。ご参考までに、私たちは、2016 年第一四半期に、WSUS へと同様にダウンロード コンテンツ (DLC) とカタログの形式で、広範囲に本更新プログラムをリリースすることを予定しています。 もしこのリリースをお待ちいただく場合は、次に記載する注意事項をご参照ください。 


重要な注意事項

WSUS から Windows 10 1511 に関連するパッケージをダウンロード、展開できない場合でも、Windows 10 1511の機能アップグレードを確認できるかもしれません。機能アップグレードは、WSUS の製品と分類のオプションにて ”Upgrades” の分類をチェックすると確認できます。 しかし、最新の更新プログラムがインストールされていない状態で、アップグレードの同期を試みると、SUSDB には利用できないデータが取り込まれてしまい、アップグレードを正常に配布できるようにする前に利用できないデータを消去しなければなりません。この状況は回復可能ですが、そのプロセスは容易ではなく、アップグレードの同期を行う前に更新プログラム (KB 3095113) をインストールすることで回避できます。


この注意事項が意味すること

もしWindows 10 を現在のビルドに留めるために、ワイプしてインストール イメージを ロードするアップグレード方法で十分である場合は、WSUS にて ”Upgrades” の同期を行わない様にして、これまで通り、Windows のビルドのアップグレードを行うようにします。しかしながら、Windows as a Service に完全対応した形で企業内へのWindows 10 の展開を予定している場合には、最新の更新プログラムをインストールすることをお勧めします。 アップグレードの同期を行う前に、Windows 10 マシンを管理するすべての Windows Server 2012 /2012 R2 の WSUS 環境に対して、更新プログラムをインストールしておくことが最も安全です。


1511
へのアップグレード エクスペリエンス

今後 1-2 週間のうちにUpgrades の分類が表示されるようになり、WSUS からの Windows 10 1511 機能アップグレードが Windows 7, Windows 8.1, Windows 10 RTM に向けて利用可能となる予定です。 Windows 10 RTM からのアップグレードを行う場合、そのアップグレード プロセスは高度に自動化されています。例えば、アプリケーション プロビジョニングのステージやユーザー操作を必要とするすべてのセットアップ ステップはスキップされて、既定でファイルの関連付けやその他の設定が保持されます。WSUS からの Windows 7 または Windows 8.1 からのアップグレードでは、ビルドではなくプラットフォーム全体の変更となるため、何らかのユーザー操作が必要となります。



 


WSUS で不要な更新プログラムのインストーラーを削除する - 続報

$
0
0

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

前回の記事にて、WSUS で不要な更新プログラムのインストーラーを削除する方法をご紹介しました。WsusContent フォルダーの領域が逼迫した際には、WSUS の「サーバー クリーンアップ ウィザード」にある「不要な更新ファイル」を実行することで、ディスク領域を確保できます。ただ、「そもそも、クリーンアップ ウィザードを実行するために必要な最低限のディスクの空き領域もないため、クリーンアップが実行できない!」というトラブルが発生した場合には、クリーンアップ ウィザード実行前に、必要な領域を確保する必要があります。

今回は、ディスク領域を確保して「サーバー クリーンアップ ウィザード」の「不要な更新ファイル」を行う方法をご紹介します。

・WSUS コンテンツ フォルダーが格納されているドライブ逼迫の対処方法

重要 1 : 以下の手順を実施する前に、WSUS データベース (SUSDB) を必ずバックアップしてください。

重要 2 : 手順 1 で実施したファイルの整合性をチェックするため、手順 4 は必ず実行してください。

重要 3 : WsusContent フォルダー内のサブ フォルダは削除せず、必ず残してください。

1. WsusContent フォルダー内にある、サブフォルダーの .exe ファイルや .cabファイルの削除を行う。

2. WsusContent フォルダーを格納するドライブに数百 MB ~ 1 GB 近くの空き領域が確保されたことを確認する。

3. WSUS サーバークリーンアップウィザード にて [不要な更新ファイル] のみにチェックを入れ、クリーンアップを実施する。

4. wsusutil reset コマンドを実行する。

   4-1. コマンドプロンプトを管理者権限で起動し、下記コマンドを実行してフォルダを移動する
   cd /d "C:\Program Files\Update Services\Tools"

   4-2.下記コマンドを実行する
   wsusutil reset


~ 参考情報 ~

コマンド ラインからの WSUS の管理
https://technet.microsoft.com/ja-jp/library/cc720466(v=ws.10).aspx

WSUS サーバーからの Windows 10 へのアップグレードの配信

$
0
0

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

 

今回は WSUS サーバーからの Windows 10 へのアップグレードの配信についてご紹介します。以前の記事でも紹介した通り、WSUS からも Windows 7、Windows 8.1 の環境に対して Windows 10 にアップグレードする更新プログラムを配信することが出来ます。

ただし、WSUS 管理者が WSUS 管理コンソールで配信準備をしない限り、Windows 10 へのアップグレードが自動的に配信されることはありませんので、ご安心ください。WSUS サーバーから Windows 10 へのアップグレードを配信するためには、今回ご紹介する条件を満たすよう事前に WSUS サーバーの準備をしていただく必要があります。Windows 7 や Windows 8.1 の環境を、そのまま利用したい場合には、特に WSUS サーバーに追加の設定は必要ありません。

 

また、WSUS サーバーから Windows 10 へのアップグレードが自動的に配信されないことについては、下記の公開情報でもご紹介しております。

 

How to manage Windows 10 notification and upgrade options

https://support.microsoft.com/en-us/kb/3080351

 

---------- 一部抜粋 ----------

The Windows 10 upgrade is automatically blocked (that is, no further action is required) on computers or other devices in the following scenarios:

 •The computer or device is serviced through WSUS and has not had update 3035583 applied.

----------------------------------

 

なお、Windows Update を利用している環境にて、Windows 10 へのアップグレードの配信を抑止する方法については下記のブログをご参照ください。WSUS を利用している環境でも下記の方法を実施いただくと、ユーザーが誤って Windows Update に接続してしまった場合に Windows 10 へアップグレードされることを抑止可能であるため、より確実にアップグレードを阻止することが出来ます。

 

[企業ユーザー向け] Windows Update からの Windows 10 への無償アップグレードを管理する方法

http://blogs.technet.com/b/askcorejp/archive/2015/07/23/windows-update-windows-10-1.aspx

 

WSUS サーバーから Windows 10 へのアップグレードを配信するために必要な条件

WSUS サーバーから Windows 10 へのアップグレードを配信するためには、下記の 5 つの条件をすべてを満たしている必要があります。

 

1. Windows Server 2012 以降の WSUS サーバーを利用していること

 

2. 下記の KB3095113が WSUS サーバーに適用済みであること

 

- 10 の Windows の機能をアップグレードの WSUS のサポートを有効にする更新プログラム

https://support.microsoft.com/ja-jp/kb/3095113

 

3. WSUS のオプション「製品と分類」にて、製品として「Windows 10」、

   分類として「Upgrades」が同期対象として選択されていること

※ 「Upgrades」の分類を選択する前に、必ず KB3095113を WSUS サーバーに適用してください。

 

 

 

4.  WSUS が動作する IIS の Web サイト配下の「Content」にて

   Windows 10 へのアップグレードに用いられる「.esd」形式のファイルの配信を許可する設定を追加していること

 

 

5. 「Upgrades」に分類されている Windows 10 へのアップグレード用の更新プログラムが

   WSUS でインストール承認されていること

 

 

WSUS サーバーのバージョン番号について

$
0
0

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

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

WSUS 3.0 SP2

バージョン適用した更新プログラム
3.2.7600.226未適用
3.2.7600.251KB2720211
3.2.7600.256KB2734608
3.2.7600.262KB2828185
3.2.7600.274KB2938066

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


Windows Server 2012 WSUS

バージョン適用した更新プログラム
6.2.9200.16384未適用
6.2.9200.16384KB2938066
6.2.9200.21629KB3095113


Windows Server 2012 R2 WSUS

バージョン適用した更新プログラム
6.3.9600.16384未適用
6.3.9600.16384KB2938066
6.3.9600.18057KB3095113

※ 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 管理コンソールにつながらない!」を解消するための 6 つのワザ

$
0
0

みなさま、こんにちは!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 で不要な更新プログラムのインストーラーを削除する

$
0
0

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

WSUS サーバーを長期間運用している、または自動承認規則で製品などにフィルターをかけずに運用していると、知らない間に更新プログラムのインストーラー (コンテンツ ファイル) が多くダウンロードされており、「ディスク サイズの空き容量がない!」といったトラブルが発生することがあります。WSUS は自動でメンテナンスを行う機能を持っておりませんので、ディスク サイズの空き容量が少なくなった場合は、「サーバー クリーンアップ ウィザード」を実行して、不要なファイルを削除する必要があります。

でも、「サーバー クリーンアップ ウィザードを実行しても、あまり不要なファイルが削除されない!空き容量が増えない!」という結果になったことはありませんしょうか。

そこで今回は、WSUS で不要な更新プログラムのインストーラーを確実に削除するためのポイントについてご紹介いたします。

・「サーバー クリーンアップ ウィザード」で WSUS で不要な更新プログラムのインストーラーを削除する
・「サーバー クリーンアップ ウィザード」実行後も 更新プログラムのインストーラーが削除できない場合

「サーバー クリーンアップ ウィザード」で WSUS で不要な更新プログラムのインストーラーを削除する
サーバー クリーンアップ ウィザード項目で「不要な更新ファイル」を実行することで、不要な更新ファイルを削除することができますが、削除対象となる更新プログラムは「拒否済み」のステータスとなっている必要があります。
そのため、以下の流れで不要な更新プログラムのインストーラーを削除します。

(作業の流れ)
STEP1 : 更新プログラムを「拒否済み」とする

STEP2 : サーバー クリーンアップ ウィザードで「不要な更新ファイル」を実行する

「サーバー クリーンアップ ウィザード」実行後も更新プログラムのインストーラーが削除できない場合
上記流れで「サーバー クリーンアップ ウィザード」を実行した場合でも、更新プログラムのインストーラーが削除できないことがあります。代表的な要因は以下の通りです。

<要因 1 : WSUS オプション設定が既定から変更されている>
WSUS オプションの「更新ファイルと更新言語」にて、「更新プログラムが承認されている場合にのみ、更新ファイルをこのサーバーにダウンロードします」のチェックが既定では「オン」です。この設定が、「オフ」の構成の場合には、このままクリーンアップを実行しても「拒否済み」の更新プログラムのインストーラーを削除することは出来ません。このような構成の場合には、既定の「オン」に変更し、クリーンアップウィザード実施後に、再度、「オフ」に戻します。
  

<要因 2 : 「拒否済み」とした更新プログラムのインストーラーが他の更新プログラムで利用されており、かつ、インストール承認を行っている>
例として、以下の更新プログラムは、同一のインストーラーを利用しています。このような更新プログラムは、一方を「拒否済み」としても、もう一方で「インストール承認」済みの場合には、更新プログラムのインストーラーを削除することが出来ません。
Windows 7 for x64-based Systems 用の更新プログラム (KB974431)
Windows Server 2008 R2 x64 Edition 用の更新プログラム (KB974431)

見分け方としては、WSUS 管理コンソールで、「拒否済み」としても、ファイルの状態列はインストール承認ステータスのままとなります。
  

<要因 3 : 子 WSUS が「自律」の構成である もしくは 過去に「自律」の 子 WSUS が存在していた>
親子 WSUS 構成で、子 WSUS が「自律」の場合、子 WSUS 側で親 WSUS とは異なる承認情報を保持できます。たとえば、親 WSUS 側では未承認の更新プログラムも、子 WSUS が必要とすれば、親 WSUS は Microsoft Update カタログから更新プログラムのダウンロードを行います。このような処理に伴い、「子 WSUS の要求によりダウンロードした」ものであることを示すフラグを、データベース内のファイル情報に対して設定します。

このフラグが設定されたファイルは、親 WSUS 側でサーバー クリーン アップウィザードを実行しても削除されないよう設計されています。過去に子 WSUS が存在し、現在はすでに登録解除を行っている場合にもこの状態は変化いたしません。このため、サーバー クリーンアップ ウィザードでこのフラグが設定された不要な更新プログラムのインストーラーを削除できるようにするためには、データベースに対して SQL を発行し、フラグを解除する作業が必要になります。

子 WSUS 側で必要とした更新プログラムの有無の確認方法 と 設定されたフラグを解除する方法 (※) をご紹介します。
(※ 重要) データーベース内の情報を変更する操作となりますので、事前に必ず WSUS データーベースのバックアップをご実施ください。
WSUS 3.0 SP2 をデータベースごと移行する方法について
http://blogs.technet.com/b/jpwsus/archive/2012/09/20/wsus-sql-migration.aspx

<< 子 WSUS 側で必要とした更新プログラムの有無の確認 と 設定されたフラグを解除する方法>>
親 WSUS 側で子 WSUS によって必要とされている更新プログラムの有無は、WSUS 管理コンソールから目視で確認をすることができません。以下の手順にて、フラグが設定されている更新プログラムが存在するか確認します。

補足:
手順は、WSUS のデータベースが、SQL Server であるか Windows Internal Database (WID) で
あるかで異なります。どちらのデータベースを現在利用しているかにつきましては、WSUS サーバーの
以下のレジストリから判断できます。
%computername%\MICROSOFT##SSEE となっていれば、WID です。それ以外は SQL Server です。

******
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup]
- SqlServerName (REG_EXPAND_SZ)
******

SQL Server 環境の手順
1. SQL Server Management Studio を起動し、WSUS のデータベースを実行しているデータベース エンジンに接続します。
2. Microsoft SQL Server Management Studio 画面が起動したら、画面左ペインの[データベース] ツリーを展開します。
3. [SUSDB] を右クリックし [新しいクエリ] をクリックします。
4. 右ペインに表示された新しいクエリ画面に、以下のとおり入力し、ツールバーの [実行] をクリックするかもしくは F5 キーを押して、実行を開始します。
SELECT COUNT(DSSRequestedDownload) FROM dbo.tbFileOnServer WHERE DSSRequestedDownload = 1

※この結果、2 行目に表示される数値が 0 以外であれば、フラグの設定を持つ更新プログラムのが存在しています。
その場合は引き続き下記の手順をご実施します。

<手順>
5. 引き続き下記 2 件のコマンドを順に実行します。
update tbfileOnServer set actualstate=1 where (actualstate=8 or actualstate=9 or actualstate=10) and DSSRequestedDownload = 1
update tbFileOnServer set DSSRequestedDownload = 0 WHERE DSSRequestedDownload = 1

6. 正しく変更されたかの確認のために、下記コマンドを実行します。
SELECT COUNT(DSSRequestedDownload) FROM dbo.tbFileOnServer WHERE DSSRequestedDownload = 1

結果が 0 なら正しく変更されています。

WID 環境の手順
1. 管理者権限でコマンドプロンプトを起動します。
2. 下記コマンドにてフォルダを移動します。
cd /d %ProgramFiles%\Update Services\setup

3. 引き続き下記コマンドを実行します。executesql.exe は実行結果をプロンプト画面に表示しませんので、出力先ファイル名を指定し、その内容を確認する手順となります。「一行として」投入してください。

executesql.exe -S %computername%\MICROSOFT##SSEE -d "SUSDB" -Q "SELECT COUNT(DSSRequestedDownload) FROM dbo.tbFileOnServer WHERE DSSRequestedDownload = 1"  -l result1.txt

4. 以下のコマンドを実行して出力ファイル内容を確認します。
TYPE result1.txt

結果出力例)
<no name>
10591

※この結果、2 行目に表示される数値が 0 以外であれば、フラグの設定を持つ更新プログラムのが存在しています。
その場合は引き続き下記の手順をご実施します。

<手順>
5. 引き続き下記2件のコマンドを順に実行します。
executesql.exe -S %computername%\MICROSOFT##SSEE -d "SUSDB" -Q "update tbfileOnServer set actualstate=1 where (actualstate=8 or actualstate=9 or actualstate=10) and DSSRequestedDownload = 1"

executesql.exe -S %computername%\MICROSOFT##SSEE -d "SUSDB" -Q "update tbFileOnServer set DSSRequestedDownload = 0 WHERE DSSRequestedDownload = 1"

6. 正しく変更されたかの確認のため、下記コマンドを実行します。
末尾のファイル名 result2.txt は任意の名前で結構です。
executesql.exe -S %computername%\MICROSOFT##SSEE -d "SUSDB" -Q "SELECT COUNT(DSSRequestedDownload) FROM dbo.tbFileOnServer WHERE DSSRequestedDownload = 1" -l result2.txt

7. 以下のコマンドを実行してファイル内容を確認します。
2 行目に表示される数値が 0 なら正しく変更されています。

TYPE result2.txt

結果出力例)
<no name>
0

Windows 10 の Windows Update の自動更新設定

$
0
0

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

7 月 29 日に、ついに Windows 10 がリリースされましたが、みなさまもうアップグレードはされましたでしょうか?!

このブログ記事では、読者のみなさまが気になっているであろう Windows 10 における Windows Update の自動更新設定についてご紹介します。Windows 10 の環境では、Windows Update の自動更新の設定方法が大きく変わりました。下記の順にご案内していきます。

 

・ Windows Update 関連の設定箇所について

・ 自動更新の設定について

Windows Update 関連の設定箇所について

Windows 10 からは、コントロール パネルの Windows Update の項目がなくなり、自動更新を含む Windows Update 関連の設定は、すべて 「設定」から行うようになりました。

下記の手順にて Windows Update 関連の設定画面を開けます。

 

[スタート] – [設定] を選択します。

 

[更新とセキュリティ] をクリックします。

 

Windows 10 の Windows Update 画面が表示されます。

 

自動更新の設定について

自動更新の設定は、上記画面内にある、[詳細オプション] をクリックすると下記の 2 種類から選択することができます。

- 自動 (推奨)

- 再起動の日時を設定するように通知する

 

*補足*

- 自動 (推奨)

更新プログラムのインストール、再起動まで自動で行えます。

 

- 再起動の日時を設定するように通知する

更新プログラムのインストール完了後、再起動のタイミングを選択することが  可能です。

 

また、Windows 10 以前の OS では、[コントロールパネル] – [システムとセキュリティ] – [Windows Update] から、以下の設定を行うことができました。

 

a) 更新プログラムを自動的にインストールする (推奨)

b) 更新プログラムをダウンロードするが、インストールを行うかどうかは選択する

c) 更新プログラムを確認するが、ダウンロードとインストールを行うかどうかは選択する

d) 更新プログラムを確認しない (推奨されません)

 

Windows 10 では、このうち b) ~ d) の設定を [Windows Update] から行うことができなくなり、既定では a) と同等の動作です。

但し、Windows Update のグループ ポリシーについては、Windows 10 以前の OS のように、構成することができます。例えば、「d) 更新プログラムを確認しない (推奨されません)」に構成する場合、ローカル PC 上で設定可能なローカル グループ ポリシーを使用して設定する手順は、以下の通りです。(ローカル グループ ポリシーは、Windows 10 Pro, Enterprise エディションで使用可能です。)

1. スタート ボタンを右クリックして [コマンド プロンプト (管理者)] をクリックします。
2. コマンド プロンプトが開くので、gpedit.msc を実行します。
3. ローカル グループ ポリシー エディターが開きます。左ペインより以下の場所に移動します。
[コンピューターの構成] – [管理用テンプレート] – [Windows コンポーネント] – [Windows Update]
4. 右ペインより [自動更新を構成する] をダブル クリックします。
5. ダイアログが開くので、[無効] を選択して [OK] をクリックします。
6. ローカル グループ ポリシー エディターを閉じます。
7. コマンド プロンプト上で gpupdate /force を実行します。このコマンドでポリシーを強制的に反映させます。

[自動更新を構成する] ポリシーで構成した際の [Windows Update] – [詳細オプション] の画面は、以下のようになります。(スクリーンショット内の、[一部の設定は組織によって管理されています。] と記載されている環境は、グループ ポリシーによって自動更新の設定が行われていることを示します。) 上記手順実施直後は、画面には設定内容が反映されませんが、内部的には設定内容が有効になっています。画面上の表示は次回更新プログラムのチェックが試みられるタイミングで反映されますので、時間が経過すれば反映されるようになります。([更新プログラムのチェック] をクリックすれば直ちに反映しますが、一度更新プログラムをチェックすることになりますのでご注意ください。)

[自動更新を構成する] ポリシーが「無効」の場合

 

[自動更新を構成する] ポリシーにて、「2 – ダウンロードとインストールを通知」が有効となっている場合

 

なお、新しい更新プログラムが検出されると、以下のようにタスクバー上で通知が行われます。

通知アイコンをクリックすると、以下の詳細を確認できます。

通知メッセージをクリックすると、以下のように更新プログラムのダウンロード、およびインストールが可能です。


 

 

 

[自動更新を構成する] ポリシーにて、「3 – 自動ダウンロードしインストールを通知」が有効となっている場合

 

こちらも、新しい更新プログラムが検出されるとタスクバー上で通知が行われます。

通知アイコンをクリックすると、以下の詳細を確認できます。

通知メッセージをクリックすると、以下のように更新プログラムのインストールが可能です。

 

 

 

[自動更新を構成する] ポリシーにて、「4 – 自動ダウンロードしインストール日時を指定」が有効となっており、かつ [自動メンテナンス時にインストールする] のチェックが オフ の場合

 

[自動更新を構成する] ポリシーにて、「4 – 自動ダウンロードしインストール日時を指定」が有効となっており、かつ [自動メンテナンス時にインストールする] のチェックが オン の場合

および

[自動更新を構成する] ポリシーにて、「5 – ローカルの管理者の設定選択を許可」が有効となっている場合

Windows 10 環境向けの WSUS / Windows Update に関する情報は、これからも順次公開していきますので、乞うご期待ください!

 

 

 

Office 2010 32 bit を使用している環境に、Office 2010 64 bit の更新プログラムが検出される

$
0
0

(2015 年 11 月 2 日 更新 – 修正完了し、解消いたしました。)

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

2015 年 10 月 28 日以降、Office 2010 の 32 ビット版を使用している環境において、64 ビット版 Office 2010 用の更新プログラムが検出されるとの報告がございます。この事象について詳細をお伝えいたします。
本事象は WSUS に接続するクライアントだけではなく、Microsoft Update や Microsoft Intune に接続する環境でも発生します。状況に進展があり次第、こちらの記事に情報を公開させていただきますので、今しばらくお待ちくださいますようお願いいたします。
本事象につきましては、2015 年 10 月 31 日 に Microsoft Update サイト側の修正が完了し、現時点では解消しております。解消前に適用されていた、64 ビット版の KB2687413 および KB2837582 につきましては、アンインストールせずにそのままご使用いただいても動作に問題はございません。解消前にご案内しておりました、事象について以下にご紹介させていただきます。

- 現象
2015 年 10 月 28 日以降、Office 2010 の 32 ビット版を使用している環境において、Microsoft Update による更新プログラムの検出を実行した際、以前は検出されなかった以下の 64 ビット版 Office 2010 用の更新プログラムが適用対象として検出される現象が確認されています。

KB2687413
MS13-075: Description of the security update for Microsoft Office IME (Chinese): September 10, 2013
https://support.microsoft.com/en-us/kb/2687413

KB2837582
October 14, 2014 update for Office 2010 (KB2837582)
https://support.microsoft.com/en-us/kb/2837582

KB2687455
Description of Office 2010 Service Pack 2
https://support.microsoft.com/en-us/kb/2687455

上記の更新プログラムのうち KB2687413 および KB2837582 については、64 ビット版の更新プログラムの適用を実行した場合、正常に適用が完了しますが、KB2687455 の 64 ビット版 Office 2010 SP2 の適用は失敗します。

注意:
1. KB2687413 は検出操作以前に適用されていた更新プログラムの種類に依存して、検出されない環境もあります。
2. 上述の他に、以下の 64 ビット版の更新プログラムも検出されますが、これは、10 月 28 日以前からの動作です。

KB2553347
July 14, 2015, update for Office 2010 (KB2553347)
https://support.microsoft.com/en-us/kb/2553347

3. WSUS を使用した更新プログラムの展開を行っている環境でも同事象が発生します。

- 状況
現在、Microsoft Update サイトの検出処理等、原因の調査を弊社開発部門と協業の上進めております。
本事象につきましては、Microsoft Update サイトに問題があったため、修正いたしました。

- 対処方法
Office 2010 の 32 ビット版を使用している場合、検出された 64 ビット版の更新プログラムは、適用の必要はございませんので、適用対象から除外くださいますようお願いいたします。
なお、すでに 64 ビット版の KB2687413 および KB2837582 が適用された環境につきましては、更新対象となる Office IME 2010 の動作には影響ございませんので、アンインストールせずそのままご使用いただいても動作に問題はございません。


動的メモリを有効にしている Hyper-V 仮想マシンで WSUS の同期が全く進まない / 完了しない現象

$
0
0

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

仮想環境上で WSUS サーバーをご運用されている方も、たくさんいらっしゃるかと思います。本記事では、動的メモリを有効にしている Hyper-V 仮想マシン上の WSUS サーバーで確認されている同期が全く進まない / 完了しない現象についてご紹介します。

まず仮想環境上で WSUS サーバーを動作させる構成は、非常に多くの実績がある構成ですので、ご安心ください。弊サポート チームにて受け付けるお問い合わせでも、いまやほとんどの WSUS サーバーが仮想環境上で動作しています。

しかし、残念ながら TechNet 上の技術情報では Hyper-V 等の仮想環境上で WSUS を動作させる際の注意点について記載はございません。これは、開発の段階にて動的メモリ等の仮想環境の固有の機能を意識した検証が充分に行われていないためです。仮想環境の固有の機能を利用している場合でも、ほとんどの場合には問題なく WSUS サーバーは動作しますが、該当の機能が問題となることもあります。

今回は仮想環境固有の問題として、動的メモリを有効にしている Hyper-V 仮想マシン上の WSUS サーバーで稀に発生する現象をご案内します。

 

動的メモリを有効にしている Hyper-V 仮想マシンで WSUS の同期が全く進まない / 完了しない現象 )

動的メモリの影響で、稀に WSUS の処理に上手くメモリが割り当てられず、同期処理が全く進まないという現象が確認されています。 動的メモリをご利用いただいている環境で、下記の同期画面から処理が全く進まない場合には、本現象に該当している可能性が非常に高いと考えられます。

 


 

この場合、下記のいずれかの対処をしていただくことで、現象を改善していただくことが可能です。

- 動的メモリではなく固定メモリに設定を変更していただく

- 動的メモリの設定にて、最小メモリをより大きな値に変更いただく

 

( 上記の現象に合致しているか、より詳細に判別する方法 )

下記の 2 点をご確認いただくと、上記の現象に合致しているか、より詳細に下記の 2 点をご確認いただくと、上記の現象に合致しているか、より詳細に判別することが可能です。

- WSUS が動作している Hyper-V 仮想マシンで、動的メモリが有効に設定されていること

- WSUS サーバー内のログ「%ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log」に

  下記のような記録が出力され続けていること

 

・ 出力例 1

———————————

SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないかアクセスできません。インスタンス名が正しいこと、および SQL Server がリモート接続を許可するように構成されていることを確認してください。 (provider: 名前付きパイプ プロバイダ, error: 40 – SQL Server への接続を開けませんでした)

———————————

・ 出力例 2

———————————

Timeout に達しました。操作が完了する前にタイムアウト期間が過ぎたか、またはサーバーが応答していません。

———————————

 

2015 年12 月に公開されたセキュリティ情報 MS15-135 について

$
0
0

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

本記事では  2015 年12 月に公開されたセキュリティ情報  MS15-135 についてご案内いたします。

 

弊社公開のセキュリティ情報を元に更新プログラムの展開を検討されているお客様から

2015 年12 月に公開された MS15-135について、次のようなご質問をいただきます。

・WSUS や MBSA を使っても検出されない。

・更新プログラムが適用されない。

・更新プログラムが見つからない。

・どうやったら適用できるのか?

 

結論から申しますと、MS15-135 に対応した更新プログラムはリリースしていない (MS15-128 にその内容を含んでいる) ことがその理由となります。

 

脆弱性の報告としてのMS15-135を公開させていただきましたが、当該脆弱性への対応として紐づく更新プログラムは存在せず、MS15-128で提供させていただく更新プログラム (KB3109094) にて脆弱性に対応することができます。

したがいまして、MS15-135 の更新プログラムは WSUS や MBSA を使っても検出されません。

こちらは想定する動作でありMS15-135が検出されないこと自体に問題はなく、MS15-128 (KB3109094) が検出、適用されていることをご確認いただければ問題ございませんので、どうぞご安心ください。

 

ご参考情報

以下は KB3109094 の公開ページとなります。

[MS15-128 と MS15-135] Windows カーネル モード ドライバーのセキュリティ更新プログラムについて (2015 年 12 月 8 日)

< https://support.microsoft.com/ja-jp/kb/3109094>

Windows Server 2012 / 2012 R2 の WSUS の重要な更新 (KB 3095113) について

$
0
0

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

先日 Windows Server 2012 / 2012 R2 の WSUS に適用可能な更新プログラム KB 3095113 がリリースされましたが、この更新プログラムは Windows 10 対応に関する修正が含まれております。

ただ、「Windows 10 に更新プログラムを配信するためには、この更新プログラムを適用しなければいけないのか?」「KB 3095113 はどういった修正が含まれるのか」といった疑問をお持ちの方も多いのではないでしょうか。

この疑問にお答えする記事が、弊社米国の開発部署が管理しているブログにて公開されましたので、日本の WSUS サポート チームでも、お客様のリクエストにお答えして、その記事を翻訳させていただきました。これから Windows 10 の更新プログラム管理をご検討されている管理者の皆様は、是非ともご一読ください。


このポストは、12 月 4 日に投稿された Important update for WSUS 4.0 (KB 3095113) の翻訳です。


著者
: Steve Henry   

既にご存知の方もおられるかもしれませんが、私たちは 今後数週間のうちに Windows 10 の最初のインプレース アップグレードである Windows 10 1511 への機能アップグレードを WSUS に向けてリリースする予定です。この展開シナリオに完全対応するために、Windows Server 2012 および Windows Server 2012 R2 の WSUS 用の更新プログラム (KB 3095113) を公開しました。この更新プログラムのリリース後、更新プログラムの適用に関して以下のような質問が寄せられています。:

・この更新プログラム (KB 3095113) は Windows 10 をサポートするために必要ですか?

・この更新プログラム (KB 3095113) をインストールしない場合、何が起こるのですか?

・修正プログラム (Hotfix) ではないダウンロード コンテンツ (DLC) 形式でのリリースまで待つべきですか?

・本リリースに関する既知の問題はありますか?

”Windows 10 サポート” に関する解説

WSUS で同期やインポートを行って、Windows 10 用の更新プログラムを配布するにあたり、更新プログラム (KB 3095113) を WSUS に適用する必要があるのか、気になる方もいるのではないでしょうか。 もしそれが気になる場合は、Windows 10 の更新プログラムを配布するために WSUS への適用が必要な更新プログラムはありませんのでご安心ください。Windows 10 自体はこれまでの歴史においても非常に大きなリリースとなりますが、WSUS の観点では、これまでリリースした製品の一部というだけに過ぎず、Windows 10 の更新プログラム (セキュリティ更新プログラムを含む) を配布するにあたって、WSUS 側での変更は必要ありません。そのため、WSUS 3.0 SP2 (SBS 2011 を含む) および更新プログラムを適用していない Windows Server 2012 / 2012 R2 の WSUS で、Windows 10 の更新プログラムを配布することができます。但し、機能アップグレードは配布することはできません。


”Windows 10 サポート” 
に関する推奨事項

Windows 10 を特別なものとしている機能の一つに、Windows as a Service (サービスとしての Windows) があります。WSUS や SCCM の管理者にとっては、これは Windows の新しいビルドへの機能アップグレードを可能にすることを意味します。これらのアップグレードは、通常の更新プログラムと同じように処理されますが、WSUS / SCCM によって管理される端末へのインストールが承認されると、そのバイナリだけではなく、ビルド全体がアップグレードされます。 もし Windows Insider Program のメンバーであれば、この機能をしばらくの間利用していることになります。(但し、WSUS 経由ではありません。) この機能を使用すれば、Windows のビルドをアップグレードするために、従来のワイプしてインストール イメージをロードする操作はもはや必要ありません。新しい Windows 10  のビルドはこれまでの慣用的な1 ~3 年のリリース サイクルよりもさらに早いサイクルでリリースされるので、この機能は特に役立ちます。この機能アップグレードをサポートするためには、WSUS に更新プログラム (KB 3095113) をインストールする必要があります。機能アップグレードでは、更新プログラムの新しいコンテンツ ファイルの形式と Upgrades という新しい分類が採用されています。これは WSUS 管理者の方はおわかりになるかと思いますが、企業ユーザーではない方々にもわかりやすいように詳細を説明しています。


修正プログラムの品質について

KB 3095113 のリリースに記載されている “この修正プログラムは、ここで説明する問題が発生しているコンピューターに対してのみ適用してください。” といった定型文の記載を見て、適用に慎重になる方もいらっしゃると思います。修正プログラム (Hotfix) は最も早く修正を提供可能にするプログラムのリリース方法ですが、今後WSUS から Windows 10 1511 への機能アップグレードを展開するために、私たちはできる限りの猶予期間を提供したいと考えました。更新プログラム (KB 3095113) についても他の Windows Update のリリースと同様にテストしておりますので、Windows Server 2012 / 2012 R2 の WSUS 環境へのインストールに慎重になる必要はありません。ご参考までに、私たちは、2016 年第一四半期に、WSUS へと同様にダウンロード コンテンツ (DLC) とカタログの形式で、広範囲に本更新プログラムをリリースすることを予定しています。 もしこのリリースをお待ちいただく場合は、次に記載する注意事項をご参照ください。 


重要な注意事項

WSUS から Windows 10 1511 に関連するパッケージをダウンロード、展開できない場合でも、Windows 10 1511の機能アップグレードを確認できるかもしれません。機能アップグレードは、WSUS の製品と分類のオプションにて ”Upgrades” の分類をチェックすると確認できます。 しかし、最新の更新プログラム がインストールされていない状態で、アップグレードの同期を試みると、SUSDB には利用できないデータが取り込まれてしまい、アップグレードを正常に配布できるようにする前に利用できないデータを消去しなければなりません。 この状況は回復可能ですが、そのプロセスは容易ではなく、アップグレードの同期を行う前に更新プログラム (KB 3095113) をインストールすることで回避できます。


この注意事項が意味すること

もしWindows 10 を現在のビルドに留めるために、ワイプしてインストール イメージを ロードするアップグレード方法で十分である場合は、WSUS にて ”Upgrades” の同期を行わない様にして、これまで通り、Windows のビルドのアップグレードを行うようにします。しかしながら、Windows as a Service に完全対応した形で企業内へのWindows 10 の展開を予定している場合には、最新の更新プログラムをインストールすることをお勧めします。 アップグレードの同期を行う前に、Windows 10 マシンを管理するすべての Windows Server 2012 /2012 R2 の WSUS 環境に対して、更新プログラムをインストールしておくことが最も安全です。


1511
へのアップグレード エクスペリエンス

今後 1-2 週間のうちにUpgrades の分類が表示されるようになり、WSUS からの Windows 10 1511 機能アップグレードが Windows 7, Windows 8.1, Windows 10 RTM に向けて利用可能となる予定です。 Windows 10 RTM からのアップグレードを行う場合、そのアップグレード プロセスは高度に自動化されています。例えば、アプリケーション プロビジョニングのステージやユーザー操作を必要とするすべてのセットアップ ステップはスキップされて、既定でファイルの関連付けやその他の設定が保持されます。WSUS からの Windows 7 または Windows 8.1 からのアップグレードでは、ビルドではなくプラットフォーム全体の変更となるため、何らかのユーザー操作が必要となります。



 

WSUS で不要な更新プログラムのインストーラーを削除する–続報

$
0
0

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

前回の記事 にて、WSUS で不要な更新プログラムのインストーラーを削除する方法をご紹介しました。WsusContent フォルダーの領域が逼迫した際には、WSUS の「サーバー クリーンアップ ウィザード」にある「不要な更新ファイル」を実行することで、ディスク領域を確保できます。ただ、「そもそも、クリーンアップ ウィザードを実行するために必要な最低限のディスクの空き領域もないため、クリーンアップが実行できない!」というトラブルが発生した場合には、クリーンアップ ウィザード実行前に、必要な領域を確保する必要があります。

今回は、ディスク領域を確保して「サーバー クリーンアップ ウィザード」の「不要な更新ファイル」を行う方法をご紹介します。

・WSUS コンテンツ フォルダーが格納されているドライブ逼迫の対処方法

重要 1 : 以下の手順を実施する前に、WSUS データベース (SUSDB) を必ずバックアップしてください。

重要 2 : 手順 1 で実施したファイルの整合性をチェックするため、手順 4 は必ず実行してください。

重要 3 : WsusContent フォルダー内のサブ フォルダは削除せず、必ず残してください。

1. WsusContent フォルダー内にある、サブフォルダーの .exe ファイルや .cabファイルの削除を行う。

2. WsusContent フォルダーを格納するドライブに数百 MB ~ 1 GB 近くの空き領域が確保されたことを確認する。

3. WSUS サーバークリーンアップウィザード にて [不要な更新ファイル] のみにチェックを入れ、クリーンアップを実施する。

4. wsusutil reset コマンドを実行する。

   4-1. コマンドプロンプトを管理者権限で起動し、下記コマンドを実行してフォルダを移動する
   cd /d "C:\Program Files\Update Services\Tools"

   4-2.下記コマンドを実行する
   wsusutil reset

~ 参考情報 ~

コマンド ラインからの WSUS の管理
https://technet.microsoft.com/ja-jp/library/cc720466(v=ws.10).aspx

WSUS サーバーからの Windows 10 へのアップグレードの配信

$
0
0

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

 

今回は WSUS サーバーからの Windows 10 へのアップグレードの配信についてご紹介します。以前の記事でも紹介した通り、WSUS からも Windows 7、Windows 8.1 の環境に対して Windows 10 にアップグレードする更新プログラムを配信することが出来ます。

ただし、WSUS 管理者が WSUS 管理コンソールで配信準備をしない限り、Windows 10 へのアップグレードが自動的に配信されることはありませんので、ご安心ください。WSUS サーバーから Windows 10 へのアップグレードを配信するためには、今回ご紹介する条件を満たすよう事前に WSUS サーバーの準備をしていただく必要があります。Windows 7 や Windows 8.1 の環境を、そのまま利用したい場合には、特に WSUS サーバーに追加の設定は必要ありません。

 

また、WSUS サーバーから Windows 10 へのアップグレードが自動的に配信されないことについては、下記の公開情報でもご紹介しております。

 

How to manage Windows 10 notification and upgrade options

https://support.microsoft.com/en-us/kb/3080351

 

———- 一部抜粋 ———-

The Windows 10 upgrade is automatically blocked (that is, no further action is required) on computers or other devices in the following scenarios:

 •The computer or device is serviced through WSUS and has not had update 3035583 applied.

———————————-

 

なお、Windows Update を利用している環境にて、Windows 10 へのアップグレードの配信を抑止する方法については下記のブログをご参照ください。WSUS を利用している環境でも下記の方法を実施いただくと、ユーザーが誤って Windows Update に接続してしまった場合に Windows 10 へアップグレードされることを抑止可能であるため、より確実にアップグレードを阻止することが出来ます。

 

[企業ユーザー向け] Windows Update からの Windows 10 への無償アップグレードを管理する方法

http://blogs.technet.com/b/askcorejp/archive/2015/07/23/windows-update-windows-10-1.aspx

 

WSUS サーバーから Windows 10 へのアップグレードを配信するために必要な条件

WSUS サーバーから Windows 10 へのアップグレードを配信するためには、下記の 5 つの条件をすべてを満たしている必要があります。

 

1. Windows Server 2012 以降の WSUS サーバーを利用していること

 

2. 下記の KB3095113 が WSUS サーバーに適用済みであること

 

- 10 の Windows の機能をアップグレードの WSUS のサポートを有効にする更新プログラム

https://support.microsoft.com/ja-jp/kb/3095113

 

3. WSUS のオプション「製品と分類」にて、製品として「Windows 10」、

   分類として「Upgrades」が同期対象として選択されていること

※ 「Upgrades」の分類を選択する前に、必ず KB3095113 を WSUS サーバーに適用してください。

 

 

 

4.  WSUS が動作する IIS の Web サイト配下の「Content」にて

   Windows 10 へのアップグレードに用いられる「.esd」形式のファイルの配信を許可する設定を追加していること

 

 

5. 「Upgrades」に分類されている Windows 10 へのアップグレード用の更新プログラムが

   WSUS でインストール承認されていること

 

 

Viewing all 179 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>