[Q&A]
|
|
はじめに
Windows OSやアプリケーションの脆弱性を修正し、ウイルスや不正アクセスなどからシステムを保護するためには、更新プログラムの適用と管理が重要だ。本連載では、更新プログラムの管理にWindows Server Update Services(WSUS)を実際に活用しているユーザーならではの、よくある疑問や質問をピックアップして回答する。なお、特にバージョンを示さない場合は、最新のWSUS 3.0を対象とする。WSUS 3.0の機能や操作方法については、別稿の「[運用]これから始めるWSUS 3.0入門(前編)」と「[運用]これから始めるWSUS 3.0入門(後編)」も参照していただきたい。
■Q&A■
更新プログラムがどのような手順で適用されるのか知りたい。 |
現象の詳細:
WSUSクライアントのグループ・ポリシーを使って、更新プログラムを自動的に適用するよう設定したつもりだが、予定したスケジュールどおりに適用できないことがある。スケジュール適用がどのようなケースで失敗するのか知りたい。
失敗の原因を探るには、自動更新の設定によって、どのように更新プログラムが適用されるのかを理解する必要がある。 |
自動更新のためのグループ・ポリシーの設定
自動更新の仕組みを解説する前に、WSUSを使って更新プログラムをスケジュール適用するための、必須のグループ・ポリシー設定について確認しておこう。「自動更新」がWSUSクライアントで動作するには、まず「イントラネットのMicrosoft更新サービスの場所を指定する」ポリシーを有効にする必要がある(画面1)。併せて[更新を検出するためのイントラネットの更新サービスを設定する]オプションと[イントラネット統計サーバーの設定]オプションにWSUSサーバへのアクセス用URLを設定することで、自動更新はWindows Update Webサイトではなく、WSUSサーバにアクセスするようになる。
画面1 「イントラネットのMicrosoft更新サービスの場所を指定する」ポリシーのプロパティ | ||||||
「イントラネットのMicrosoft更新サービスの場所を指定する」ポリシーのプロパティを開いてポリシーを有効にしたうえで、[更新を検出するためのイントラネットの更新サービスを設定する]オプションと[イントラネット統計サーバーの設定]オプションにWSUSサーバへのアクセス用URLを設定する。 | ||||||
|
次に有効にするポリシーは、「自動更新を構成する」ポリシーである(画面2)。[自動更新の構成]ドロップダウン・リストを[4−自動ダウンロードしインストール日時を指定]に設定すると、更新プログラムのスケジュール適用が可能になる。具体的なスケジュールは、[インストールを実行する日]オプションと[インストールを実行する時間]オプションで指定する。
画面2 「自動更新を構成する」ポリシーのプロパティ | |||||||||
「自動更新を構成する」ポリシーのプロパティを開いてポリシーを有効にしたうえで、[4−自動ダウンロードしインストール日時を指定]を選択する。 | |||||||||
|
ここまでは、ほとんどの管理者が間違いなく設定できることだし、誤りにも気付きやすいはずだ。にもかかわらずスケジュール適用が失敗するのは、ユーザーのログオン状態と手動操作によってスケジュールが崩れてしまうためだ。具体的な更新プログラムの適用手順を、ケース分けして見てみよう。
自動更新処理の第1段階――更新プログラムのチェック
自動更新は、前回のスケジュール日時以降にインストールを承認された更新プログラムをチェックするために、定期的にWSUSサーバにアクセスして確認している。既定の確認タイミングは「PCの起動時」または「約22時間周期」の2つで、「自動更新の検出頻度」ポリシーを有効にすることで確認頻度を変更できる(画面3)。
画面3 「自動更新の検出頻度」ポリシーのプロパティ | ||||||
「自動更新の検出頻度」ポリシーのプロパティを開いてポリシーを有効にした上で、[更新を確認する時間]を1時間から22時間の範囲で設定する。 | ||||||
|
自動更新処理の第2段階――更新プログラムの適用
インストール可能な更新プログラムがあれば、実行ファイルをWSUSサーバからダウンロードして待機する。スケジュールされた日時までにダウンロードが完了していなければ、当然ながら適用不能だ。
ケース1:スケジュールされた日時に誰もログオンしていない場合
クライアントPCに誰もログオンしていない場合は、スケジュールされた日時が到来すると、問題なくスケジュール適用が実行される。適用完了の条件としてPCの再起動が必要な更新プログラムが含まれていれば、PCが自動的に再起動される。
ケース2:管理者ユーザーがログオンしているとき
「自動更新処理の第2段階――更新プログラムの適用」処理が完了してからスケジュールされた日時が到来するまでの間に、クライアントPCに管理者の権限を与えられたユーザーがログオンしていると、更新プログラム適用の通知メッセージがタスク・バーの通知領域に表示される(画面4)。
画面4 新しい更新プログラムが利用できるようになったことを表す通知メッセージ | |||
更新プログラムのダウンロードが完了したときに管理者ユーザーがログオンしていると、スケジュール日時を待たずに通知メッセージが表示される。 | |||
|
ここで、管理者ユーザーが通知に従ってすぐに更新プログラムの適用を開始すると、自動適用のスケジュールは完全に無視されることになる。さらに、更新プログラムの適用後に「コンピュータを再起動してください」というダイアログが表示されたとき、管理者ユーザーが「今すぐ再起動」ボタンをクリックすると、再起動のスケジュールも無視される(画面5)。
画面5 コンピュータの再起動を促すダイアログ | ||||||||||||
再起動が必要な更新プログラムを手動で適用すると、再起動の確認ダイアログが表示される。管理者ユーザーは即時再起動や再起動の延長を選択できる。 | ||||||||||||
|
従って、管理者ユーザーがログオンしていても、本来のスケジュール日時に更新プログラムを自動適用したければ、管理者ユーザーは通知メッセージを無視してスケジュール日時まで適用を我慢する必要がある。
ケース3:非管理者ユーザーがログオンしているとき
非管理者ユーザーがログオンしている場合は、ケース2と異なり、更新プログラム適用の通知メッセージは表示されないので、更新プログラムはスケジュールどおりに適用される。更新プログラムの適用後に再起動が必要であれば、再起動の確認ダイアログが表示されるが、[今すぐ再起動]ボタンしかクリックできないので、非管理者ユーザーが再起動を先延ばしすることはできない。
このように、スケジュール適用が失敗するのは、クライアントPCにインストール可能な更新プログラムがないか、管理者ユーザーがログオンしていて手動で更新プログラムの適用と再起動を実行した場合である。しかしながら、次の2つのポリシーが1つ以上有効に設定されていると、例外的に非管理者ユーザーがログオンしている場合もスケジュール適用が失敗する可能性が出てくるので要注意だ。もっとも、これら2つのポリシーを活用すれば、不当に高い権限をユーザーに与える必要がなくなるので、かえって安全性が高まるともいえる。
■例外1:「非管理者による更新の通知の受信を許可する」ポリシーが有効な場合
このポリシーを有効にすると、非管理者ユーザーがログオンしていてもケース2とまったく同じ動作になる。つまり、一般ユーザーも通知メッセージを受信できるようになり、更新プログラムの手動適用と手動再起動、そして再起動延長の操作が可能になる。
■例外2:「ログオンしているユーザーがいる場合はスケジュールされた自動更新のインストールに対してシステムを自動的に再起動しない」ポリシーが有効な場合
このポリシーを有効にすると、ケース3において再起動の確認ダイアログが表示されたとき、[後で再起動]ボタンもクリック可能になる。つまり、更新プログラムはスケジュールどおりに適用されるが、再起動のタイミングは任意に延長できる。
運用 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|