1
2019年 11月 21日
クラウド時代のサイバーテポドン Windows Update の回線帯域を確保：GPO
何だかネットワークが遅い、エラーがでる。クラウドサービスに接続できない、などのトラブルをよく聞くようになりました。
そんな時はWindows update が帯域を食いまくっている場合があります。
Microsoft、「Windows 10」のデルタ更新を終了へ ～エクスプレス更新に一本化
何しろ ISP の回線容量をも破壊する、Windows Update はインターネット業界でのサイバーテポドン。毎月やってくるノストラダムスの大予言。
空から恐怖の大王が来るだろう、アンゴルモアの大王を蘇らせ、マルスの前後に首尾よく支配するために。
Windows Update はインターネット業界の恐怖の大魔王、諸悪の根源になりつつあります。だからWindows Update の帯域制限をしたい。
NTTコムの「OCN」が輻輳状態、Windows Updateが原因か
「なんでもクラウド」の反省すべき点で、ソフトウェアのクラウドサービスを検討する時に、真っ先に
「反省」
すべき事の一つです。
何しろ Windows10 の update は、サイズが半端ない。
で、ついにやっちまったのが、Windows update を P2P 配信するという荒業。
Windows10の Windows Update はデフォルトで使ってはいけない
しかし、結局はアップデートがキャッシュされるのはデフォルト３日が最大で、インターネット経由の P2P は結局ルータに負荷がかかる。つまり得をするのは配信の大元である Microsoft のサーバーだけなんですね。ルーター越しの回線負荷が下がるわけでなし。
しかも年に二度ほどある「大型アップデート」は３~４Gのダウンロードがあります。これで社内数百台のPCがアップデートするとどうなるのか。
もう想像がつきます。社内でみんなで Netflix やってる状態。グループポリシー（GPO）で帯域制限できないものか。
--
ま、大型アップデートはヘルプデスクチームが代表して、ISOファイルをダウンロードして共有 NAS なんかに置いておき、みんながそれをツツけば、ダウンロード自体は一回で済みます。
Windows10 手動で ISOファイル からアップデートする
- まずは Windows update の帯域制限をする -
という事で Windows Update の帯域制限をやってしまおうという事。田 ＞ 歯 ＞「更新とセキュリティ」＞Windows Update の中の "詳細オプション" > 「詳細オプション」の中の "配信の最適化" > 「配信の最適化」の中の "詳細オプション" ＞「ダウンロード設定」と「アップロード設定」というイスタンブールのトプカピ宮殿のハーレムのタンスの奥にしまったようなところに、「ヒミツの設定」が隠されており、ここのスライダーをポチっとやると、バックグラウンドでのアップデートの帯域制限ができます（きっと）。
一般的に ISP の回線設定はダウンロードよりアップロードの方が帯域が制限されているので、アップロードは極力少なくすべきでしょう。アクティビティモニタもあるので、どれくらい「貢献」したかも確認できます。
それにしても、”マイクロソフトからのダウンロード量12Gb”っていったい何をダウンロードしてるんでしょうね。一発 Windows Update すると格安 SIM をギガ爆死させる強力な破壊力。
- グループポリシーで帯域制限:GPO -
GPO グループポリシーで Windows Update の帯域制限をすることもできます。こちらの方が細かな制御ができそうです。
> gpedit
ローカルポリシー ＞ コンピューターの構成 ＞ 管理用テンプレート ＞ ネットワーク ＞ バックグラウンドインテリジェンス転送サービス（BITS） を「有効」にセットし「転送レート」をkb 単位で設定します。
「配信の最適化」では、帯域の「何％にするか」を設定するわけですが、これでは、1Gbps のローカルネットワークが 100Mbps のインターネット回線に繋がっているかどうかの判断はできないわけです。仮に "10%" で設定すると、１Gbpsの１０％、つまり100 Mbps で通信しちゃうのですんね（たぶん）。
一方 GPO で設定する BITS は具体的に「転送速度」を指定できるので、LANの状態やインターネット回線の「太さ」に合わせて細かな設定ができるので、グループポリシーを使った方に分がありそうです。という事で細い回線なら数十Kbps、早い回線でも、社内LANにどれ位の台数の端末があるかにもよりますが、100Kbps 程度（多分）に控えておくのが良いと思います。> gpupdate を実行してポリシーを適用します。
C:\>gpupdateポリシーを最新の情報に更新しています...コンピューター ポリシーの更新が正常に完了しました。ユーザー ポリシーの更新が正常に完了しました。C:\>
まぁ台数が多いなら、WSUSを入れる方がよほど効果がありそうなんですが、WSUSも最近はどうも動作が妖しい。
- BITS って何だ？ -
BITS(Background Intelligent Transfer Service)は、ネットワークがアイドリングしている時にバックグラウンド通信を行うように制御することです。これで必要な通信量を確保するのですが、所詮、OSが認識できるのは NIC の通信量、つまり LAN の通信量が制御できるだけ。ルーターにどれだけトラフィックがかかっているかは判断できないでしょうね。「配信の最適化」機能で使われる技術です。
- WSUS と併用する -
WSUSと併用する場合、次の文書が役に立ちそうです。
配信の最適化について #2 グループポリシー篇https://blogs.technet.microsoft.com/jpwsus/2018/11/02/aboutdo_2/Windows 10 の更新プログラムの配信の最適化https://docs.microsoft.com/ja-jp/windows/deployment/update/waas-optimize-windows-10-updates
グループポリシーを使います。
> gpedit
ローカルコンピュータポリシー ＞ コンピュータの構成 ＞ 管理用テンプレート ＞ "Windows コンポーネント" にある "配信の最適化" の中にローカルネットワークでの Windows Update の配信の最適化のパラメータがいくつかあります。「歯」（設定）にある P2P 配信の抑制よりもよほど細かな制御ができそうです。
C:\>gpupdateポリシーを最新の情報に更新しています...コンピューター ポリシーの更新が正常に完了しました。ユーザー ポリシーの更新が正常に完了しました。C:\>
もっとも、Windows Update の配信をLAN内で最適化すると言っても、「持つべき者が持たざる者に施す」ことは、「持つべき者」に余計な負荷がかかるわけで、エンドユーザさんには決して好ましい機能ではありません。そのための Windows Update Service (WSUS) なのだから、やはり、構内であってもクライアントに負荷がかかる P2P 配信は、おすすめできるものではありません。
また Windows の AD では OU 単位にポリシー掛けまくるので、エライさんのPCは快適に、そうでないパートさんのPCの配信率を上げる、と言った制御ができません。ま、OUを分ければいいのでしょうが、そうなるとまた管理が煩雑になる。Novell の ZENworks の様な、サードパーティ製のクライアントPC管理ツールを検討した方が速そうです。
「配信の最適化」については上の、Microsoft のドキュメントの中に、エンタープライズでの「お勧め」パラメータの記述があるので、参考にしてみましょう。
上の文書の「配信の最適化」の”ダウンロードモード”には次の６つの設定があります。
- 0: HTTPのみ -- P2P は使わず、Microsoft の Update サーバーとのみ通信、台数が少ない時はこれですかね。
- 1: LAN -- Microsoft のアップデートサーバーや WSUS からダウンロードしたものを、同じパブリックアドレス内でBITSを使って P2P 通信。VPN で同じパブリックアドレスを使っている場合はWAN越しの通信もあり。Pro 版はこれらしい。
- 2: グループ -- AD ドメイン内で P2P 通信をする。同じドメインなら WAN越しの通信も発生するので注意が必要。グループ ID との組み合わせ推奨
- 3: インターネット -- HOME エディションの標準、同一プライベートLAN、パブリック WAN 間で P2P 通信、見ず知らずの他人と妖しい通信がある。
- 99: 簡易 -- P2P を使わず WSUS からのみ HTTPダウンロード、急いで配布したいならこれか？
- 100: バイパス -- P2P を使わず BITS を使って WSUS からのみダウンロード
Windows10 1607 から以前のバージョンにはこの機能がないようなので、下の文書から、管理テンプレート admx をダウンロードして使える様です。
グループ ポリシーを使用して Windows 10 で Windows Update の配信の最適化を構成する方法
まだ Windows update だけなら手段はあるのですが、iPhone の iOS のアップデートなんかも、自宅でやるとアレなので、カイシャの Wifi 経由でやっちゃう輩もいるわけですね。これもバカにならない。
また Windows の OneDrive も、ネットワーク回線に異常なトラフィックをかける極悪機能です。
社内ネットワークは「便利だから使う共有リソース」であって、個人の我儘を満たすものであってはならない。何らかのルールが必要なんですね。
極悪 Windows10 の OneDrive を無効にする
--
グループポリシー：GPO で設定する BITS と、歯（設定）にある「配信の最適化」のどちらが優先されるかは資料が見つかりませんでした。コメントいただけるとありがたいです。
▲
by islandcenter
| 2019-11-21 12:04
| Windows
|
Comments(0)
2016年 10月 17日
WSUS のディスク容量がピンチ！空き容量を一挙に増やすには
この記事は書き換える可能性があります。
2016/10 より、Windows Update のポリシーが変わったせいでしょうか、急に WSUS の容量が爆発的にふえてしまったのです。
1) インストール済のパッチの拒否
2) クリーンアップウィザード
3) WSUS 自身のアップデート
4) 同期
5) 世間のパッチの不具合の話題をチェックしてインストールの承認
6) パッチのダウンロードと配信
という流れが出来てきます。これで毎月運用していれば WSUS の使用ディスク容量なんて２０Gから３０G程度で落ち着いてくれます。
ところが、ある日、クリーンアップウィザードを実施しても、全然キャッシュが消えないという不思議な現象に出くわしました。WSUS ピンチです。40G確保したD:ドライブを dd コマンドで４Gほど増やしてみて（当然仮想化運用です）も、キャッシュドライブは、大泉洋が作るスパゲッティみたいに膨れ上がる一方です。
ということで、WSUS の空き容量を緊急に確保する緊急手段です。
Windows Update Service > 「オプション」 > 「更新ファイルと更新言語」を開きます。
ギリギリだった容量が一挙に回復しました。
OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ) https://islandcnt.exblog.jp/238412872/ フォルダの容量制限付きアーカイブ専用ファイルサーバー：サーバーをゴミ箱にしない工夫 https://islandcnt.exblog.jp/238371771/ クライアントPCのBCP対策 D:ドライブにドキュメントを保管・バックアップ https://islandcnt.exblog.jp/238911684/ SUSE linux15 virt-manager が起動できない https://islandcnt.exblog.jp/239299263/ クラウド時代のサイバーテポドン Windows Update の回線帯域を確保 https://islandcnt.exblog.jp/239787249/
▲
by islandcenter
| 2016-10-17 17:20
| プライベートクラウド
|
Comments(0)
2015年 10月 04日
Windows10の Windows Update はデフォルトで使ってはいけない。
Windows10 の Windows Update は P2P の仕組みを利用して配信するように、デフォルト設定されています。どの様な仕組みなのかは、明らかにされていませんが、アップデートプログラムが Microsoft からではなく、不特定のインターネットに接続されたＰＣから入手されるような仕掛けがデフォルトです。
設定＞更新とセキュリティ＞「詳細オプション」＞「更新プログラムの提供方法を選ぶ」という、山深い伊賀忍法のヒミツの隠し戸のようなトコロにこの設定があります。
「ローカルネットワーク上のPCとインターネット上のPC」がデフォルトなので、これを「ローカルネットワーク上のPC」のみにします。
複数の場所から更新するはONでも構いませんが、入手先はローカルネットワークのみにします。僻地でダイアルアップ回線を使っている（限界集落なら当然）なら、もちろんＯＦＦですね。
最初にアップデートを受け取るＰＣは Microsoft からの転送になりますが、一度受け取ったアップデートはローカルネットワーク内部でＰ２Ｐ配信されるようです。もっとも、社内に Windows Update Server (WSUS) を用意してあるのであれば、すべてそこから供給を受けるべきなのでＰ２Ｐ配信もＯＦＦにするのが良いでしょう。
Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update ServerWSUS のディスク容量がピンチ！空き容量を一挙に増やすには
どうせ一台目はMicrosoft から受けざるを得ません。しかし、他の全く面識のないWindows ユーザにアップデートを送信する義務は、利用者にとっては全く意味のないことですし、受け取るにもどのような危険性があるかわかりません。アップデートを配信するのは Microsoft の義務ですから、ユーザのリソースを勝手に使わないで、自社の配信設備をちゃんと金かけて構築してくれと言いたくなります。よくゲームのパッチ配信でＰ２Ｐ技術を使ってウィルスまがいのソフトウェアがご訪問してくることもよく聞きます。
また、自分のＬＡＮ内のＰＣから、アップデートが外に出ていくという事は、当たり前ですが、自社のネットワークのアウトゴーイングのトラフィックに 社内からDDoSの踏み台になって攻撃してんじゃないのってくらいの、アップロードの負荷をかけます。そのコストは利用者が負担しなければなりません。もちろん私たちはそんな義務はありません。当然従量課金制の無線ネットワークを利用しているユーザにとっては、パケット代もＩＳＰへの「お布施」になってしまいます。
という事で、Windows Update は、自社の社内ネットワークだけのＰ２Ｐコピーにとどめておくことをお勧めします。
"Do not use Windows Update on default condition"
関連記事
クラウド時代のサイバーテポドン Windows Update の回線帯域を確保
補足記事
Windows 10 更新プログラムにおけるP2P配信の仕組み - 阿久津良和のWindows Weekly Report
その他の情報はこちら
-key Word-
Windows10 Update Default 変更 SUSE Linux Novell NetIQ
▲
by islandcenter
| 2015-10-04 22:01
| Windows
|
Comments(0)
2013年 12月 16日
Windows Update Service(WSUS) の日常の運用
Windows Update Service(WSUS 3.0) の日常の運用について説明します。
Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update Server の続きです。
通常の Windows Update は月に一度の公開ですが、WSUS で見ると、毎日新しいアップデートが提供されていることがわかります。マイクロソフトから公開されるタイミングと、こちらの業務のタイミングが合わないと、忙しい時期にアップデートを取り込んでとっ散らかることもあります。
WSUS ではアップデートのタイミングをこちらで設定できるので、こちらの「心の準備」ができてから配信することが出来ます。
最新の同期状態をチェックし、アップデートがある場合、アップデート配信を「承認」し、配信日時を決めることが出来ます。ここでは「今すぐ配信」を開始するようにしてみました。
次に、アップデートが配信されているかの確認です。
アップデートの配信が終わった後は、サーバーに残った「不要になったアップデート」をクリーンアップします。この作業をやらないと、ディスクがとんでもないことになってしまうのでこまめにクリーンアップウィザードを使って、アップデートファイルからディスク容量を解放します。
承認済みのアップデートから「全て」を選ぶとアップデートファイル全体の何％が配信済みかがわかります。１００％配信が終わったアップデートは「拒否」して、クリーンアップウィザードを開始して、不要なファイルを削除します。
結構時間がかかる作業なので負荷の少ない時間帯を選んで実施するとよいでしょう。
-補足-
ちなみに WSUS と本家との「同期」というのはデータベースの同期であり、アップデートを受け取りキャッシュしておくものではないようです。zabbix でチェックしてみるとデータベースと「同期」した後は、時間をかけて本家からアップデートをダウンロードしていました。量にもよりますが、数十分から数時間ダウンロードを続けます。つまり「同期」は「見積もり」から「発注」までを意味して「納品」されるのはその後という事です。
この間は、Windows Update を実行しても登録したPCにアップデートは配信されません。 WSUS が完全にアップデートをダウンロードしてキャッシュして初めてPCへのアップデート配信が始まります。従って、実際の「同期」はエンドユーザが帰り始め、トラフィックが下がる午後７時から九時ごろ、早めに始めるのが効果的でしょう。
Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update Server の続きです。
通常の Windows Update は月に一度の公開ですが、WSUS で見ると、毎日新しいアップデートが提供されていることがわかります。マイクロソフトから公開されるタイミングと、こちらの業務のタイミングが合わないと、忙しい時期にアップデートを取り込んでとっ散らかることもあります。
WSUS ではアップデートのタイミングをこちらで設定できるので、こちらの「心の準備」ができてから配信することが出来ます。
※ まず、重要なことは、パッチがリリースされたら、その配信直後にある不具合をしっかりチェックする事です。パッチを適用したら、再起動できないとか、致命的で修復困難なトラブルがあるかないかを数日チェックして、それから、「承認」の手続きに入ることです。大抵” Windows Update, 月例, n月度, 不具合”なんてキーワードで見つかります。また、「承認」するまえに WSUS と Windows サーバーをしっかりアップデートしてから、慌てて配信しないのが良いでしょう。２～３日、情報を集めて、問題がない事を確認してから配信するのがポイントです。もちろん管理者が十分なバックグラウンドジョブを抱えていないタイミングを選ぶのはとても大切な事です。
最新の同期状態をチェックし、アップデートがある場合、アップデート配信を「承認」し、配信日時を決めることが出来ます。ここでは「今すぐ配信」を開始するようにしてみました。
PR - Windows の開発環境が欲しいンだが .. -PR
次に、アップデートが配信されているかの確認です。
アップデートの配信が終わった後は、サーバーに残った「不要になったアップデート」をクリーンアップします。この作業をやらないと、ディスクがとんでもないことになってしまうのでこまめにクリーンアップウィザードを使って、アップデートファイルからディスク容量を解放します。
承認済みのアップデートから「全て」を選ぶとアップデートファイル全体の何％が配信済みかがわかります。１００％配信が終わったアップデートは「拒否」して、クリーンアップウィザードを開始して、不要なファイルを削除します。
結構時間がかかる作業なので負荷の少ない時間帯を選んで実施するとよいでしょう。
-補足-
ちなみに WSUS と本家との「同期」というのはデータベースの同期であり、アップデートを受け取りキャッシュしておくものではないようです。zabbix でチェックしてみるとデータベースと「同期」した後は、時間をかけて本家からアップデートをダウンロードしていました。量にもよりますが、数十分から数時間ダウンロードを続けます。つまり「同期」は「見積もり」から「発注」までを意味して「納品」されるのはその後という事です。
この間は、Windows Update を実行しても登録したPCにアップデートは配信されません。 WSUS が完全にアップデートをダウンロードしてキャッシュして初めてPCへのアップデート配信が始まります。従って、実際の「同期」はエンドユーザが帰り始め、トラフィックが下がる午後７時から九時ごろ、早めに始めるのが効果的でしょう。
その他の情報は
islandcenter.jp
islandcenter.jp
-関連記事-
Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update ServerSquid Proxy 経由で WSUS 3.0 sp2, Windows10 Update がエラークラウド時代のサイバーテポドン Windows Update の回線帯域を確保
▲
by islandcenter
| 2013-12-16 12:37
| Windows
|
Comments(0)
2013年 04月 03日
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 してから実行します。
※ 一連のコマンドを実行する場合、「コマンドプロンプト」アイコンから右ボタンで「管理者として実行」を選ぶことをお勧めします。 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の管理コンソールに変更結果がただちに（ちょっと待ちます）反映されます。
この状態で 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
Windows Update は「月の物」でいざ「今日は残業覚悟の締日」という時に限りダウンロードが始まったりすることがあります。それぞれのデータサイズが数十Mバイトもあるわけですから、みんなで動画サイトを訪問するようなもので、ISPとの回線を圧迫します。
しかも悪いことにSquid などのウェブキャッシュは無視してくれるようで、クライアントがアップデートを取りに行くときはすべてのコンピュータの通信が Microsoft のサーバーに集中してアクセスしてくれます。
Windows Update Service (WSUS) は、マイクロソフトさんの投資を減らし、サーバーライセンスの売り上げにも貢献してくれるため、無料で配布されています。
PR- 今すぐに使える Windows -PR
-環境-
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 のインストーラーの罠を回避することができました。
許諾画面が出てきたら、あとはウィザードに従ってインストールするだけです。
ちなみにプロクシサーバーを指定すると「同期エラー」になりました。
※ なるべく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 がエラー。
この状態で 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
▲
by islandcenter
| 2013-04-03 18:43
| Windows
|
Comments(0)
1
