Задачи планировщика заданий Windows не запускаются или завершаются с 0x1 — диагностика причин и проектирование надёжного выполнения по расписанию

«Хочу, чтобы PowerShell-скрипт для агрегации запускался каждое утро в 6 часов». «Вручную скрипт работает, но стоит поставить его в планировщик заданий — перестаёт». Когда речь заходит об автоматизации бизнес-процессов, разговор почти всегда рано или поздно упирается именно в это.

В этом блоге мы уже писали целую серию статей про автоматизацию: автоматизация обслуживания логов, тестирование скриптов с помощью Pester, запуск PowerShell из C# и автоматизация бизнес-процессов с помощью Power Automate. Все эти статьи в конечном счёте исходят из того, что соответствующая задача будет запускаться по расписанию через планировщик заданий. Но сам планировщик заданий оказывается на удивление капризным механизмом: истории вроде «вручную работает, а по расписанию — нет» или «никто не заметил, что задача давно не выполняется» случаются постоянно.

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

1. Сначала выводы

• Большинство проблем с планировщиком заданий возникает не из-за самого скрипта, а из-за расхождения в понимании того, «от чьего имени и в какой сессии выполняется задача». Как только вы выбираете «Выполнять вне зависимости от того, вошёл ли пользователь в систему», проектируйте решение исходя из того, что оно работает в мире, отличном и от интерактивной сессии, и от окружения при входе в систему.¹
• Расследование ситуации «задача не запускается» начинается с вкладки «Журнал» (History) и журнала событий. Однако журнал задач по умолчанию отключён, поэтому перед вводом в эксплуатацию обязательно включите «Включить журнал всех задач».²
• Код 0x1 в поле «Результат последнего выполнения» — это не ошибка самого планировщика заданий, а означает, что запущенная программа сама вернула код завершения 1. Причина кроется в скрипте, поэтому сначала продумайте коды завершения и создайте собственный механизм ведения журнала.³
• Базовая форма вызова PowerShell-скрипта — -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "полный путь", а пути внутри скрипта следует строить от $PSScriptRoot. Именно здесь легко попасть в классическую ловушку: в поле «Начать в» (Start in (optional)) нельзя ставить кавычки.
• Чтобы избежать инцидента, когда задача незаметно перестаёт работать после смены пароля, нужно продумать учётную запись выполнения — провести инвентаризацию служебных учётных записей, а в доменной среде рассмотреть gMSA.⁴
• Контроль повторного запуска (по умолчанию — «Не запускать новый экземпляр»), ограничение времени выполнения (по умолчанию 3 дня) и условия электропитания (по умолчанию — только при питании от сети) — типичные настройки, которые незаметно остаются на значениях по умолчанию. Обязательно задавайте их явно при регистрации задачи.⁵

2. Устройство планировщика заданий — триггеры, действия, условия, параметры

Задача планировщика заданий состоит из четырёх основных элементов.

Задачу, созданную через графический интерфейс (taskschd.msc), можно экспортировать в XML. Если вы хотите вести определения задач в Git или развернуть одну и ту же задачу на нескольких машинах, рекомендуется описать её в виде кода — либо через экспорт в XML и schtasks /Create /XML, либо с помощью модуля PowerShell ScheduledTasks (New-ScheduledTaskAction / New-ScheduledTaskTrigger / New-ScheduledTaskSettingsSet / Register-ScheduledTask).⁵

$action   = New-ScheduledTaskAction -Execute 'pwsh.exe' `
    -Argument '-NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Jobs\Cleanup-Logs.ps1"' `
    -WorkingDirectory 'C:\Jobs'
$trigger  = New-ScheduledTaskTrigger -Daily -At '06:00'
# Условие электропитания по умолчанию: «запуск только при питании от сети, остановка при переходе на батарею».
# Если задание должно выполняться и на ноутбуках или полевых устройствах, разрешите это здесь явно
$settings = New-ScheduledTaskSettingsSet -StartWhenAvailable `
    -MultipleInstances IgnoreNew `
    -ExecutionTimeLimit (New-TimeSpan -Hours 2) `
    -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
# Получаем учётные данные через Get-Credential, чтобы пароль не отображался на экране
$cred = Get-Credential -UserName 'DOMAIN\svc-batch' -Message 'Учётные данные для учётной записи выполнения'
Register-ScheduledTask -TaskName 'KS-Cleanup-Logs' `
    -Action $action -Trigger $trigger -Settings $settings `
    -User $cred.UserName -Password $cred.GetNetworkCredential().Password

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

Для развёртывания на нескольких машинах хорошо зарекомендовал себя и другой способ — экспортировать созданную в GUI задачу в XML и распространить её через schtasks.

rem Экспортируем задачу, созданную на тестовой машине
schtasks /Query /TN "KS-Cleanup-Logs" /XML > KS-Cleanup-Logs.xml

rem Импортируем на каждой машине (учётная запись выполнения и пароль указываются при регистрации)
schtasks /Create /TN "KS-Cleanup-Logs" /XML KS-Cleanup-Logs.xml /RU DOMAIN\svc-batch /RP *

XML содержит все триггеры, условия и параметры, поэтому, поместив его в репозиторий, можно проводить ревью определений задач и отслеживать изменения по diff. И наоборот: если вручную регистрировать одну и ту же задачу через GUI на десяти машинах, рано или поздно обязательно появится «блудная задача» с настройками, отличающимися от остальных ровно на одной машине. Безопаснее перевести определение задачи в код ещё до того, как число машин перевалит за два знака.

Отметим, что материал этой статьи рассчитан на планировщик заданий (линейку Task Scheduler 2.0) в Windows 10/11 и Windows Server 2016 и новее. Если в вашей среде остались задачи, унаследованные от старой команды at, начните с их инвентаризации.

3. Учётная запись выполнения и тип входа в систему — главный источник инцидентов

Параметры в свойствах задачи — «Выполнять только для вошедших в систему пользователей» и «Выполнять вне зависимости от того, вошёл ли пользователь в систему» — на внутреннем уровне представляют собой выбор типа входа в систему (LogonType). Если понимание этого расходится с реальностью, вы будете блуждать в потёмках, не в силах объяснить большинство случаев «вручную работает, а по расписанию — нет».¹

3.1 Различия между тремя режимами

Вот типичные инциденты, встречающиеся на практике.

• Скрипт, обращающийся к общей папке, зарегистрировали с параметром «Не хранить пароль» (S4U). В локальном тестировании всё работало, а в продакшне отказывал именно доступ к общей папке. Причина в том, что у S4U нет сетевых учётных данных.
• Задачу зарегистрировали с параметром «Выполнять вне зависимости от того, вошёл ли пользователь в систему», а через несколько месяцев истёк срок действия доменного пароля и его сменили. С этого момента задача постоянно завершалась ошибкой входа (0x8007052E), но никто этого не заметил.
• Задачу для запуска GUI-приложения зарегистрировали с параметром «выполнять вне зависимости». Приложение фактически запускалось, но его окно нигде не отображалось, и это ошибочно приняли за «не работает». Причина в том, что задача выполняется в неинтерактивной сессии — обработка, требующая интерактивного экрана, в такой конфигурации в принципе работать не может.

Кроме того, учётной записи, работающей в режиме Password или S4U, требуется право «Вход в качестве пакетного задания» (SeBatchLogonRight). Группе Administrators оно предоставлено по умолчанию, но если вы делаете служебной учётную запись отдельного обычного пользователя, проверьте и настройки локальной политики безопасности.⁶

3.2 Под какой учётной записью запускать

• SYSTEM: не требует управления паролем и обладает мощными правами, но эти права слишком широки. Она удобна для локальных обслуживающих задач, но задачи, работающие с бизнес-данными, не стоит бездумно запускать от SYSTEM. О том, как определить, действительно ли нужны права администратора, мы писали в отдельной статье «Когда Windows-приложению на самом деле нужны права администратора».
• Выделенная служебная учётная запись (обычный пользователь): позволяет применить принцип наименьших привилегий, но требует обновлять задачу при каждой смене пароля. Управляйте сроком действия пароля и инвентаризацией задач как единым процессом.
• gMSA (групповая управляемая служебная учётная запись): первый кандидат в доменной среде. Пароль автоматически управляется контроллером домена, поэтому сама проблема «задача умирает при смене пароля» исчезает. Планировщик заданий поддерживает выполнение от имени gMSA.⁴

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

4. Порядок диагностики ситуации «задача не запускается»

4.1 Сначала включите журнал, потом ищите причину

Пункт «Включить журнал всех задач» на правой панели планировщика заданий по умолчанию отключён. Пока журнал отключён, в записях не сохраняется даже сам факт сбоя. Обязательно включите его перед вводом в эксплуатацию и настройте возможность проверки вместе с журналом событий (Просмотр событий → Журналы приложений и служб → Microsoft → Windows → TaskScheduler → Operational).²

Базовая процедура диагностики прекрасно работает, если просто следовать порядку из официального руководства Microsoft по устранению неполадок.²

1. Протестировать скрипт отдельно — прежде чем помещать его в задачу, убедиться, что сам скрипт полностью отрабатывает в условиях, эквивалентных учётной записи выполнения (по возможности через runas или на тестовой машине).
2. Посмотреть столбец состояния и вкладку журнала — понять, была ли задача вообще запущена триггером, или запустилась, но завершилась сбоем. Если триггер не сработал — проверить настройки триггера и условия (питание, сеть), а также убедиться, что само действие работает при ручном запуске (правой кнопкой → «Выполнить»).
3. Временно переключить на «Выполнять только для вошедших в систему пользователей» — если после этого всё заработало, причину можно сузить до неинтерактивной сессии или учётных данных (см. предыдущую главу).

4.2 Как читать «Результат последнего выполнения»

Коды семейства 0x413xx — это коды состояния самого планировщика заданий, 0x8007xxxx — коды ошибок Windows, а небольшие значения вроде 0x1 или 0x2 — это коды завершения самой запущенной программы.³ Если различать их с самого начала, вы не будете искать причину не там, где нужно (в настройках задачи или в скрипте).

4.3 Обратите внимание на значения условий и параметров по умолчанию

• Условие электропитания: по умолчанию включён параметр «Запускать задачу только при питании компьютера от электросети». Если в качестве тестовой машины используется ноутбук, вы получите «невоспроизводимый баг», который проявляется только при работе от батареи. Кроме того, начиная с Windows 10, пока активен режим энергосбережения батареи, срабатывание триггеров многих задач откладывается.⁷
• Пропущенное время запуска: если компьютер был выключен и запланированное время прошло, по умолчанию задача не выполнится до следующего запланированного момента. Либо явно включите «Немедленно выполнить задачу, если пропущен плановый запуск» (-StartWhenAvailable), либо заранее решите на уровне проектирования, допустимо ли для этой задачи быть пропущенной.
• Выход из спящего режима: для ночных заданий на компьютере, который может уходить в спящий режим, также решите, нужен ли параметр «Выводить компьютер из спящего режима для выполнения задачи» (-WakeToRun).

4.4 Внимание к самому проектированию триггеров

Бывает и так, что то, что кажется «задача не запускается», на самом деле — расхождение между замыслом и фактическим устройством триггера.

• Триггер «каждое 31-е число месяца» не срабатывает в месяцах, где нет 31-го дня. Для обработки конца месяца безопаснее проектировать под фактический замысел «последний день месяца» — например, обрабатывать данные предыдущего месяца в начале нового или проверять дату непосредственно в скрипте.
• Время задаётся в местном часовом поясе машины, на которой зарегистрирована задача. Если раздать один и тот же XML на машины в зарубежных офисах или, изредка, на сервер, настроенный на UTC, время выполнения будет расходиться от площадки к площадке. Заранее зафиксируйте в требованиях, что имеется в виду — «6 утра по японскому времени везде» или «6 утра по местному времени на каждой площадке».
• Стоит насторожиться, если вы начинаете использовать планировщик заданий для коротких повторяющихся интервалов (например, каждые 5 минут). Как инструмент для «пакетной обработки раз в сутки» он превосходен, но как только требуется поминутный опрос или непрерывный мониторинг — это уже область резидентного процесса (см. главу 8 ниже).
• Триггеры по событиям мощны, но сначала убедитесь, что целевое событие действительно стабильно фиксируется в журнале. Конфигурация, запускающаяся по конкретному ID события в журнале приложений, может незаметно перестать работать, если обновление приложения изменит порядок генерации событий. Триггер по времени в сочетании с проверкой условий внутри скрипта зачастую в итоге легче отслеживать.

5. Типичные причины завершения с кодом 0x1 и правильный вызов PowerShell

0x1 — это лишь результат, говорящий о том, что скрипт завершился неудачей; сама причина кроется в различиях среды выполнения скрипта. Между ручным запуском и запуском по расписанию различаются в основном следующие моменты.

• Отличается текущий каталог: если не указать «Начать в», задача выполняется, например, из C:\Windows\System32. Скрипты с относительными путями ломаются именно на этом. В скрипте стройте пути от $PSScriptRoot, а в задаче укажите рабочую папку в поле «Начать в». При этом в поле «Начать в» нельзя ставить кавычки — путь пишется без кавычек даже если содержит пробелы (иначе задача завершится с 0x8007010B).
• Отличаются переменные окружения и профиль: считайте, что переменные окружения, задаваемые сценариями входа или пользовательским профилем, а также подключённые сетевые диски (например, X:) в неинтерактивной сессии просто не существуют. Используйте напрямую UNC-пути (\\server\share\...), а параметр -NoProfile устраняет различия, связанные с профилем.
• Отличается политика выполнения: даже если у пользователя настроена политика RemoteSigned, у служебной учётной записи она может быть не задана. Явно указывайте -ExecutionPolicy Bypass в аргументах задачи.
• У отдельных утилит нестандартные соглашения о кодах завершения: например, robocopy возвращает 1, когда «были файлы для копирования, и они были успешно скопированы». Обёртка, напрямую пробрасывающая код завершения, может показывать 0x1 при полностью нормальной работе — или наоборот. Обязательно проверяйте соглашение о кодах завершения для каждой используемой внешней команды.

Базовая форма вызова PowerShell выглядит так.

Программа/скрипт:     pwsh.exe          (для Windows PowerShell — powershell.exe)
Добавить аргументы:   -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Jobs\Cleanup-Logs.ps1"
Начать в (необязательно): C:\Jobs           (без кавычек)

-File вместо -Command используется не только потому, что экранирование аргументов становится проще, но и потому, что exit n внутри скрипта напрямую становится кодом завершения процесса, а значит, успех или неудачу можно определить по «Результату последнего выполнения» в планировщике заданий. Проектируйте и сам скрипт так, чтобы он явно возвращал 0 при успехе и ненулевое значение при неудаче.

# Устанавливаем Stop, чтобы даже "неостанавливающие ошибки" командлетов попадали в catch.
# Без этого, например, сбой Copy-Item может пройти незамеченным и завершиться с exit 0
$ErrorActionPreference = 'Stop'

try {
    Main
    exit 0
}
catch {
    Write-Error $_
    exit 1
}

Подробнее о том, где перехватывать исключения и как их фиксировать, мы писали в отдельной статье «Перехват исключений и проектирование журналирования».

6. Ведите журнал самостоятельно

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

Как минимум, вместо перенаправления вывода через аргументы задачи (синтаксис перенаправления в поле «Аргументы» планировщика заданий не работает, поскольку выполняется не через оболочку) проще всего вести транскрипт непосредственно внутри скрипта.

$logDir = 'C:\Jobs\logs'
New-Item -ItemType Directory -Path $logDir -Force | Out-Null
Start-Transcript -Path (Join-Path $logDir ("cleanup-{0:yyyyMMdd}.log" -f (Get-Date))) -Append
try {
    # основная обработка
}
finally {
    Stop-Transcript
}

Решение проблемы накопления самих логов (управление поколениями, архивирование) напрямую описано в статье «Продвинутое использование PowerShell-скриптов — безопасная автоматизация анализа, архивирования и отчётности логов» — материал оттуда применим без изменений.

Если хотите пойти дальше, рассмотрите запись в журнал событий Windows. В отличие от файлового журнала, преимущество в том, что информация об успехе или неудаче попадает туда, куда эксплуатация и так уже смотрит (Просмотр событий, существующие средства мониторинга).

# --- Выполняется один раз при установке, с правами администратора (в установщике или скрипте первоначальной настройки) ---
if (-not [System.Diagnostics.EventLog]::SourceExists('KS-Jobs')) {
    [System.Diagnostics.EventLog]::CreateEventSource('KS-Jobs', 'Application')
}

# --- Тело задания (выполняется под учётной записью с минимальными правами) только записывает.
#     SourceExists может потребовать прав администратора для поиска по всем журналам, поэтому не вызывайте его во время выполнения.
#     Предполагается, что блок ниже вызывается внутри обработчика сбоя (catch) функции Main ---
catch {
    $err = $_
    try {
        [System.Diagnostics.EventLog]::WriteEntry('KS-Jobs',
            "Cleanup-Logs failed: $($err.Exception.Message)",
            [System.Diagnostics.EventLogEntryType]::Error, 1001)
    }
    catch {
        # Не позволяйте невозможности записи в журнал скрыть исходную ошибку
        Write-Warning "Не удалось записать в журнал событий: $_"
    }
    exit 1
}

Дадим два уточнения. Во-первых, для регистрации источника событий (CreateEventSource) требуются права администратора. Если смешать регистрацию с телом задания, то при первом же сбое в продакшне, где задание выполняется под учётной записью с минимальными правами, вы получите двойной сбой: попытка регистрации выбрасывает исключение, и в результате не записывается само нужное событие. Как показано выше, выносите регистрацию на сторону установки, а во время выполнения ограничивайтесь только записью. Во-вторых, если, как в примерах регистрации задач из этой статьи, в качестве движка выполнения используется pwsh.exe, командлеты New-EventLog / Write-EventLog времён Windows PowerShell 5.1 недоступны (команда не найдена, и скрипт целиком завершается сбоем). А вызов классов .NET напрямую, как показано выше, работает как в 5.1, так и в 7.

Помимо этого, добавление механизма, который «доносит информацию о сбое до человека», — уведомления по почте или в Teams/Slack — позволяет избежать инцидента, когда о нескольких месяцах простоя узнают только при инвентаризации. Сложная инфраструктура уведомлений не нужна: достаточно нескольких строк, отправляющих POST-запрос на webhook только при сбое. Уведомления при каждом успехе, наоборот, рано или поздно перестают читать, поэтому успешные запуски лучше сводить к еженедельной сводке, а объектами обнаружения делать сбои и «не выполнилось» (устаревшее время последнего запуска). Критерии того, что стоит писать в журнал, мы также разбирали в статье «Перехват исключений и проектирование журналирования».

7. Контроль повторного запуска и длительного выполнения

Что произойдёт, если предыдущий запуск ещё не завершился, а уже настало время следующего по расписанию? Это определяется настройкой «Правило, применяемое, если задача уже выполняется» на вкладке параметров, которой в PowerShell соответствует -MultipleInstances.⁵

Заодно установите «Время до остановки» (-ExecutionTimeLimit, по умолчанию 3 дня) в реалистичное значение (примерно в 2–3 раза больше ожидаемого времени выполнения) — это убережёт от ситуации, когда зависший процесс тянет за собой ещё и задание следующего дня.⁵

Стоит учитывать, что IgnoreNew и Queue защищают только в пределах одного и того же определения задачи. Они не предотвращают конфликт, если одну и ту же задачу вызывает другая задача или если во время устранения инцидента кто-то запускает её вручную. Если к одному и тому же ресурсу (файлу, БД, внешней системе) ведёт несколько путей, взаимное исключение нужно реализовать и на стороне скрипта. Стандартный приём — именованный мьютекс.

$mutex = New-Object System.Threading.Mutex($false, 'Global\KS-Cleanup-Logs')
if (-not $mutex.WaitOne(0)) {
    Write-Warning 'Завершение работы, так как уже выполняется другой экземпляр.'
    exit 0   # используйте 0, если "не выполнилось" не должно считаться сбоем, и ненулевое значение — если должно
}
try {
    # основная обработка
}
finally {
    $mutex.ReleaseMutex()
}

Если добавить в начало имени Global\, взаимное исключение будет работать и между разными сессиями (например, между задачей другого пользователя и ручным запуском). Ждать ли захвата блокировки (передавая тайм-аут в WaitOne) или сразу отступать — решайте исходя из характера задания. Обратите внимание, что именованный объект с префиксом Global\ виден любому на машине. На общем сервере, куда входят несколько пользователей, если по злому умыслу или случайно одноимённый мьютекс перехватят первым, задание может пропускаться вечно (причём при exit 0 это будет выглядеть как нормальная работа). В такой среде либо настройте ACL мьютекса (MutexSecurity), ограничив круг учётных записей, которые могут его захватывать, либо как минимум фиксируйте факт «не удалось захватить, пропущено» в уведомлениях и журнале событий из предыдущего раздела, чтобы мониторинг мог заметить серию пропусков. Взаимное исключение при взаимодействии через файлы подробно рассмотрено в статье «Лучшие практики интеграции через файлы и блокировки».

8. Когда пора отказаться от планировщика заданий — разграничение с резидентными службами

Планировщик заданий не универсален. По мере роста требований наступает момент, когда лучше перейти на другой механизм, чем продолжать насильно использовать текущий.

Как только вы начинаете опрос через «задачу каждые 5 минут», каждый запуск обходится в затраты на создание процесса и загрузку модулей, к тому же требуется механизм сохранения предыдущего состояния, например, в файл, — по сути, вы заново по кускам реализуете резидентный процесс. На этом этапе логичнее сделать процесс резидентным с помощью Generic Host и BackgroundService из .NET. Паттерн реализации разобран в статье «Использование Generic Host и BackgroundService в десктопном приложении».

И наоборот, специально превращать ежемесячную или ежедневную пакетную обработку в службу с собственным управлением таймером — тоже избыточно. Граница, которая почти всегда верна: если «интервал выполнения от часа и более, обработка независима и не хранит состояние» — используйте планировщик заданий, а как только начинаете выходить за эти рамки — рассматривайте переход на резидентный процесс.

9. Чек-лист перед вводом в эксплуатацию

Перед регистрацией задачи рекомендуется один раз пройтись по следующим пунктам.

• Определена ли учётная запись выполнения (не выбран ли SYSTEM по инерции? В домене рассмотрен ли gMSA?)
• Понятны ли ограничения выбранного типа входа (при S4U нет сетевого доступа; при Password — определён ли порядок действий при смене пароля?)
• Протестирован ли скрипт отдельно в условиях, эквивалентных учётной записи выполнения?
• Вызывается ли скрипт в форме -NoProfile -NonInteractive -ExecutionPolicy Bypass -File?
• Построены ли пути внутри скрипта от $PSScriptRoot / UNC (нет ли зависимости от подключённых дисков или относительных путей)?
• Не добавлены ли кавычки в поле «Начать в»?
• Продуманы ли коды завершения (0 — успех / ненулевое — неудача; проверены ли соглашения о кодах завершения внешних команд)?
• Включён ли журнал задач? Есть ли собственный журнал скрипта и уведомления о сбоях?
• Явно ли настроены условие электропитания, StartWhenAvailable, повторный запуск и ограничение времени выполнения?
• Сохранено ли определение задачи в репозитории в виде XML или PowerShell-скрипта?

10. Заключение

Работа с планировщиком заданий не заканчивается написанием скрипта: стабильная эксплуатация начинается только после того, как продуманы три предпосылки — учётная запись выполнения, сессия и значения по умолчанию. Иными словами, если один раз учесть при регистрации моменты, перечисленные в этой статье — выбор типа входа, включение журнала, проектирование кодов завершения и журналирования, явное указание повторного запуска и ограничения времени, — в дальнейшем задача будет удивительно необременительной в обслуживании.

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

Похожие статьи

• Продвинутое использование PowerShell-скриптов — безопасная автоматизация анализа, архивирования и отчётности логов
• Защита PowerShell-скриптов с помощью Pester — стратегия тестирования на этапе сопровождения
• Автоматизация бизнес-процессов с помощью Power Automate — разграничение облачных и настольных потоков и проектирование обработки ошибок
• Когда Windows-приложению на самом деле нужны права администратора

Смежные области консультаций

Komura Software LLC (合同会社小村ソフト) занимается ревью проектирования автоматизации бизнес-процессов на базе PowerShell и планировщика заданий, а также консультациями по восстановлению периодических заданий, оказавшихся в состоянии «работает, но никто не может это починить».

• Техническая консультация и ревью проектирования
• Разработка Windows-приложений
• Расследование причин сбоев
• Контакты

Справочные материалы

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что означает код 0x1 в поле «Результат последнего выполнения» планировщика заданий?

0x1 — это не ошибка самого планировщика заданий, а означает, что запущенная программа вернула код завершения 1. Причина кроется в скрипте. Типичные причины — разница в текущем каталоге, переменных окружения, профиле и политике выполнения между ручным запуском и запуском по расписанию. Также стоит учитывать соглашения о кодах завершения внешних команд вроде robocopy, которая может возвращать 1 даже при успешном выполнении. Полезно различать коды: семейство 0x413xx — это коды состояния планировщика заданий, а 0x8007xxxx — коды ошибок Windows, что помогает не искать причину не там, где нужно.

Почему скрипт работает при ручном запуске, но не работает через планировщик заданий?

Почти наверняка причина в различиях учётной записи выполнения, сессии и окружения. При выборе «Выполнять вне зависимости от того, вошёл ли пользователь в систему» задача работает в неинтерактивной сессии, поэтому подключённые сетевые диски и переменные окружения пользовательского профиля попросту отсутствуют. Кроме того, при варианте «Не хранить пароль» (S4U) нет доступа к сетевым ресурсам. Для диагностики полезны такие шаги: проверка вкладки журнала, автономное тестирование скрипта, временное переключение на «Выполнять только для вошедших в систему пользователей». Журнал задач по умолчанию отключён, поэтому обязательно включите его перед вводом в эксплуатацию.

Как правильно вызывать PowerShell-скрипт из планировщика заданий?

В качестве программы указывается pwsh.exe (или powershell.exe), а аргументы задаются в форме -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "полный путь". Использование -File вместо -Command приводит к тому, что exit n внутри скрипта напрямую становится кодом завершения процесса, что позволяет определить успех или неудачу. Пути внутри скрипта следует строить от $PSScriptRoot, а в поле «Начать в» нельзя ставить кавычки (иначе задача завершится с 0x8007010B). Сам скрипт нужно спроектировать так, чтобы он явно возвращал 0 при успехе и ненулевое значение при неудаче.

Как предотвратить остановку задачи из-за смены пароля?

При регистрации с параметром «Выполнять вне зависимости от того, вошёл ли пользователь в систему» пароль сохраняется, поэтому после его смены задача продолжает завершаться ошибкой входа (0x8007052E). В доменной среде первым кандидатом является gMSA (групповая управляемая служебная учётная запись) — её пароль автоматически управляется контроллером домена, и сама эта проблема исчезает. Если используется выделенная служебная учётная запись, управляйте сроком действия пароля и инвентаризацией задач как единым процессом. Дополнительно стоит настроить уведомления по почте или в Teams при сбое, чтобы не пропустить ситуацию, когда задача незаметно простаивает месяцами.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.