運用IISサーバーでWindows自動更新を有効のままにしますか？

Windows Server 2003（IIS6）で年中無休のWebサイトを実行している場合。Windows自動更新機能を有効のままにしますか、それともオフにしますか？

有効にすると、最新のセキュリティパッチとバグ修正が入手可能になり次第、自動的に取得されます。これが最も安全な選択です。ただし、更新を適用するためにマシンが自動的に再起動される場合があり、深夜に数分のダウンタイムが発生します。また、マシンが正常に再起動せず、ダウンタイムが長くなることもまれにあります。

自動更新がオフの場合、いつパッチを適用しますか？複数のWebサーバーでロードバランサーを使用し、それらを運用サイトからローテーションして、手動でパッチを適用し、元に戻す必要があると思います。また、常に最新のセキュリティパッチがインストールされているとは限らない運用環境のマシンがあり、どのパッチをいつ適用するかを決定するために定期的に時間を費やす必要があります。

短い答え、いいえ。

最善のシナリオでは、少なくとも別のbox / vm / guinea pigを使用してパッチをテストし、ワールドが破壊されないことを確認する必要があります。

最悪の場合、パッチのダウンロードは許可するがインストールは許可しないため、インストールされている内容を確認できます。しかし、私はそのようにただコントロールマニアです。

私はコンセンサスに反対する必要があると思います。

「人間の介入が必要」と言う人はだんだんと十分に考えていません。

すべてを自動化します。

たぶん、これは自動更新をオンにすることを意味します（私はこれを自分の影響の少ない環境で行います）。

それはもっと厳密なことを意味するかもしれません（ステージング環境を自動的に更新し、正常に動作するかどうかを自動的に検証してから、実稼働環境で自動更新をトリガーします）。管理者がプロセスのステータスを把握できるように、レポートまたは電子メール通知を使用する必要があります。

powershellスクリプトからSoftware Update Services（SUS）に至るまで、この自動化を実現する方法はいくつかあります。特に、サーバーフォールトではなくstackoverflowでこの質問をしたので、できるだけ多くを自動化するルーチンを開発することをお勧めします可能な限り更新プロセス。

そうしないと、更新プログラムを適用しなかったり、不適切に適用したりする危険があります。また、あなたが私のような人なら、更新が失敗したときにブルームーンで午前3時に一度目を覚まし（更新ルーチンによってページングされている）、更新をインストールするために毎月午前3時に目を覚まさないことを好むでしょう影響の少ない時間中。

もちろん、YMMV。自分に最適なプロセスを設計しますが、不必要に多くの作業を行わないようにしてください。

運用Windowsサーバーの場合、更新プログラムを自動的にダウンロードしてインストールするようにWindows Updateを設定することはお勧めしません。より良い方法は、更新を自動的にダウンロードし、手動でインストールすることです。

このアプローチの利点は次のとおりです。

1. インストール前に提案された更新を確認し、必要に応じて、更新のインストールの影響を調査できます。これはより多くの作業のように見えるかもしれません-それはそうです！しかし、少なくともあなたはコントロールできます。Microsoftは、Windows Updateの次のバッチでリリースされる更新の種類を早期に通知する無料のメーリングリストも提供しています 。
2. Webサイトへの訪問者への影響を最小限に抑える再起動時間を決定できます。あなたのウェブサイトは単一のサーバーから実行されているように見えるので、再起動が迫っていることを訪問者に警告するバナーをウェブサイトに表示すると便利かもしれません。再起動の1時間前に表示され、「メンテナンスのためウェブサイトがx分で閉じます。メンテナンスにかかる時間は10分以内です
3. サーバーの再起動を手動で開始したため、再起動後にサーバーが正常に起動したことを確認できます。そうでない場合は、ホスティングプロバイダーに相談して問題に対処できます。

基本的には制御がすべてであり、自動ダウンロードと自動インストールでは、多くは得られません!!

自動更新を許可していますが、WSUSを使用して更新しています。これにより、自動的に適用する更新プログラムのクラスを選択して選択できるため、気にしないトリビアの中断を回避できますが、できるだけ早くDay 0エクスプロイトのパッチを取得できます。

「更新を許可する」と「許可しない」が正しいか間違っているかは問題ではないと思います。ちなみに、それは単にあなたがどのようなリスクと不便を冒すかを選ぶだけの問題です。更新を自動的に実行することにはリスクがあり、そうしないとリスクがあります。それらのバランスを取り、情報に基づいた選択を行います。

段階的なロールアウトを検討することができます-火曜日にリリースされたパッチは、テスト環境にすぐにインストールされ、実稼働サーバーに木曜日にインストールされるようにスケジュールされます。特定のパッチの遅延。

高可用性がそれほど問題である場合は、とにかく必要に応じてクラスタリングまたは負荷分散を使用する必要があります。これは、パッチを適用することによるダウンタイムをカバーするはずです。結局のところ、パッチによるダウンタイムが、1つのボックスでいつでも発生する可能性のあるハードウェア障害よりもなぜか魔法のように悪いのはなぜですか？

サーバーで自動更新を有効にすることはありません。データセンターでホストされているため、Googleアナリティクスの統計を見てトラフィックが最も少ない時間を確認し、その時間にオンサイトで更新プログラムをインストールするように技術者をスケジュールしました。そうすれば、再起動が必要な場合、または何かがひどく間違っていたとしても、Windowsが1日の途中で更新プログラムをダウンロードした場合ほど多くの人には影響しません。

ここの他のみんながすでに答えているように： いいえ！ Systems Centers Essentialsを使用して、テストサーバーにインストールされた後でのみ、運用Webサーバーに更新をプッシュします。

また、MSから毎月の更新メールを受け取り、各更新の内容とその目的を正確に把握しています。何がいつ更新されたかを正確に知っていれば、トラブルシューティングがずっと簡単になります。

絶対にありません。このナンセンスが起こらないように何度も難しい方法で教えられました。残念ながら、パッチとアップデートの適用に関して少し怠であることを意味します。しかし、これまでのところ、私はすぐにいくつかの特定のパッチを適用していなかったために分割サーバーを持っていましたが、私がしている不便な時に再起動するサーバによって、または再起動しに失敗によって引き起こされる非常に多くの頭痛を持っていましたパッチをインストールした後、いくつかの重要なサービスを開始します。

補足として、世界のこの地域の非常に大規模で有名なISPであるサービスプロバイダーを介して、5台のマシンの新しいクラスターを取得しました。管理者アカウントを取得し、ログインしてソフトウェアのセットアップを開始できるようになったとき、この通常の最初のタスクがネットワークのシステム管理者によってすでに処理されていることを非常に嬉しく思いました。:)

アップデートの適用==システムのランダムな再起動であり、あなたの制御下ではありません。これにより、SAの巣ができます。さらに、過去にパッチを壊すという事件があったため、過去にパッチを試したことがない場合、パッチを適用することはほとんどありません。

私が検討してきた1つのアプローチは、仮想化されたホスティング環境への移行です。これにより、非実稼働インスタンスで更新を試用したり、オフラインインスタンスに更新を適用して、実行に問題がないことが確認できたら実稼働にスワップしたりできます。

絶対違う。更新は、営業時間外にサーバーに適用し、緊急時対応計画を実施する必要があります。これは、更新が失敗した場合にロールバックするのに十分な時間を意味します。

システム管理者は、できるだけ多くの変数を管理する必要があります。午前中に死んだサーバーに到着することなく、それは十分に難しいです！;-)

更新が行われる特定の時間を設定することができ、ほとんどの更新は火曜日に行われることに注意してください。そうすることで、今後の更新やダウンロードされた更新を確認する時間をスケジュールし、潜在的な問題がいつ発生するかを知ることができます。

自問すべき良い質問は、何かが私のVP / CIO / etcが私に言っていることを台無しにするかどうかです。それを自動化することはあなたの人生を楽にするかもしれませんが、問題があるならあなたは石炭の上でかき集められることになるでしょう、そしてこれは物事をずっと難しくするかもしれません。

私はあなたがしなければならない数百を使って、PCを完全に自動化します。サーバーは私がそれをスケジュールし、承認されるので、もし何かがうまくいかなければ私の$$$がカバーされます。私たちは他の人々のデータや企業のリソースを使用していることを忘れないでください。彼らは常にリスクを認識しておく必要があります。