Как настроить запуск PowerShell по расписанию в Windows

Чтобы PowerShell-скрипт запускался по расписанию, в Планировщике укажите исполняемый файл PowerShell, передайте ему полный путь к `.ps1` через `-File` и выберите учётную запись с нужными правами. Я покажу настройки, которые проверяю сам, и объясню, почему запуск от администратора и `Bypass` не являются универсальным лекарством.

Подготовьте скрипт к фоновому запуску

Начинаю с простого: запускаю .ps1 вручную под той же учётной записью, от имени которой будет работать задача. Проверяю не только код возврата, но и результат: создался ли файл, обновилась ли запись, доступен ли сетевой ресурс. Планировщик запускает программу в отдельном контексте. Там может не быть открытой консоли, загруженного пользовательского профиля, подключённых вручную дисков и переменных, заданных только в окне администратора. Скрипт, который ждёт Read-Host, просит подтверждение или открывает диалог, в такой среде не сможет спросить человека и будет ждать либо завершится с ошибкой. Уберите интерактивные вопросы, а настройки вынесите в явные параметры или конфигурационный файл с ограниченными правами. Если скрипт читает Z:ackup, замените зависимость от смонтированного диска на UNC-путь вроде \fileserverackup и отдельно проверьте доступ от имени задачи. Сама папка со скриптом должна быть доступна на чтение, а каталоги результата и журнала — на запись только тем, кому это действительно нужно.

Проверьте зависимости до создания расписания: модуль, внешний исполняемый файл, рабочий каталог и переменные среды. Модуль, установленный только в профиле администратора, не обязательно будет доступен служебной учётной записи. Для Windows PowerShell 5.1 общесистемный каталог модулей обычно находится в %ProgramFiles%\WindowsPowerShell\Modules, пользовательский — в Documents\WindowsPowerShell\Modules; для PowerShell 7 пути отличаются. Не копируйте модуль наугад и не дописывайте чужой пользовательский путь в PSModulePath: сначала выясните, какая версия оболочки запускается и где именно установлен модуль. В моих проектах полезнее явно вызвать Import-Module и записать ошибку, чем надеяться, что фоновая сессия сама найдёт нужный компонент. Для плановых резервных копий Windows я использую PowerShell-сценарий, а расписание задаю в Планировщике; проверку восстановления держу отдельным шагом, потому что успешный запуск ещё не доказывает, что копия пригодна. Если нужно описать задачу кодом, модуль ScheduledTasks предоставляет командлет Register-ScheduledTask для регистрации действия и триггера; для одной задачи графический интерфейс часто проще. Если нужен системный аудит и обслуживание такой схемы, мы занимаемся поддержкой ИТ-инфраструктуры.

• Запустите скрипт под учётной записью задачи.
• Проверьте UNC-пути, модули и рабочий каталог.
• Уберите запросы, требующие ответа человека.

Укажите программу, аргументы и учётную запись

В Планировщике создайте задачу и добавьте действие «Запуск программы». В поле программы укажите полный путь к нужной оболочке. Для встроенного Windows PowerShell это обычно C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe; если нужен PowerShell 7, запускайте установленный pwsh.exe и проверьте его фактическое расположение на этой машине. В аргументах передайте параметры оболочки и путь к сценарию, например: -NoProfile -NonInteractive -File "C:\Scripts\Backup.ps1". -File указывает файл, который надо выполнить; кавычки нужны, если путь содержит пробелы. Поле «Рабочая папка», если скрипт от неё зависит, задайте отдельно — например, C:\Scripts. Не вводите аргументы с незакрытой кавычкой: такой пример выглядит почти правильно, а запускает почти не то. Проверьте также разрядность и версию PowerShell, если скрипт использует модуль, рассчитанный только на Windows PowerShell или только на PowerShell 7. Эти оболочки устанавливаются рядом и не взаимозаменяемы автоматически.

Учётную запись выбирайте по доступам, которые реально нужны сценарию. «Выполнять с наивысшими правами» — настройка повышения привилегий для задач, которым это требуется из-за UAC; она не выдаёт права на сетевую папку и не исправляет ACL. Я включаю её только когда задача действительно выполняет административные действия. Для чтения и записи в каталоге достаточно выдать минимально необходимые разрешения самой учётной записи. Если задаче нужно работать, когда пользователь не вошёл в систему, настройте соответствующий режим запуска и учётные данные в свойствах задачи; для интерактивного окна, наоборот, потребуется вошедший пользователь. Это разные сценарии, а не две галочки «на всякий случай». Не назначайте служебной учётной записи членство в локальных администраторах без конкретной причины. В одном типовом разборе для компании «Вертикаль-М» мы бы начали с проверки контекста и прав к каталогу выгрузки, а не с повышения всего процесса: именно так проще отделить проблему доступа от ошибки самого сценария. Если сценарий управляет резервными копиями, сверяйте его доступы с политикой хранения, а не с удобством запуска.

• Вызовите `powershell.exe` или `pwsh.exe` явно.
• Передайте скрипт через `-File` и полный путь.
• Повышайте права только при обоснованной необходимости.

Проверьте запуск и найдите настоящую ошибку

Сначала запускаю задачу кнопкой «Выполнить» и смотрю не только на строку «Последний результат», но и на следы работы скрипта. Код 0x1 не означает автоматически «нет прав»: это ненулевой результат действия, а конкретная причина зависит от того, что вернул сценарий или запущенная программа. Код доступа вроде 0x80070005 тоже не указывает сам по себе, к какому объекту отказан доступ. Сверьте время запуска, учётную запись, путь к программе, аргументы и рабочую папку, затем проверьте журнал Планировщика и журнал событий Windows. Добавьте в сценарий явные сообщения о начале, ключевых этапах и завершении; ошибки перехватывайте и записывайте вместе с контекстом операции. Для простого текстового журнала можно использовать Start-Transcript -Path "C:\Logs\Backup.log" -Append и в конце вызывать Stop-Transcript, предусмотрев завершение и при исключении. Каталог C:\Logs заранее создайте и разрешите запись выбранной учётной записи. Не перенаправляйте > ... 2>&1 в поле аргументов как будто его обрабатывает cmd.exe: оболочку запускает сам Планировщик, а не командная строка, поэтому для надёжного лога настройте запись внутри скрипта или добавьте отдельное действие через корректно настроенный командный интерпретатор.

Если ручной запуск проходит, а запуск по расписанию нет, сравните среды: профиль, текущую папку, переменные, модульный путь, доступ к UNC-ресурсу и наличие сетевого подключения в момент старта. Проверьте, не требует ли скрипт ввод пароля, подтверждение или окно браузера. Временно включить Set-PSDebug -Trace 1 можно для локальной диагностики, но подробная трассировка быстро раздувает журнал и способна показать значения переменных; не оставляйте её без необходимости. Для контроля создания процессов Windows использует событие безопасности 4688, однако аудит создания процессов надо включить, а командную строку для события — отдельно разрешить политикой. Командные аргументы могут содержать чувствительные данные, поэтому включайте подробное логирование осознанно и ограничивайте доступ к журналу. Связывайте симптом с конкретным этапом: «процесс не стартовал», «скрипт стартовал, но не прочёл файл», «результат записан не туда». Это куда полезнее догадки по одному коду. Именно здесь обычно помогает сравнение рабочего запуска с журналом фоновой задачи, а не повторная установка PowerShell.

• Сопоставьте код возврата с логом самого скрипта.
• Проверьте пользователя, рабочую папку и UNC-доступ.
• Трассировку включайте кратковременно и локально.

Обновляйте сценарий предсказуемо

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

PowerShell 7 устанавливается отдельно от Windows PowerShell 5.1, поэтому путь к pwsh.exe и модульный набор надо проверить именно на целевом компьютере. При стандартной MSI-установке PowerShell 7 обычно находится в %ProgramFiles%\PowerShell\7, но ZIP, MSIX и нестандартная папка меняют расположение. Не закрепляйте в статье и в скрипте версию «7.4.0» как обязательный минимум без требования конкретного модуля: безопасная версия определяется совместимостью и поддержкой в вашей среде. Проверьте текущую версию командой $PSVersionTable.PSVersion непосредственно тем исполняемым файлом, который указан в задаче. Обновили оболочку — повторите запуск, проверьте импорт модулей, код завершения и формат лога. Откат должен быть простым: сохранённый прошлый файл, зафиксированные аргументы и понятная процедура возврата. Актуальность — не то же самое, что надёжность; плановое изменение без контроля превращает автоматизацию в сюрприз по расписанию.

• Храните и разворачивайте проверенные версии.
• Проверяйте источник и целостность перед запуском.
• Уточняйте фактический путь к `pwsh.exe`.

Ограничьте права и настройте аудит

Политика выполнения PowerShell не заменяет контроль доступа к файлам и не является защитной границей. Параметр -ExecutionPolicy Bypass действует для запускаемого процесса, но политика из групповой политики может иметь приоритет; сам факт наличия этого ключа не делает сценарий безопаснее. Поэтому я не добавляю Bypass автоматически. Сначала смотрю фактический результат Get-ExecutionPolicy -List, источник скрипта и принятую в организации политику. Если выполнение блокирует управляемая политика, согласуйте корректный способ запуска с администратором, а не пытайтесь обойти ограничение. Для локального проверенного сценария задайте подходящую политику по правилам организации и используйте подписывание, если оно принято. Не переносите пример с Unrestricted в рабочую задачу ради одной ошибки: ослаблять настройки системы намного проще, чем потом выяснять, кто и почему это сделал.

Отдельно ограничьте, кто может менять саму задачу и файл сценария. Если пользователь способен заменить .ps1, который затем запускается с административными правами, защита задачи сводится к правам на этот файл и каталог. Аудит создания процессов помогает увидеть, что запускалось; чтобы в событии 4688 появилась командная строка, включите соответствующую настройку аудита отдельно и учитывайте, что аргументы могут содержать секреты. Проверяйте журналы и права доступа при изменениях, а не только после инцидента. Для похожих сценариев администрирования полезно посмотреть материал про автоматизацию Active Directory в PowerShell; если скрипт связан с резервным копированием Veeam, отдельно изучите учётную запись PowerShell для Veeam. Моя рабочая последовательность простая: минимальная учётная запись, каталог с контролируемой записью, журнал без секретов, тест после каждого изменения. Пароль, помещённый в аргументы задачи, — плохой способ облегчить себе жизнь: такие данные могут попасть в журналы и средства аудита.

• Не используйте `Bypass` по привычке.
• Защитите от записи файл и задачу.
• Не передавайте секреты в аргументах и логах.

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