Задача в Планировщике работает вручную, но не запускается автоматически: что различается

Разделите три разных способа запуска

Сценарий работает из открытой консоли, но ночью ничего не происходит. Сначала выясните, что означает «вручную»: двойной щелчок по файлу, команда в терминале или кнопка «Выполнить» в самом Планировщике. Это три разных проверки. Кнопка Планировщика использует сохранённое действие и контекст задачи; запуск из вашей консоли — её собственное окружение.

Нужно различить отсутствие срабатывания, отказ запуска процесса и ошибку уже запущенного сценария. От этого зависит следующий шаг. Microsoft предлагает начать с истории задачи и проверки самого сценария, а не с переустановки службы. ^[1]

Сохраните задачу и посмотрите её историю

Откройте taskschd.msc, найдите задачу и экспортируйте её XML через правую панель. Это копия конфигурации, а не резервная копия пароля, сценария и рабочих файлов. Запишите поля «Время прошлого запуска», «Результат» и «Время следующего запуска».

Если вкладка «Журнал» пуста, включите журнал всех заданий и воспроизведите один запуск. Старые отсутствующие записи от этого не появятся. Дополнительный канал — Просмотр событий → Журналы приложений и служб → Microsoft → Windows → TaskScheduler → Operational. Сопоставляйте время и имя именно своей задачи. ^[1]

Get-ScheduledTaskInfo -TaskPath '\Automation\' -TaskName 'NightJob' |
  Format-List LastRunTime, LastTaskResult, NextRunTime, NumberOfMissedRuns

Если задача находится в корне библиотеки, TaskPath будет \. Справка Get-ScheduledTaskInfo описывает эти поля. Статус Running показывает, что запуск ещё считается выполняющимся; код 0x41301 соответствует работающей задаче. Код 0x1 обычно требует анализа завершившегося действия, а не означает одну универсальную ошибку Планировщика. ^{[2], [3]}

Проверьте триггер и условия отдельно от действия

Во вкладке «Триггеры» проверьте, включён ли нужный триггер, дату начала и окончания, повторение и часовой пояс. Во вкладках «Условия» и «Параметры» — питание от сети, простой, доступность сети, запуск после пропущенного времени и поведение при уже работающем экземпляре.

Если задача разрешена только от сети, опыт на батарее не воспроизводит ночной сценарий. Если предыдущий процесс не завершился, правило «не запускать новый экземпляр» может объяснить отсутствие второго запуска. Настройка пробуждения не включает полностью выключенный компьютер и зависит от поддержки платформы.

Для сравнения используйте копию задачи с безопасным диагностическим действием и ближайшим будущим временем. Сохраните исходные условия. Не включайте параллельные экземпляры задачи, которая пишет в одни файлы или обрабатывает одну базу, ради проверки расписания.

Особый случай — программа, рассчитанная на нажатия в видимом окне. Запуск «независимо от входа пользователя» создаёт другой, неинтерактивный контекст: нельзя ожидать, что браузер откроется в вашей обычной сессии и сценарий увидит нужные кнопки. Для такой автоматизации заранее выбирают интерактивную модель и её ограничения либо поддерживаемый фоновый интерфейс программы. Сам процесс в списке задач ещё не означает доступного рабочего стола. ^[6]

Укажите интерпретатор, аргументы и рабочую папку

Для PowerShell-сценария действие должно запускать нужный PowerShell, а не редактор ISE и не текстовый файл. Ниже пример для Windows PowerShell 5.1; PowerShell 7 использует отдельный установленный pwsh.exe. Проверьте точный путь своей версии. Рабочая папка — отдельное свойство действия, она не обязана совпадать с папкой сценария. ^{[4], [5]}

NoProfile позволяет не зависеть от интерактивного профиля, NonInteractive исключает ожидание диалога PowerShell. Но приложение, запущенное из сценария, всё ещё может ждать собственного окна. Для относительных путей внутри PowerShell удобно явно использовать $PSScriptRoot. Не добавляйте ExecutionPolicy Bypass автоматически: сначала определите действующую политику и разрешённый способ запуска.

Сравните учётную запись и тип входа

Во вкладке «Общие» посмотрите, от чьего имени работает задача и требуется ли существующий вход пользователя. Установка «с наивысшими правами» меняет уровень полномочий, но не подменяет пользователя и не делает доступными его сетевые диски.

Особенно важно условие «не сохранять пароль». Для S4U система не хранит пароль, а сетевой доступ и доступ к зашифрованным EFS-файлам отсутствуют. Интерактивный запуск под той же записью не воспроизводит такое ограничение. Если задаче нужен SMB-ресурс, выбирают согласованную модель учётной записи и доступа; локальная успешная проверка файла не доказывает доступ к NAS. ^[6]

Сетевую папку задавайте UNC-путём вроде \\NAS\Archive, а не буквой диска из Проводника. При этом у учётной записи должны быть права и рабочий способ аутентификации. Вписывать пароль в bat-файл или аргументы действия не требуется.

Запишите фактическое окружение безопасным пробным действием

Для копии задачи создайте папку C:\Automation\Logs и дайте выбранной записи право писать в неё. Сохраните следующий пример как C:\Automation\TaskProbe.ps1. Он только пишет диагностический журнал; исходную обработку данных не выполняет.

$ErrorActionPreference = 'Stop'
$Log = Join-Path $PSScriptRoot 'Logs\TaskProbe.txt'
try {
  @(
    (Get-Date).ToString('o')
    [Security.Principal.WindowsIdentity]::GetCurrent().Name
    "PowerShell: $($PSVersionTable.PSVersion)"
    "PSHOME: $PSHOME"
    "Working directory: $((Get-Location).Path)"
    "Script directory: $PSScriptRoot"
    "Input exists: $(Test-Path 'C:\Automation\Input')"
  ) | Set-Content -LiteralPath $Log -Encoding UTF8
  exit 0
}
catch {
  Write-Error $_ -ErrorAction Continue
  exit 1
}

Проверяйте время изменения журнала: старый файл не подтверждает новый запуск. Если запись невозможна, probe завершится с ошибкой; исправьте путь и права, прежде чем считать отсутствие файла доказательством несработавшего триггера. Не выводите всё окружение без отбора: в нём бывают токены и другие секреты.

Сравните журнал при запуске из консоли, кнопкой Планировщика и по триггеру. Разница в пользователе, PSHOME и рабочем каталоге обычно предметнее предположения «Windows не запускает скрипты».

Добавьте журнал и явный результат в настоящий сценарий

После успешного probe верните реальное действие и добавьте понятные отметки начала, конца и этапа отказа. Для PowerShell Microsoft предлагает транскрипт; помните, что он может записать секретные аргументы и вывод. Для внешней EXE-программы отдельно считывайте её код завершения: текст ошибки не всегда становится ошибкой PowerShell автоматически. ^{[1], [5]}

Результат 0 означает, что процесс сообщил об успешном завершении; он не доказывает, что внутри создан нужный архив или обработаны все файлы. В сценарии должна быть проверка результата работы. Ошибки не следует безусловно гасить и завершать exit 0.

Повторите запуск в исходное время и при исходных условиях, затем проверьте журнал и итоговые данные. Для поддержки сохраните XML, узкое окно событий, путь интерпретатора, контекст входа и журнал действия.

Если расписание требует NAS, отдельно проверьте момент доступности сети. Сразу после старта Windows соединение и аутентификация могут ещё не установиться. Разумнее предусмотреть ограниченное ожидание и понятный отказ в журнале, чем бесконечный цикл. Повтор задачи должен быть безопасен: сценарий должен отличать уже завершённую работу от новой, чтобы случайный повтор не дублировал результат.