2019年 11月 21日
リモートワーク時代のサイバーテポドン Windows Update の回線帯域を確保:GPO
Microsoft、「Windows 10」のデルタ更新を終了へ ~エクスプレス更新に一本化
空から恐怖の大王が来るだろう、アンゴルモアの大王を蘇らせ、マルスの前後に首尾よく支配するために。
NTTコムの「OCN」が輻輳状態、Windows Updateが原因か
「反省」
Windows10の Windows Update はデフォルトで使ってはいけない
Windows10 手動で ISOファイル からアップデートする
という事で Windows Update の帯域制限をやってしまおうという事。田 > 歯 >「更新とセキュリティ」>Windows Update の中の "詳細オプション" > 「詳細オプション」の中の "配信の最適化" > 「配信の最適化」の中の "詳細オプション" >「ダウンロード設定」と「アップロード設定」というイスタンブールのトプカピ宮殿のハーレムのタンスの奥にしまったようなところに、「ヒミツの設定」が隠されており、ここのスライダーをポチっとやると、バックグラウンドでのアップデートの帯域制限ができます(きっと)。
一般的に ISP の回線設定はダウンロードよりアップロードの方が帯域が制限されているので、アップロードは極力少なくすべきでしょう。アクティビティモニタもあるので、どれくらい「貢献」したかも確認できます。
それにしても、”マイクロソフトからのダウンロード量12Gb”っていったい何をダウンロードしてるんでしょうね。一発 Windows Update すると格安 SIM をギガ爆死させる強力な破壊力。
GPO グループポリシーで Windows Update の帯域制限をすることもできます。こちらの方が細かな制御ができそうです。
> gpedit
ローカルポリシー > コンピューターの構成 > 管理用テンプレート > ネットワーク > バックグラウンドインテリジェンス転送サービス(BITS) を「有効」にセットし「転送レート」をkb 単位で設定します。
「配信の最適化」では、帯域の「何%にするか」を設定するわけですが、これでは、1Gbps のローカルネットワークが 100Mbps のインターネット回線に繋がっているかどうかの判断はできないわけです。仮に "10%" で設定すると、1Gbpsの10%、つまり100 Mbps で通信しちゃうのですんね(たぶん)。
一方 GPO で設定する BITS は具体的に「転送速度」を指定できるので、LANの状態やインターネット回線の「太さ」に合わせて細かな設定ができるので、グループポリシーを使った方に分がありそうです。という事で細い回線なら数十Kbps、早い回線でも、社内LANにどれ位の台数の端末があるかにもよりますが、100Kbps 程度(多分)に控えておくのが良いと思います。> gpupdate を実行してポリシーを適用します。
C:\>gpupdateポリシーを最新の情報に更新しています...コンピューター ポリシーの更新が正常に完了しました。ユーザー ポリシーの更新が正常に完了しました。C:\>
まぁ台数が多いなら、WSUSを入れる方がよほど効果がありそうなんですが、WSUSも最近はどうも動作が妖しい。
BITS(Background Intelligent Transfer Service)は、ネットワークがアイドリングしている時にバックグラウンド通信を行うように制御することです。これで必要な通信量を確保するのですが、所詮、OSが認識できるのは NIC の通信量、つまり LAN の通信量が制御できるだけ。ルーターにどれだけトラフィックがかかっているかは判断できないでしょうね。「配信の最適化」機能で使われる技術です。
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 配信の抑制よりもよほど細かな制御ができそうです。 > gpupdate を実行してポリシーを適用します。
C:\>gpupdateポリシーを最新の情報に更新しています...コンピューター ポリシーの更新が正常に完了しました。ユーザー ポリシーの更新が正常に完了しました。C:\>
もっとも、Windows Update の配信をLAN内で最適化すると言っても、「持つべき者が持たざる者に施す」ことは、「持つべき者」に余計な負荷がかかるわけで、エンドユーザさんには決して好ましい機能ではありません。そのための Windows Update Service (WSUS) なのだから、やはり、構内であってもクライアントに負荷がかかる P2P 配信は、おすすめできるものではありません。
また Windows の AD では OU 単位にポリシー掛けまくるので、エライさんのPCは快適に、そうでないパートさんのPCの配信率を上げる、と言った制御ができません。ま、OUを分ければいいのでしょうが、そうなるとまた管理が煩雑になる。Novell の ZENworks の様な、サードパーティ製のクライアントPC管理ツールを検討した方が速そうです。
「配信の最適化」については上の、Microsoft のドキュメントの中に、エンタープライズでの「お勧め」パラメータの記述があるので、参考にしてみましょう。
上の文書の「配信の最適化」の”ダウンロードモード”には次の6つの設定があります。
- 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 の配信の最適化を構成する方法
極悪 Windows10 の OneDrive を無効にする
2016年 10月 17日
WSUS のディスク容量がピンチ!空き容量を一挙に増やすには

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





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/
isLandcenter.jp -Keyword- WSUS 3.0 ディスクが満杯 アップデートの削除 ディスクの節約 容量不足 空き容量
2015年 10月 04日
Windows10の Windows Update はデフォルトで使ってはいけない。

Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update ServerWSUS のディスク容量がピンチ!空き容量を一挙に増やすには
2013年 12月 16日
Windows Update Service(WSUS) の日常の運用
Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update Server の続きです。
通常の Windows Update は月に一度の公開ですが、WSUS で見ると、毎日新しいアップデートが提供されていることがわかります。マイクロソフトから公開されるタイミングと、こちらの業務のタイミングが合わないと、忙しい時期にアップデートを取り込んでとっ散らかることもあります。
WSUS ではアップデートのタイミングをこちらで設定できるので、こちらの「心の準備」ができてから配信することが出来ます。
※ まず、重要なことは、パッチがリリースされたら、その配信直後にある不具合をしっかりチェックする事です。パッチを適用したら、再起動できないとか、致命的で修復困難なトラブルがあるかないかを数日チェックして、それから、「承認」の手続きに入ることです。大抵” Windows Update, 月例, n月度, 不具合”なんてキーワードで見つかります。また、「承認」するまえに WSUS と Windows サーバーをしっかりアップデートしてから、慌てて配信しないのが良いでしょう。2~3日、情報を集めて、問題がない事を確認してから配信するのがポイントです。もちろん管理者が十分なバックグラウンドジョブを抱えていないタイミングを選ぶのはとても大切な事です。
最新の同期状態をチェックし、アップデートがある場合、アップデート配信を「承認」し、配信日時を決めることが出来ます。ここでは「今すぐ配信」を開始するようにしてみました。
次に、アップデートが配信されているかの確認です。
アップデートの配信が終わった後は、サーバーに残った「不要になったアップデート」をクリーンアップします。この作業をやらないと、ディスクがとんでもないことになってしまうのでこまめにクリーンアップウィザードを使って、アップデートファイルからディスク容量を解放します。
承認済みのアップデートから「全て」を選ぶとアップデートファイル全体の何%が配信済みかがわかります。100%配信が終わったアップデートは「拒否」して、クリーンアップウィザードを開始して、不要なファイルを削除します。
結構時間がかかる作業なので負荷の少ない時間帯を選んで実施するとよいでしょう。
-補足-
ちなみに WSUS と本家との「同期」というのはデータベースの同期であり、アップデートを受け取りキャッシュしておくものではないようです。zabbix でチェックしてみるとデータベースと「同期」した後は、時間をかけて本家からアップデートをダウンロードしていました。量にもよりますが、数十分から数時間ダウンロードを続けます。つまり「同期」は「見積もり」から「発注」までを意味して「納品」されるのはその後という事です。

この間は、Windows Update を実行しても登録したPCにアップデートは配信されません。 WSUS が完全にアップデートをダウンロードしてキャッシュして初めてPCへのアップデート配信が始まります。従って、実際の「同期」はエンドユーザが帰り始め、トラフィックが下がる午後7時から九時ごろ、早めに始めるのが効果的でしょう。
islandcenter.jp
Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update ServerSquid Proxy 経由で WSUS 3.0 sp2, Windows10 Update がエラークラウド時代のサイバーテポドン Windows Update の回線帯域を確保
2013年 04月 03日
Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update Server
Windows Update は「月の物」でいざ「今日は残業覚悟の締日」という時に限りダウンロードが始まったりすることがあります。それぞれのデータサイズが数十Mバイトもあるわけですから、みんなで動画サイトを訪問するようなもので、ISPとの回線を圧迫します。
しかも悪いことにSquid などのウェブキャッシュは無視してくれるようで、クライアントがアップデートを取りに行くときはすべてのコンピュータの通信が Microsoft のサーバーに集中してアクセスしてくれます。
Windows Update Service (WSUS) は、マイクロソフトさんの投資を減らし、サーバーライセンスの売り上げにも貢献してくれるため、無料で配布されています。
-環境-
Windows 2008 R2 sp1(x64) を使用しました。機材の関係で C: 40Gb D:30Gb のディスクをSUSE+XEN で仮想化し1.2Gのメモリ、4VCPU を与えました。かなり無理した構成なので実際には最低でも4G程度のメモリが必要だと思います。また、たかがパッチ管理と侮ってはいけません。かなり 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 などですね。
言語パックも必要に応じてチェックしておきます。外資系企業や貿易関連のお仕事であれば、とりひきが多い、英語や中国語などのパックも選んでおくと良いでしょう。
クラスは最低限のものだけ選択されていたので、全てのクラスをセットしました。(これは敗因)

ここから「同期」という長いタスクが始まります。
同期後は700Mb強の 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 は千歳基地で常時スクランブル状態のジェット戦闘機の様に構えている必要はありません。月の3週間はB767のように鷹揚にHDDで稼働し、スクランブル状態であれば、イメージを SSD などに mv してスクランブル状態にしておけば良いわけです。
しかし Windows Update サーバーには巨大な「使わなくなった」アップデートの残骸が残るので、こまめに「インストール済み」の更新を「拒否」して「オプション」のクリーンアップウィザードで削除しないと、 WSUS のストアされたディレクトリが「増えるワカメちゃん」状態になってしまいます。この作業は手動です。(敗因)
※一週間くらい運用しただけで30Gbなんてディスクは食いつぶすくらい更新をダウンロードしてしまいますから容量のチェックは十分な注意が必要です。食いつぶすと「クリーンアップ」も受け付けなくなってしまいます。
※補足:「同期」というプロセスはあくまでも「本家」とのデータベース照合で、実際にはパッチのダウンロードは行っていないようです。実際に登録した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