2月からダラダラと書いてきたこのシリーズですが、最後に小ネタを2つ紹介して終わります。
＜１＞
技術的な裏付けの無い経験則となりますが、.NET Framework の更新プログラムは他の更新プログラムよりも「一度に複数適用しようとして失敗する確率」が高いようです。
「１つ適用して、再起動」を繰り返すほうが、結果的に時間を短縮できるかもしれません。
＜２＞
更新プログラムは、いつのまにかバージョンアップされて「v2」や「v3」になっていることがあります。
たとえば、「KB982018」がそうです。
インストーラーファイルをダウンロードセンターから入手すると、ファイル名に「v3」が含まれています。
決して多くはないと思いますが、ダウンロードしたインストーラー(.msuファイル)に破損等の問題があるために適用できないことも、あるかもしれません。
適用できるはずの更新プログラムがどうしても適用できない場合、最後の最後にはそれを疑います。
もしかしたら、改めてダウンロードし直したらすんなり適用できるかもしれません。
そんな場合は、最初にダウンロードしたインストーラーは破損していたのかもしれません。
更新プログラムの中には、以前発行された別の更新プログラムを「置き換える」ものがあります。
新しい方の更新プログラムがすでに適用済みの状態であれば、置き換えられた古い更新プログラムを適用しようとしても失敗します。
（そもそも適用する必要がありません。）
Windowsの更新にWindows Updateを用いるのであれば、自動的に「このOSに適用可能な更新プログラム」だけを適用してくれます。
しかし、自分でインストーラー（.msuファイル）をダウンロードする場合には注意が必要です。
適切なインストーラーを選び、前提条件を満たした状態で適用しなければ、失敗して当然だからです。
サポートセンターに問い合わせが入る Windows のトラブルは多様ですが、そのなかでも比較的多い問い合わせの一つに「更新プログラムの適用に失敗する。」というものがあります。
考えられる原因はいくつかあるのですが、一度に多くの更新プログラムを適用しようとすると、トラブルになりやすいように思います。
久しぶりに「Windows Update」を行う場合や、更新プログラムのインストーラー（.msuファイル）を多数まとめて実行する場合などです。
（個人宅のPCでは前者が、業務用のPCやサーバーでは後者が多いのではないでしょうか。）
環境については、＜ログオン編＞と同じです。
ユーザーがログオフした際には、[ID:23] というイベント（情報）が記録されました。
[G] ローカルでログオフした場合
リモートデスクトップ サービス: セッション ログオフに成功しました。
ユーザー: TEST¥user001
セッションID: X
[H] リモートデスクトップでログオフした場合
上記[G]と全く同じです。 [ID:21]と違い、「ソースネットワークアドレス」として IP アドレスが記載されないので、リモートでログオンしていたのかどうかは判別できません。
ログオフ時に記録されるイベントとしては、他に[ID:24]というイベント（情報）もあります。
こちらには、[ID:21]と同様に「ソースネットワークアドレス」が記載されるため、そのユーザーがローカルでログオンしていたのか、リモートデスクトップでログオンしていたのか、判別可能です。
しかし、ログオンしていたユーザーがそのコンピューター自体をシャットダウンないし再起動した場合は、[ID:23]は記録されても[ID:24]は記録されないので、注意が必要です。
おわり
ユーザーログオン時に「TerminalServices-LocalSessionManager」の「Operational」にどのようなイベントが記録されるのかを実際に確認してみた結果、Windows Server 2008 R2 Standard(RTM版)とWindows 10 Enterprise Technical Preview(ビルド9926)で共通して、 [ID:21] というイベント（情報）が記録されました。
どちらのOSの場合も、ログオンするコンピューターは、Active Directory ドメイン「test.domain」に参加しています。
そこに、ドメインユーザー「User001」としてログオンした場合の[ID:21]の内容は以下のようになります。
※セッションIDの数値は変動するものなので、Xとしておきました。
※[C],[D],[E]のように他のコンピューターからリモートでアクセスする場合は、同一セグメント内にあるWindows Vista Enterprise SP2 （IPアドレス：aaa.bbb.ccc.ddd）からアクセスしています。
[A] ローカルでログオンした場合
リモートデスクトップ サービス: セッション ログオンに成功しました。
ユーザー: TEST¥user001
セッションID: X
ソースネットワークアドレス: ローカル
[B] ローカルでキャッシュログオンした場合
上記[A]と全く同じです。
つまり、キャッシュログオンか否かは判別できません。
[C] リモートデスクトップでログオンした場合
リモートデスクトップ サービス: セッション ログオンに成功しました。
ユーザー: TEST¥user001
セッションID: X
ソースネットワークアドレス: aaa.bbb.ccc.ddd
[D] リモートデスクトップでキャッシュログオンした場合
上記[C]と全く同じです。
つまり、キャッシュログオンか否かは判別できません。
[E] エクスプローラーで C$ （管理共有）へアクセスした場合
何も記録されません。
[F] タスクの実行ユーザーとしてログオンした場合
何も記録されません。
つづく
あるコンピューターにユーザーがログオン/ログオフした形跡を監視する場合、セキュリティログを確認することが一般的だと思います。
が、決してそれだけではありません。
監視の要件にもよりますが、他にも有用なログがあります。
Windows 7 や Windows Server 2008 R2 以降の OS に限られますが、「アプリケーションとサービス ログ」の中のちょっと分かりにくい所にあります。
フォルダを「Microsoft」、「Windows」、「TerminalServices-LocalSessionManager」の順で開いていったところにある「Operational」というログです。
名前からすると、リモートデスクトップに関係するイベントしか記録されないように見えますが、実はローカルでログオンしたことも記録されます。
ただし、セキュリティログのID 4624のイベントに「ログオン タイプ: 3」として記録されるような、「ネットワーク経由でのログオン」の場合、この「Operational」には記録されません。
（ログオンの種類については、TechNetの「ログオン イベントの監査」に一覧が載っています。）
つづく
よくあるお問い合わせ「OS を再起動したところ、再起動前は実行されていなかったサービスが、再起動後に勝手に実行されている。これは問題ではないか。」をテーマに続けてきた [ サービスの「状態」比較 ] シリーズは、今回で最後となります。
今回取り上げるのは、第一回で少しだけ触れた、このお問い合わせに潜む問題点です。
問題点を一言で言うと、「サーバーの正常性確認というタスクを現場で実施している当人が、作業の意味をよく理解していない」という事に尽きます。
重要なサービスが起動しておらず、実際にサーバーとしての役割を果たせていなければ、紛れも無い障害事案です。
しかし多くの場合は何の問題も起きておらず、サービスの「スタートアップの種類」が「手動」であるが故の、たんなるタイミングの問題 (詳細は #2 参照) である場合がほとんどです。
この問題は、さらに A、B、C の要素に分解出来ます。
=====================================
[ A ] Windows における「サービス」の挙動についての知識不足。
他の OS を管理する部署から異動してきたばかりでたまたま知らなかっただけなのかもしれません。
が、Windows を管理する仕事においては、こういった知識がないと他にも色々と困る事が出てくると思います。
なぜか資格試験対策の本ではあまり触れられていないようなので、#3 で紹介したような情報源を利用して積極的に情報収集する必要があります。
=====================================
[ B ] 管理対象サーバーの正常性判断基準およびその手法が確立されていない
これは必ずしも個人の力量の問題ではなく、どちらかと言うと組織の管理上の問題です。
「サーバーを再起動した後には、正常性確認のためにサービスの状態を確認する」という手順が決まっているのでしょうが、その結果を解釈・判定する基準を策定していないのであればお粗末と言わざるを得ません。
=====================================
[ C ] お問い合わせ自体の矛盾
個人的にはこの点が一番気になります。
再起動前は問題無く稼働していたことを根拠にその時のサービスの状態を「正常」とし、それと違っている現在（再起動後）の状態を「異常」ではないかと考えてお問い合わせいただくことが多いのですが、これはまったく理に適っていません。
「問題無く稼働していたから正常」というロジックが正しいなら、再起動後も同じロジックに基づいて正常性を判断出来るはずです。
「表面的には問題無くとも、サービスの状態を細かくチェックしなければ見つけられないような潜在的な問題も存在し得る」ということを心配しているのかもしれませんが、その場合、再起動前が正常だった保証など無いことになります。
これまで潜在的な問題に気付かないまま運用してきたのだとしたらそれも問題ですが、その点を懸念してお問い合わせいただいたことは（私が知る限り）ありません。
おわり。