isLandcenter 非番中

WSUS のディスク容量がピンチ！空き容量を一挙に増やすには

この記事は書き換える可能性があります。

2016/10 より、Windows Update のポリシーが変わったせいでしょうか、急に WSUS の容量が爆発的にふえてしまったのです。

WSUSを長年運用していると、

1) インストール済のパッチの拒否

2) クリーンアップウィザード

3) WSUS 自身のアップデート

4) 同期

5) 世間のパッチの不具合の話題をチェックしてインストールの承認

6) パッチのダウンロードと配信

という流れが出来てきます。これで毎月運用していれば WSUS の使用ディスク容量なんて２０Gから３０G程度で落ち着いてくれます。

ところが、ある日、クリーンアップウィザードを実施しても、全然キャッシュが消えないという不思議な現象に出くわしました。WSUS ピンチです。40G確保したD:ドライブを dd コマンドで４Gほど増やしてみて（当然仮想化運用です）も、キャッシュドライブは、大泉洋が作るスパゲッティみたいに膨れ上がる一方です。

ということで、WSUS の空き容量を緊急に確保する緊急手段です。

Windows Update Service > 「オプション」 > 「更新ファイルと更新言語」を開きます。

「更新ファイルをローカルに保存せず Microsoft Update からインストール」をチェックして「適用」します。
これで、キャッシュされたアップデートが削除が指示されるので、（その間「OK」ボタンがグレーアウトします。５分待ってください）その後、クリーンアップウィザードを使って、キャッシュのクリーンアップを行います。
空き容量が増えたら「更新ファイルをローカルに保存する」のチェックを入れてOKボタンを押します。次のパッチ配信から、ローカルネットワークにキャッシュされます。

ギリギリだった容量が一挙に回復しました。

Windows は 2016/10 より、パッチのリリース方法が変わりました。2016 年 10 月からのロールアップ リリースに伴う WSUS 運用の注意点
これで、WSUS のキャッシュが「ふえるワカメ」になるという記述はありませんが、 WSUS の運用方法に影響が出ることは予測していました。やっぱり、運用は変わりますね。
-ただ今４０Ｇｂダウンロード中-
どこまで増えるんだ？ 4G のＯＳパッチがその１０倍もあるなんて .....!　という事でこの話はまだ続きます。
やっと終わった４０Ｇｂ、Windows 7, 10/ 10amv Upadte の三つのパッチだけで、本体の３倍のパッチ。これえ４０Ｇｂってどういう事よ。
-ダウンロードの取り消しと拒否-
それでもダウンロードが止まらない。という事で、「ダウンロードの取り消し」をやってみました。「全ての更新プログラム」の中で「タイトル」の左にある白の「！」アイコンを押して、ソートして、配信しなければならないパッチのみ黄色の「！」マークをリストします。
配布が不要な無印の更新プログラムの残骸が「拒否、未インストール」でゴッソリ残っています。
この黄色の「！」マーク以外の拒否したリストをShift キーを押しながら選択(やっちゃった後の「キャプチャ」なんでね....)、右ボタンから「ダウンロードの取り消し」と「拒否」を行います。（下の図では！マークを選んでいますが...）その後、クリーンアップウィザードでディスクをクリーンアップすると、見事にダウンロードの嵐が止み、ディスク容量も回復することが出来ました。
Windows10 のKB3197356には気を付けろ。Edge のパッチだけで 700Mb あるぞ、という事らしいです。このパッチが配布された後は、小康状態です。良かったみたいです。

OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)
https://islandcnt.exblog.jp/238412872/

フォルダの容量制限付きアーカイブ専用ファイルサーバー：サーバーをゴミ箱にしない工夫
https://islandcnt.exblog.jp/238371771/

クライアントPCのBCP対策 D:ドライブにドキュメントを保管・バックアップ
https://islandcnt.exblog.jp/238911684/

isLandcenter.jp


-Keyword-
WSUS 3.0 ディスクが満杯　アップデートの削除　ディスクの節約　容量不足　空き容量　

Windows10の Windows Update はデフォルトで使ってはいけない。

Windows10 の Windows Update は P2P の仕組みを利用して配信するように、デフォルト設定されています。どの様な仕組みなのかは、明らかにされていませんが、アップデートプログラムが Microsoft からではなく、不特定のインターネットに接続されたＰＣから入手されるような仕掛けがデフォルトです。

設定＞更新とセキュリティ＞「詳細オプション」＞「更新プログラムの提供方法を選ぶ」という、山深い伊賀忍法のヒミツの隠し戸のようなトコロにこの設定があります。

「ローカルネットワーク上のPCとインターネット上のPC」がデフォルトなので、これを「ローカルネットワーク上のPC」のみにします。

複数の場所から更新するはONでも構いませんが、入手先はローカルネットワークのみにします。僻地でダイアルアップ回線を使っている（限界集落なら当然）なら、もちろんＯＦＦですね。

最初にアップデートを受け取るＰＣは Microsoft からの転送になりますが、一度受け取ったアップデートはローカルネットワーク内部でＰ２Ｐ配信されるようです。もっとも、社内に Windows Update Server (WSUS) を用意してあるのであれば、すべてそこから供給を受けるべきなのでＰ２Ｐ配信もＯＦＦにするのが良いでしょう。

どうせ一台目はMicrosoft から受けざるを得ません。しかし、他の全く面識のないWindows ユーザにアップデートを送信する義務は、利用者にとっては全く意味のないことですし、受け取るにもどのような危険性があるかわかりません。アップデートを配信するのは Microsoft の義務ですから、ユーザのリソースを勝手に使わないで、自社の配信設備をちゃんと金かけて構築してくれと言いたくなります。よくゲームのパッチ配信でＰ２Ｐ技術を使ってウィルスまがいのソフトウェアがご訪問してくることもよく聞きます。

また、自分のＬＡＮ内のＰＣから、アップデートが外に出ていくという事は、当たり前ですが、自社のネットワークのアウトゴーイングのトラフィックに 社内からDDoSの踏み台になって攻撃してんじゃないのってくらいの、アップロードの負荷をかけます。そのコストは利用者が負担しなければなりません。もちろん私たちはそんな義務はありません。当然従量課金制の無線ネットワークを利用しているユーザにとっては、パケット代もＩＳＰへの「お布施」になってしまいます。

という事で、Windows Update は、自社の社内ネットワークだけのＰ２Ｐコピーにとどめておくことをお勧めします。

"Do not use Windows Update on default condition"

関連記事

Windows7 からWindows10 にアップデートしたらまずするべき事。

補足記事

Windows 10 更新プログラムにおけるP2P配信の仕組み - 阿久津良和のWindows Weekly Report

http://news.mynavi.jp/articles/2016/10/17/windows10report/

その他の情報はこちら

islandcenter.jp

-key Word-

Windows10 Update Default 変更　SUSE Linux Novell NetIQ

Windows Update Service(WSUS) の日常の運用

Windows Update Service(WSUS 3.0) の日常の運用について説明します。

Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update Server の続きです。

通常の Windows Update は月に一度の公開ですが、WSUS で見ると、毎日新しいアップデートが提供されていることがわかります。マイクロソフトから公開されるタイミングと、こちらの業務のタイミングが合わないと、忙しい時期にアップデートを取り込んでとっ散らかることもあります。

WSUS ではアップデートのタイミングをこちらで設定できるので、こちらの「心の準備」ができてから配信することが出来ます。

※　まず、重要なことは、パッチがリリースされたら、その配信直後にある不具合をしっかりチェックする事です。パッチを適用したら、再起動できないとか、致命的で修復困難なトラブルがあるかないかを数日チェックして、それから、「承認」の手続きに入ることです。大抵” Windows Update, 月例, n月度, 不具合”なんてキーワードで見つかります。また、「承認」するまえに WSUS と Windows サーバーをしっかりアップデートしてから、慌てて配信しないのが良いでしょう。２～３日、情報を集めて、問題がない事を確認してから配信するのがポイントです。もちろん管理者が十分なバックグラウンドジョブを抱えていないタイミングを選ぶのはとても大切な事です。

最新の同期状態をチェックし、アップデートがある場合、アップデート配信を「承認」し、配信日時を決めることが出来ます。ここでは「今すぐ配信」を開始するようにしてみました。



次に、アップデートが配信されているかの確認です。



アップデートの配信が終わった後は、サーバーに残った「不要になったアップデート」をクリーンアップします。この作業をやらないと、ディスクがとんでもないことになってしまうのでこまめにクリーンアップウィザードを使って、アップデートファイルからディスク容量を解放します。

承認済みのアップデートから「全て」を選ぶとアップデートファイル全体の何％が配信済みかがわかります。１００％配信が終わったアップデートは「拒否」して、クリーンアップウィザードを開始して、不要なファイルを削除します。


結構時間がかかる作業なので負荷の少ない時間帯を選んで実施するとよいでしょう。

-補足-
ちなみに WSUS と本家との「同期」というのはデータベースの同期であり、アップデートを受け取りキャッシュしておくものではないようです。zabbix でチェックしてみるとデータベースと「同期」した後は、時間をかけて本家からアップデートをダウンロードしていました。量にもよりますが、数十分から数時間ダウンロードを続けます。つまり「同期」は「見積もり」から「発注」までを意味して「納品」されるのはその後という事です。

この間は、Windows Update を実行しても登録したPCにアップデートは配信されません。 WSUS が完全にアップデートをダウンロードしてキャッシュして初めてPCへのアップデート配信が始まります。従って、実際の「同期」はエンドユーザが帰り始め、トラフィックが下がる午後７時から九時ごろ、早めに始めるのが効果的でしょう。

その他の情報は
islandcenter.jp

-関連記事-

Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update Server

http://islandcnt.exblog.jp/17494887/

Squid Proxy 経由で WSUS 3.0 sp2, Windows10 Update がエラー

http://islandcnt.exblog.jp/237099978/

Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update Server

Windows Update Server (WSUS 3.0 sp2) を Windows 2008 R2 で作ってみました。

Windows Update は「月の物」でいざ「今日は残業覚悟の締日」という時に限りダウンロードが始まったりすることがあります。それぞれのデータサイズが数十Mバイトもあるわけですから、みんなで動画サイトを訪問するようなもので、ISPとの回線を圧迫します。

しかも悪いことにSquid などのウェブキャッシュは無視してくれるようで、クライアントがアップデートを取りに行くときはすべてのコンピュータの通信が Microsoft のサーバーに集中してアクセスしてくれます。

Windows Update Service (WSUS) は、マイクロソフトさんの投資を減らし、サーバーライセンスの売り上げにも貢献してくれるため、無料で配布されています。

-環境-

Windows 2008 R2 sp1(x64) を使用しました。機材の関係で C: 40Gb D:30Gb のディスクをSUSE+XEN で仮想化し１．２Ｇのメモリ、４VCPU を与えました。かなり無理した構成なので実際には最低でも４Ｇ程度のメモリが必要だと思います。また、たかがパッチ管理と侮ってはいけません。かなり WSUS のサーバーはハードな処理を要求します。あまり重要な仮想サーバーとの物理マシンとの同居は避けるべきでしょう。 大元の update.windows.com が相当ハードな処理を強いられているのは想像に難くありません。Windows Update はアップデートサーバーとかなり激しいバトルを繰り広げるためでしょうか。単純にパッチのチェックをするだけでかなりのハードワークをサーバーに要求しました。どうも、ちょっとしたアップデートの確認だけでもタスクマネージャを見る限りではSQLサーバーの性能が Windows Update Service の性能を決めます。

「単なるデータのローカルキャッシュだろう」とマシンパワーを甘く設定すると、WSUS の性能が付いてこれなくて、逆効果になる可能性もありそうなケースもありそうなので、ご注意ください。禁断の手法であるフラッシュ メモリ ストレージの利用は、データベース管理者の手間を減らすこともできるのです!!とマイクロソフトさんが赤字で強調するくらいです。大量のメモリと大量の書き込みでは賞味期限があっという間になくなるSSDシステムを前提として検討した方がよさそうです。

仮想マシンのドライバは suse の VMDP2.002 を使用し、準仮想化（パラバーチャル）ドライバで動作しています。 VMDP は SUSE のサイトで探すと自動的に Novell のサイトに飛びます。

Windows Server Update Services 3.0 SP2 はこちらからダウンロードします。
http://www.microsoft.com/en-us/download/details.aspx?id=5216

他に

Microsoft Report Viewer 再頒布可能パッケージ 2008
http://www.microsoft.com/ja-jp/download/details.aspx?id=577
が必要となります。

また Windows8/2012 用にパッチが提供されています。

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

これを入れないと、 Windows 8 の Windows Update を起動すると「あれれ？」ということになります。最後にインストールします。

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

-WSUS 3.0 sp2 のインストール-

[サーバーの役割の選択] ページで、[アプリケーション サーバー] と [Web サーバー (IIS)] が選択されていることを確認します。選択されている場合は、この手順の残りを実行して、必要な役割サービスが選択されていることを確認します。選択されていない場合は、次の手順を実行して、アプリケーション サーバーと Web サーバー (IIS) をインストールします。

まず、 IIS と アプリケーションサーバー をサーバーマネージャの「役割」からインストールします。


-「インターネットインフォメーションサービス（IIS)または、追加のIISロールサービスがインストールされている必要があります」ってなんだ？-



もう一度「手順 1 : WSUS 3.0 SP2 のインストール要件を確認する」で確認しましょう。

1. [サーバーの役割の選択] ページで、[アプリケーション サーバー] と [Web サーバー (IIS)] を選択します。[次へ] をクリックします。

2. アプリケーション ロール サービスをインストールする場合は、[アプリケーション サーバー] ページで、[次へ] をクリックします。[アプリケーション サーバーの役割サービス] ページで、既定の設定を受け入れて、[次へ] をクリックします。
3. Web サーバー IIS をインストールする場合は、[Web サーバー (IIS)] ページで、[次へ] をクリックします。Web サーバー (IIS) の役割サービスのページで、既定の設定に加えて、[ASP.NET]、[Windows 認証]、[動的なコンテンツの圧縮]、および [IIS 6 管理互換] を選択します。[役割の追加ウィザード] ウィンドウが表示されたら、[必要な役割サービスを追加] をクリックします。[次へ] をクリックします。
4. [インストール オプションの確認] ページで、[インストール] をクリックします。

ということで「IIS 6 管理互換」が「追加のIISロールサービス」ということになります。

IIS のインストールスクリーンで ASP.NET をチェック


Windows 認証、動的なコンテンツの圧縮、IIS 6 管理互換をチェックしてインストールします。


アプリケーションサービスは .NET Frame work だけインストールします。


さてこれで WSUS 3.0 のインストーラーの罠を回避することができました。

許諾画面が出てきたら、あとはウィザードに従ってインストールするだけです。

ちなみにプロクシサーバーを指定すると「同期エラー」になりました。どうも Windows Update はどのシーンでも Squid キャッシュとは相性が悪いようです。この辺は徹底しています。（プロクシのポート番号まちがってしまいました...）


※ なるべくISPとの回線に余裕がある時間帯や update.microsoft.com などに負荷がかかっていない時間帯に作業すべきです。事前に ping で「ご本尊」との通信を確認してください。以外と失敗するものです。

初期データベースがロードされると、あらかじめダウンロードすべきプロダクトの一覧が出ますから、必要な分だけチェックマークを入れます。

基本的な Windows のサービスパックや Office などですね。

言語パックも必要に応じてチェックしておきます。外資系企業や貿易関連のお仕事であれば、とりひきが多い、英語や中国語などのパックも選んでおくと良いでしょう。

クラスは最低限のものだけ選択されていたので、全てのクラスをセットしました。（これは敗因）


ここから「同期」という長いタスクが始まります。

同期後は７００Mb強の Windows Update キャッシュが作られます。今後どれだけ増えるかたのしみですね。


ここで一旦サーバ自体を Update しておいて、再起動しておくと良いでしょう。
次に、WSUS 3.0sp2 用パッチを入れます。これは Windows8/2012 には必須です。手順は下の文書に詳しいのですが

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

はパスが通っていないので見つかりません。nlb.exe は　C:\Windows\winsxs のはるか彼方にありますので「検索」して、パスを見つけてコマンドプロンプトで cd してから実行します。

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

※ 一連のコマンドを実行する場合、「コマンドプロンプト」アイコンから右ボタンで「管理者として実行」を選ぶことをお勧めします。 Administrator グループのユーザではうまく動かないケースがありました。

-クライアント側の設定-

MADであれば特に述べる必要もありませんが、LANdesk や Novell ZenWorks など他のサードパーティ製ポリシー管理ツールを使っている場合だとか、なぜか社内に 「Professional 版じゃない」通常版はある場合（結構そういうケースがあるんです）は参考にしてください。

古い情報ですが、XP Home Edition を始め「無印」Windows7/8 （非Proffesional版）は mmc コンソールが使えないので、レジストリを直接設定することになります。こちらの記事が詳しいのでご参考にしてください。

Windows XP Home EditionをSUSクライアントに
http://www.atmarkit.co.jp/fsecurity/rensai/securitytips/025sus.html


> gpedit を使い「ローカルコンピューターポリシー」＞「コンピューターの構成」＞「管理用テンプレート」＞「Windows コンポーネント」 > 「Windows Update」 に次の項目があります。

- 自動更新を構成する
- イントラネットの Microsoft 更新サーバーを指定する。


この設定は任意です。自社のポリシーに従って提供します。


WSUS サーバーの http://FQDN か http://xx.xx.xx.xx の直接アドレスを指定します。・

これ以外にも Windows Update の階層に設定する項目があります。それぞれの運用ポリシーで設定します。

この直後に

> wuauclt /detectnow

を実行します。別に実行しなくても良いのですが、実行すると WSUS サーバーに「私はあなたの管理下に入りました」というシグナルを送るため、WSUSの管理コンソールに変更結果がただちに（ちょっと待ちます）反映されます。

-関連記事-

Squid Proxy 経由で WSUS 3.0 sp2, Windows10 Update がエラー。

http://islandcnt.exblog.jp/237099978/

この状態で WSUS のコンソールを見ても「何もないじゃないか」と一瞬焦りますが、「状態」トグルを「すべて」に変更すると


wuauclt を実行したクライアントが登録されます。


これで次の「締日」にどういう効果があるのかを確認することになります。

「ご本尊」との同期が終わると、WSUSの「更新」の中にアップデートプログラムが出てきます。必要な項目、というよりほぼ「重要な更新」類は「重要」なので右ボタンから「承認」、インストールダイアログから「インストール」を選択すると、SQLサーバーがガリガリと処理を初めて配信の準備をしてくれます。


あとは Windows Update から更新のチェックを行うと、設定したポリシーに従ってアップデートを行うことができます。

「更新プログラムの確認中」はWSUSとの間でパンチの応酬が始まり、ダウンロードそのものは文字通り「一瞬」で終わります。その後のインストールはクライアント側の性能次第でインストールされるということです。

-結論-
WSUS を使った Windows Update は、各PCのアップデートにかかる時間と、ISPとの回線トラフィックを大幅に減らすことができます。しかし、「必要になるのは月一回、しかしパワーが必要」ということがわかりました。

月一度、猛烈なパワーを使いたいという事になるので、あまりクリティカルな目的ではありません。ただしパッチ管理は重要であるということです。ですから、CPUやメモリと言ったリソースの配分を自由に変化できるプライベートクラウド、仮想化に対しては非常に有効です。

例えば XEN 仮想環境では Dom-U の VM ファイルを

- メモリ小、vcpu 最小の「アイドリング状態」でパッチを蓄積
- メモリ大、vcup 最大の「スクランブル状態」でパッチを配信

の二種類の設定ファイルを作って、 cron などで「今月の Windows Update の日」である毎月第二火曜日

マイクロソフト セキュリティ情報の事前通知
http://technet.microsoft.com/ja-jp/security/bulletin/advance

直前にアイドリングモードから xm shutdown を行い、 "xm create -f スクランブル用 vm ファイル" に切り替えて起動して、一週間ほど運用したら元のアイドリング状態に切り替えるなどの方法が使えそうです。何も、WSUS は千歳基地で常時スクランブル状態のジェット戦闘機の様に構えている必要はありません。月の３週間はB767のように鷹揚にHDDで稼働し、スクランブル状態であれば、イメージを SSD などに mv してスクランブル状態にしておけば良いわけです。

しかし Windows Update サーバーには巨大な「使わなくなった」アップデートの残骸が残るので、こまめに「インストール済み」の更新を「拒否」して「オプション」のクリーンアップウィザードで削除しないと、 WSUS のストアされたディレクトリが「増えるワカメちゃん」状態になってしまいます。この作業は手動です。（敗因）

※一週間くらい運用しただけで３０Ｇｂなんてディスクは食いつぶすくらい更新をダウンロードしてしまいますから容量のチェックは十分な注意が必要です。食いつぶすと「クリーンアップ」も受け付けなくなってしまいます。

※補足：「同期」というプロセスはあくまでも「本家」とのデータベース照合で、実際にはパッチのダウンロードは行っていないようです。実際に登録したPCへパッチを「承認」して配信する時点で「パッチ本体」をダウンロードしているようです。
私の環境ではプロクシをとおしているのですが、使用しているプロクシの I/O を zabbix で監視していると、どうも「同期」している時点ではパッチ本体のインターネットへのトラフィックは増えません。「承認」して配信が始まると、なんじゃこれ、というくらい、すごい勢いでプロクシのI/O が増えていました。
したがって、「承認」するタイミングも絶妙です。午後おそくに「承認」して定時後にボチボチ配信が始まる様にするのが良いのかも知れません。

お問い合わせはこちら
islandcenter.jp

-追加-
実際の日常の運用オペレーションはこちらに動画でまとめてみました。
Windows Update Service(WSUS) の日常の運用
WSUS のディスク容量がピンチ！空き容量を一挙に増やすには

-Keyword-
Windows update service WSUS 3.0 sp2 Windows8 Windows2012 0x800B0001 SUSE XEN Novell VMDP Virtual Machine Driver Pack 仮想化



http://xx.xx.xx.xx