Windowsのログオン時に実行されるはずのタスクが実行されない謎、答えは至極単純だった：山市良のうぃんどうず日記（261）

おそらく、多くのWindowsデバイスにインストールされている「Adobe Acrobat Reader」、その自動更新機能がどうなっているのか確認してみたところ、メインで使用しているデスクトップPCだけ、自動更新のためのタスク実行履歴に疑問を持ちました。その理由はとても単純なことであり、正常に機能していたのですが、どういうオチなのか少し付き合ってください。

[山市良，テクニカルライター]

山市良のうぃんどうず日記

ストアアプリの自動更新機能のおさらい

　本連載第257回では、「モダンアプリ」や「ストアアプリ」とも呼ばれる「ユニバーサルWindowsプラットフォーム（UWP）アプリ」の自動更新について触れました。

• 月例更新なんてカワイイもの、アプリの更新も忘れずに！――Microsoft製品の“更新”にまつわるエトセトラ（本連載 第257回）

　UWPアプリの自動更新は、「タスクスケジューラ」の「\Microsoft\Windows\InstallService」にある「ScanForUpdates」タスクによって行われ、少なくとも1日（8万6400秒）に1回、更新プログラムがないかどうかチェックされて、存在する場合はキューに入れられ、その後のタスク実行時に自動的にダウンロードとインストールが行われます。このタスクは1時間ごとに無期限に繰り返し実行されますが、利用可能なアプリの更新のスキャンが1日に1回だけ行われることは、イベントログから分かります（画面1）。

画面1　UWPアプリの利用可能な更新のスキャンは、少なくとも1日（8万6400秒）に1回行われる

　多くのWindowsデバイスにインストールされているデスクトップアプリケーション（UWPアプリではなく、Win32アプリ）の一つに「Adobe Acrobat Reader」があります。UWPアプリもそうなのですが、筆者は自動更新機能が備わっていたとしても、更新バージョンが利用可能になったと分かった時点ですぐに手動で更新します。そのため、あまり気にしていなかったのですが、UWPアプリの自動更新について調べたのをきっかけに、Adobe Acrobat Readerの自動更新はどのように制御されているのだろうと思いました。

　Adobe Acrobat Readerに自動更新機能が備わっていて、既定で「有効」になっていることは、経験上知っています。試しに、2023年1月に製品サポートが終了して以来、起動していない「Windows 8.1」の仮想マシンを久しぶりに起動してみたところ、ログオンして30分後には、インストールされていたAdobe Acrobat Readerが新しいバージョンに更新されていました（画面2）。

画面2　2023年1月に製品サポートが終了したWindows 8.1の仮想マシンを数カ月ぶりに起動すると、ログオンして30分後にはAdobe Acrobat Readerが更新されていることを確認できた

Adobe Acrobat Readerの自動更新は「Adobe Acrobat Update Task」タスクが制御

　画面2で見たように、ログオン後にしばらくして自動更新されたことから、ユーザーのログオン時をトリガーとした「タスクスケジューラ」のタスクで自動更新が制御されていることは容易に想像できます。

　「タスクスケジューラ」を開いてみると、「タスクスケジューラライブラリ」のルートに分かりやすい名前の「Adobe Acrobat Update Task」がすぐに見つかりました。このタスクでは、ユーザーのログオン時にトリガーされ、その後、3時間30分ごとに無期限に繰り返される「ログオン時」トリガーと、毎日18時に起動する「毎日」トリガーが自動実行されるようになっています（画面3）。

画面3　Adobe Acrobat Readerの自動更新タスクは、更新バージョンが利用可能かどうかに関係なく、ログオン時とその後3時間30分ごとに繰り返されている

　画面3のデバイスは、前日（2023年6月7日）に手動でAdobe Acrobat Readerを最新バージョンに更新し、明朝6時ごろ電源をオンにしたものです。次回の実行時刻は「毎日」トリガーの次のタイミングになっていますが、前回の実行時刻はログオン時とその3時間30分後に実行された時刻のと矛盾しません。

　以下の画面4を見てください。画面3はサブで使用しているノートPC（OSはWindows 10 Pro x64）のものでした。画面4はメインで使用しているデスクトップPC（OSはWindows 11 Pro）のものです。こちらも毎日朝6時ごろに電源をオンにして使用を開始しているのですが、前回の実行時刻は「1991/11/30 0:00:00」となっており、「ログオン時」タスクが一度も実行された様子がありません。

画面4　「ログオン時」タスクが一度も実行された様子がない

　最初はどういうことか分からず、何かシステムがおかしいのではないかと疑ったのですが、このデバイスではタスクの履歴を有効にしていたため、すぐに疑いの一つが晴れました。このデバイスも前日に手動でAdobe Acrobat Readerを更新したのですが、更新時に「Adobe Acrobat Update Task」タスクが一度削除され、再登録されているのが分かります。そのため、過去に一度も実行されたことがないというわけではありません（画面5）。

画面5　「Adobe Acrobat Update Task」タスクは更新時に削除／再登録される

　もう1つ疑問があります。「ログオン時」トリガーはなぜ発動していないのでしょうか。こちらもすぐに答えが出ました。

　筆者はメインのPCを、Windows Updateのときやトラブル時以外の日常は、毎日休止状態にして電源を完全にオフにし、翌朝電源をオンにして再開するという使い方をしています。前回、Adobe Acrobat Readerを更新したときから、一度もログオンしない（ログオフしない）で作業を継続しているため、前回のログオン後に再登録されたタスクの「ログオン時」トリガーは一度も実行されていないのです。「ログオン時」タスクがトリガーされなければ、その後の3時間30分ごとの繰り返し実行も行われることはありません。一方のサブのノートPCは、毎日シャットダウンして電源をオフにしています。

　以前、本連載で、休止状態やスリープ、高速スタートアップは、システム稼働時間に影響しない（停止している間も動いている計算になる）ことを説明したことがあります。

• 今使っているPC、電源ボタンを押して起動したのは何時だったっけ？（本連載 第150回）

　その時に紹介した以下のコマンドラインをWindows PowerShell（powershell.exe）やPowerShell（pwsh.exe）で実行することで、過去24時間に行われたシャットダウンやスリープ／休止状態、OSの起動、システム稼働時間に関連するイベントを参照できます。

Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Kernel-Boot' or @Name='Microsoft-Windows-Kernel-General' or @Name='Microsoft-Windows-Kernel-Power'] and (EventID=1 or EventID=12 or EventID=13 or EventID=20 or EventID=42 or EventID=107 or EventID=109) and TimeCreated[timediff(@SystemTime) <= 86400000]]]"

　現在、ログオン中のユーザーがローカルアカウントである場合、いつログオンしたのかは、PowerShell（PowerShell.exeまたはpwsh.exe）の場合は、「findstr /C:"最終ログオン日時"」ではなく、「Select-String "最終ログオン日時"」のように入力してください。

net user <ローカルユーザー名> | findstr /C:"最終ログオン日時"

　しかし、MicrosoftアカウントやAzure Active Directory（Azure AD*1）の組織アカウントでローカルログオンした場合は、上記のコマンドの最終ログオン日時は更新されません（リモートデスクトップ接続の場合は更新されます）。MicrosoftアカウントやAzure ADの組織アカウントに切り替える前の最後のローカルログオン、または最後のリモートデスクトップ接続経由のログオン（Pro以上のエディションの場合）の日時のいずれかが返ってくるでしょう。

（*1）Microsoftは2023年7月11日（米国時間）、Azure Active Directory（Azure AD）の名称を「Microsoft Entra ID」に変更することを発表しました。この名称変更は、2023年7月11日から30日間の通知期間を経て、Microsoftのエクスペリエンス全体に反映され始め、SKU（Stock Keeping Unit）とサービスプランの表示名は2023年10月1日に変更されます。ほとんどの作業は、2023年末までに完了する予定です。

• New name for Azure Active Directory［英語］（Microsoft Learn）

　例えば、Windowsのセットアップ時にMicrosoftアカウントでセットアップし、一度もローカルアカウントとしてログオンしていない場合は、「最終ログオン日時 なし」が返ってくるはずです（画面6）。また、Active Directoryドメインユーザーの場合も「net user」コマンドは役に立ちません。「Get-ADUser」コマンドレットなどでActive DirectoryからユーザーのLastLogonDate属性を取得する必要があります。しかし、その場合でも、キャッシュログオンが行われた場合、ドメインコントローラー側で最終ログオン日時は記録されません。

画面6　MicrosoftアカウントでセットアップしたWindows 10 Homeエディションでのnet userコマンドの実行結果。最終ログオン日時は「なし」

　ログオンの方法（ローカルログオンまたはリモートデスクトップ接続）やアカウントの種類に関係なく、現在のログオンセッションの開始日時を取得するには、以下のコマンドを実行します。「quser」はもともと、リモートデスクトップサービスにログオンしているユーザーを確認するコマンドですが、コンソール（Console）セッションにログオンしているユーザーの情報も知ることができます。

quserまたはquery user

　ただし、このコマンドはHomeエディションでは利用できません（存在しません）。代替として、以下のPowerShellコマンドラインを実行することで、イベントログから直近のログオンイベントの日時を取得できます（画面7）。

$logons = Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Winlogon'] and (EventID=7001)]]"
$logons[0]

画面7　「ログオン時」トリガーが実行されなかったのは、このデバイスが休止状態から再開したもので、最後のログオンは3日前の6月5日早朝に行われたから。Microsoftアカウントでローカルログオンしている場合、「net user」コマンドの最終ログオン日時は実際の最終ログオン日時ではないことに注意

　このように、休止状態やスリープで利用している場合、ユーザーのログオンをトリガーとするタスクが長期間実行されない場合があります。ただし、通常、ログオンとは別のトリガーも用意されているため、タスクが実行される機会が減少しますが、全く実行されないということはないはずです。

　企業の場合、ドメイン参加デバイス（クライアントPCだけでなく仮想デスクトップなども）やドメインユーザーのスタートアップスクリプトやログオンスクリプト、シャットダウンスクリプトにも影響するかもしれません。ログオンスクリプトに何かを仕込んで、毎日自動実行されると期待しても、エンドユーザーのPCの使い方によっては何日も実行されない場合が出てくるでしょう。

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP 2008 to 2024（Cloud and Datacenter Management）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker＆Windowsコンテナーテクノロジ入門』（日経BP社）、『ITプロフェッショナル向けWindowsトラブル解決 コマンド＆テクニック集』（日経BP社）。