「らじれこ」の予約録音に失敗してから、その原因がネットに接続してサイマル配信を取得する録音開始時刻がWindows Updateの更新プログラム確認開始時刻と重なったからではないかと推測し、Windows Update の更新確認時刻を望みの時刻に変更しようと試行錯誤してきたのだが、その試行錯誤が無意味だったかもしれないと思わせる情報に辿り着いた。
更新プログラムのスキャン
Windows Update のしくみ – Windows Deployment | Microsoft Docs
PC 上のWindows Update Orchestrator は、Microsoft Update サーバーまたは WSUS エンドポイントで、ランダムな間隔で新しい更新プログラムを確認します。 ランダム化により、Windows Update サーバーが同時に要求でオーバーロードされないようにします。 Update Orchestrator は、前回の更新プログラムが検索されてから追加された更新プログラムのみを検索し、更新プログラムを迅速かつ効率的に検索できるようにします。
要するに、皆が同じ時刻にアクセスしたら Windows Update サーバーが混雑して時間がかかったり、サーバーがダウンしたりするかもしれないから、特定の時刻に更新確認できない仕組みになっているということだろう。
実際、タスクスケジューラの UpdateOrchestrator を見たら、「Schedule Scan」の「次回の実行時刻」が 2022/6/14 7:20頃に確認した時は「2022/06/14 22:36:42」だったのに、10:23に再確認したら「2022/06/15 3:24:34」に変わったし、10:26に確認したら「2022/06/15 1:31:37」で、12:40頃に確認したら「2022/06/14 22:13:40」である。タスクスケジューラを起動するたびに変わってる。
そのランダムな範囲は、もしかしたら330分(5時間半)かもしれない。「Schedule Scan」のトリガー編集に「遅延時間を指定する(ランダム)」とある。これは「繰り返し間隔」の「22時間」の時刻に実行できなかった場合に改めて実行するまでの時刻をランダムに決めるという意味ではなく、最初から[22時間~22時間+330分]の範囲内でランダムに決まった時刻に実行するということだと思われる。ちなみに、「繰り返し間隔」の「22時間」は開始日時の「2019/01/01 12:00:00」から22時間ごとに(実際はその時刻に330分を足した時刻までのいつか)実行するということで、「前回の実行時刻から22時間」ということではないと思われる。
そして、実行プログラムの「usoclient.exe StartScan」はサービス設定のWindows Update を無効にしても無視して実行するらしい。実際、6/13 21:30からWindows Update を無効にして、6/14 5:00にバッチファイルで有効(手動(トリガー開始))にしたはずなのに、4:57にWindows Updateの更新確認が行われていた。スリープ解除が4:55だったので、その直後にWiFi接続が確認されてから実行されたのだろう。
推測ばかりで確証はないのだけど、とにかく、これまでの観察結果と新しく見つけたMicrosoftの公式情報から、Windows Update の更新プログラムを確認する時刻を指定することはできず、Update Orchestrator によってランダムに決められてしまうのではないかと推測した。
コメント