Загадка выглядит почти оскорбительно просто. Днём вы открываете терминал, вставляете строку запуска скрипта, и через секунду в папке отчётов лежит свежий файл. Вы переносите ту же строку в Планировщик заданий, ставите время 03:00, утром приходите к серверу и находите пустоту. Ни файла, ни ошибки, а в колонке результата то ли ноль, то ли что-то непонятное. Команда та же, сервер тот же, вы тот же. Меняется только одно: кто и как запускает команду.

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

Учебная задача, которая будет обрастать зависимостями

Чтобы разговор не повис в воздухе, возьмём одну простую задачу. Это условный пример для разбора, а не описание чьего-то реального проекта. На Windows VPS каждую ночь нужно взять файл orders.csv, лежащий рядом со скриптом, отфильтровать или просто пересохранить его в UTF-8 и положить с датой в имени в сетевую папку отчётов. Назовём скрипт export.ps1.

Первая, наивная версия, которую пишут почти все:

Import-Csv .\data\orders.csv | Export-Csv Z:\reports\orders.csv -NoTypeInformation -Encoding UTF8

В интерактивном окне она отработает безупречно. И при этом в одной строке спрятаны сразу четыре скрытые зависимости: относительный путь .\data (зависит от текущей папки), диск Z: (зависит от того, кто его подключил), неявный пользователь (от его прав зависит всё остальное) и полное отсутствие следов (если что-то пошло не так, сообщение об ошибке улетает в никуда). Дальше мы будем вытаскивать эти зависимости на свет по одной и превращать в явные строки.

Кто на самом деле запускает задание

Первый вопрос всегда про учётную запись. Когда вы запускаете команду вручную, она выполняется от имени того, кто подключился к серверу по RDP. У задания же собственный контекст учётной записи, и он может отличаться от интерактивного пользователя; на запуск влияют и политики, в частности право «Log on as a batch job» (это следует из материала Microsoft о правах Планировщика). Иначе говоря, «я могу это сделать» и «задание может это сделать» — два разных утверждения.

На практике расхождение чаще всего возникает так. Вы тестировали под администратором, у которого есть доступ практически ко всему. А задание создали от имени другой записи, например выделенной для служебных скриптов. У той нет прав на папку с данными, или нет права на пакетный вход, или она вообще не может прочитать каталог, куда вы положили скрипт. Результат — молчаливый отказ либо ошибка доступа, которую никто не видит.

Поэтому первым делом заставьте скрипт сказать, кто он. Добавьте в самое начало запись в файл с именем пользователя:

[Environment]::UserName

Сравните то, что окажется в файле после запуска из Планировщика, с тем, что вернёт та же команда в вашем окне. Если имена совпали, учётная запись не причина, и можно идти дальше. Если нет, у вас уже есть конкретный подозреваемый.

Не лечите права повышением до администратора

Соблазн велик: задание не работает, значит, поставим галочку «Выполнять с наивысшими правами», а то и запустим всё от администратора. Иногда это действительно заставляет задание завестись. Но вы при этом не нашли причину, а лишь накрыли её более широкими правами. Теперь скрипт, который копирует CSV, умеет в случае ошибки или чужого вмешательства гораздо больше, чем должен.

Разумнее мыслить в обратную сторону: перечислите, что скрипту нужно на самом деле, и выдайте ровно это. В нашей учебной задаче список короткий:

  • чтение каталога со скриптом и данными;
  • запись в каталог журналов рядом;
  • запись в сетевую папку отчётов;
  • возможность входа как пакетное задание, если политика сервера этого требует.

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

Режим «только когда пользователь вошёл» и его ночной двойник

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

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

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

Текущая папка: невидимая точка отсчёта

Относительный путь, такой как .\data\orders.csv, не означает «рядом со скриптом». Он означает «рядом с тем местом, где сейчас находится процесс». Когда вы открываете терминал и переходите в папку со скриптом, эти понятия совпадают, и вы перестаёте замечать разницу. Планировщик ничего за вас не переходит.

У действия задания есть необязательное поле «Рабочая папка» (в английском интерфейсе — «Start in (optional)»). Если оно пустое, процесс стартует не в каталоге скрипта, а в каталоге, определённом системой для такого запуска; нередко это системная папка, где вашего data, естественно, нет. В итоге Import-Csv не находит файл. Ошибка при этом честно возникает, но показать её некому.

Есть два способа решить проблему, и лучше использовать оба. Первый — заполнить рабочую папку в задании. Второй — сделать сам скрипт независимым от того, откуда его запустили. Для PowerShell это выглядит так:

$root = 'C:\Jobs\export'
$src = Join-Path $root 'data\orders.csv'

Корень задан один раз, явно, и все остальные пути из него построены. Если когда-нибудь папку придётся перенести, поменять нужно одну строку, а не искать по скрипту разбросанные точки с обратными слэшами.

Заодно обратите внимание на путь самого скрипта в поле «Аргументы». Тот же принцип: полный путь к файлу, а не короткое имя. Запись вроде -File export.ps1 работает только тогда, когда текущая папка случайно оказалась правильной. Запись -File C:\Jobs\export\export.ps1 не зависит ни от чего.

Проверить гипотезу про папку очень легко: пусть скрипт первой строкой пишет в журнал свою текущую папку ((Get-Location).Path). Если в журнале окажется не C:\Jobs\export, вы нашли причину пустого результата и заодно получили доказательство.

Диск Z:, которого ночью нет

Теперь наша конечная точка — Z:\reports. Буква диска выглядит как часть системы, но на деле это ярлык, созданный в конкретной сессии пользователя. Вы подключили сетевую папку как Z: в проводнике, после чего она появилась в вашем сеансе. Процесс задания, запущенный в другом контексте и без вашего входа, такого подключения не видит. Для него Z: — просто несуществующая буква.

Это самая коварная причина из всех пяти, потому что вы своими глазами видите диск в проводнике, и мысль «его же там нет» не приходит в голову. Стоит помнить: подключённые диски принадлежат сессии, а не серверу.

Решение — отказаться от букв и обращаться к ресурсу по сетевому пути:

$dst = '\\files01\reports'

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

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

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

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации Россия, США, Франция и Великобритания. Оплата картой РФ и по СБП.

АРЕНДОВАТЬ СЕРВЕР

Окружение процесса: что лежит в переменных и откуда запускается программа

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

Типичная картина: скрипт вызывает программу по короткому имени, например какой-нибудь консольный клиент, и в терминале всё работает, потому что каталог с программой прописан в вашем PATH. Ночью оболочка не находит такое имя. Лекарство то же, что и для папок: полный путь к исполняемому файлу в самом скрипте. Для нашей учебной задачи внешних программ почти нет, но сам вызов PowerShell из Планировщика тоже лучше записывать полностью: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.

К окружению относится и профиль. Привычка помещать в профиль PowerShell полезные функции и настройки приводит к тому, что скрипт «случайно» зависит от них. Параметр -NoProfile убирает эту зависимость: скрипт стартует с чистого листа и либо работает сам по себе, либо падает сразу и громко. Параметр -NonInteractive гарантирует, что скрипт не станет ждать ответа на вопрос, которого ночью никто не увидит. Зависшее ожидание ввода — отдельная классика: процесс жив, задание «выполняется» часами, результата нет.

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

Вывод в никуда: как заставить задание рассказывать о себе

Теперь о самом важном для диагностики. Когда вы запускаете скрипт в терминале, вы видите вывод: красный текст ошибки, предупреждения, результат команд. Когда запускает Планировщик, никакого окна нет. Сообщение об ошибке возникает и исчезает вместе с процессом. Именно поэтому задание может «выполниться» без ожидаемого результата, и со стороны это выглядит как мистика.

Microsoft в руководстве по заданиям, которые не выполняются советует проверять сценарий отдельно, смотреть статус, историю и журнал TaskScheduler/Operational, а при поиске причины использовать упрощённый скрипт и собственное журналирование действий. Мы возьмём последний совет буквально: журнал — не опция, а часть задания.

Минимальный журнал для нашей задачи пишет четыре вещи: время старта и контекст (пользователь, текущая папка), результат проверки исходного файла, результат проверки назначения и итог. Каждая запись одной строкой с отметкой времени. Допустим, после ночного запуска в файле лежит:

2025-01-15T03:00:02 start user=svc-export cwd=C:\Jobs\export
2025-01-15T03:00:02 ERROR недоступна папка \\files01\reports

Это конкретный диагноз за секунды. Без журнала вы бы гадали между пятью причинами. (Строки выше — иллюстрация формата, а не вывод реального запуска.)

Код возврата как честный итог

Колонка «Результат последнего запуска» в Планировщике показывает код завершения процесса. Если скрипт при ошибке завершается кодом 0, то есть как будто всё хорошо, никакие настройки задания не смогут отличить успех от провала. Поэтому скрипт должен сам сообщать итог через код возврата: ноль, когда файл записан, и ненулевое значение в остальных случаях. Тогда и Планировщик, и любой ваш мониторинг получают честный сигнал.

Для этого в PowerShell удобно задать $ErrorActionPreference = 'Stop', чтобы ошибки не пропускались молча, и обернуть работу в блок try/catch, где ветка с ошибкой пишет сообщение в журнал и завершает скрипт командой exit 1. Заодно появляется возможность в заданных настройках включить повторы при неудаче: они имеют смысл, только когда неудача вообще распознаётся.

Как воспроизвести ночь, не дожидаясь ночи

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

  1. Запускайте задание из самого Планировщика, а не из терминала. Кнопка «Выполнить» в карточке задания стартует его так же, как расписание: с учётной записью задания, его рабочей папкой и его окружением. Если после этого результата нет, вы воспроизвели проблему, не дожидаясь расписания.
  2. Проверьте задание при закрытой сессии. Выйдите из учётной записи на сервере (именно выйдите, а не просто закройте окно RDP, чтобы сессия не осталась висеть), и запустите задание, например, временным одноразовым триггером на ближайшие минуты. Так проявятся и подключённые диски, и зависимость от открытой сессии.
  3. Тестируйте под обычной записью. Если до сих пор вы проверяли под администратором, создайте тестовую обычную учётную запись и дайте ей только то, что вы перечислили для скрипта. Любая нехватка прав проявится как конкретная ошибка в журнале, и вы поймёте, что именно нужно добавить.
  4. Откройте журнал событий. В журнале TaskScheduler/Operational видно, запускалось ли задание вообще, когда стартовало и когда завершилось. Это разделяет два принципиально разных случая: «Планировщик не запустил процесс» и «процесс запустился и сломался внутри». Если в истории задания события не отображаются, проверьте, включена ли запись истории.

Эти четыре шага, по сути, и есть методика: сначала выясняем, стартует ли вообще, потом — что происходит внутри. Они же подсказывают, где копать дальше. Нет записи о запуске — смотрим триггер, учётную запись, режим входа и политику «Log on as a batch job». Запуск есть, журнала скрипта нет — проблема в самой команде, пути к скрипту или политике выполнения. Журнал есть, но с ошибкой — вы уже читаете причину.

Что ещё отличает ночь от дня

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

Тестовая копия на отдельном VPS

Когда ночное задание важно, а боевой сервер трогать не хочется, удобно отладить его на отдельной небольшой машине. На ней можно создать ту же структуру каталогов, те же учётные записи и сетевую папку-имитацию, и ломать всё без последствий. Для такой отладки обычно хватает минимальных ресурсов: в линейке VPS MAATRIX есть, например, тариф Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) — но это лишь точка отсчёта для пробы, а не обещание, что подойдёт под вашу нагрузку. Серверы доступны с NVMe-дисками и процессорами AMD EPYC, а на странице аренды VPS перечислены локации UK, US, RU и FR. Наличие образа Windows в нужной локации стоит уточнить в форме заказа заранее: состояние наличия там проверяется отдельно.

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

Сборка: задание без загадок

Теперь соберём всё, что мы по очереди сделали явным. Скрипт C:\Jobs\export\export.ps1:

$ErrorActionPreference = 'Stop'
$root = 'C:\Jobs\export'
$logDir = Join-Path $root 'logs'
New-Item -ItemType Directory -Path $logDir -Force | Out-Null
$log = Join-Path $logDir ('export-' + (Get-Date -Format 'yyyy-MM-dd') + '.log')
function Write-Log($m) { Add-Content -Path $log -Value ((Get-Date -Format 's') + ' ' + $m) }

try {
  Write-Log ('start user=' + [Environment]::UserName + ' cwd=' + (Get-Location).Path)
  $src = Join-Path $root 'data\orders.csv'
  $dstDir = '\\files01\reports'
  if (-not (Test-Path $src)) { throw ('нет исходного файла ' + $src) }
  if (-not (Test-Path $dstDir)) { throw ('недоступна папка ' + $dstDir) }
  $dst = Join-Path $dstDir ('orders-' + (Get-Date -Format 'yyyy-MM-dd') + '.csv')
  Import-Csv -Path $src | Export-Csv -Path $dst -NoTypeInformation -Encoding UTF8
  Write-Log ('ok ' + $dst)
  exit 0
} catch {
  Write-Log ('ERROR ' + $_.Exception.Message)
  exit 1
}

И действие задания:

  • Программа: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • Аргументы: -NoProfile -NonInteractive -File C:\Jobs\export\export.ps1
  • Рабочая папка: C:\Jobs\export
  • Учётная запись: отдельная обычная, с правами только на каталог C:\Jobs\export и папку отчётов, режим запуска вне зависимости от входа пользователя.

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

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