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)
