Как настроить Execution Policy в PowerShell на Windows

Сообщение «running scripts is disabled on this system» не означает, что PowerShell сломан. Часто оно говорит о политике выполнения: оболочка разрешает отдельные команды, но ограничивает загрузку скриптов. Прежде чем менять настройку всего компьютера, нужно понять, какая политика реально действует и на каком уровне она задана.
Разбор относится к PowerShell на Windows. На Linux и macOS модель Windows Execution Policy не применяется так же: наличие команды Get-ExecutionPolicy не означает работу тех же ограничений. Все команды ниже — учебные действия для своей разрешённой среды; настройки вашего компьютера ими здесь не менялись.
Что ограничивает Execution Policy
Политика задаёт условия загрузки конфигурационных файлов и запуска скриптов. Microsoft подчёркивает, что это не граница безопасности: пользователь может выполнить команды иным способом. Политика помогает избежать случайного нарушения правил запуска, но не проверяет смысл скрипта и не делает доверенным всё, что успешно выполнилось.
Например, RemoteSigned не является обещанием «все интернет-скрипты безопасны». Проверенная подпись говорит об определённых свойствах подписанного файла и издателе, а не гарантирует отсутствие вредных действий. Перед запуском важны источник файла, его содержимое и права, с которыми он будет работать.
| Режим | Практический смысл |
|---|---|
| Restricted | Отдельные команды разрешены, скрипты и соответствующие конфигурационные файлы не запускаются |
| RemoteSigned | Локальные скрипты могут быть без подписи; для помеченных как загруженные из интернета нужна доверенная подпись либо осознанная разблокировка файла |
| AllSigned | Подпись доверенного издателя нужна и локальным скриптам, включая написанные самостоятельно |
| Bypass | Политика ничего не блокирует и не показывает предупреждений; это не средство проверки файла |
| Unrestricted | Неподписанные скрипты допускаются, для некоторых внешних источников возможны предупреждения |
| Undefined | В данном scope настройка не задана; это не самостоятельное разрешение на запуск |
Не определяйте политику по общему предположению о настройках «обычного Windows». Результат зависит от установленной оболочки, уровней настройки и управления организацией. Его проще и точнее прочитать командами.
Сначала снимите фактическое состояние
$PSVersionTable.PSVersion
Get-ExecutionPolicy
Get-ExecutionPolicy -List
Первая команда помогает зафиксировать версию оболочки. Вторая показывает эффективную политику текущего сеанса. Третья — значения уровней в порядке приоритета. Выполняйте диагностику в том окне, в котором возникает ошибка: результат из другого процесса не объясняет автоматически проблемный запуск.
Уровни применяются по приоритету: MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine. Выбирается применимая настройка более высокого уровня, а не «самое строгое» слово из списка. MachinePolicy и UserPolicy задаются групповой политикой; Set-ExecutionPolicy не меняет эти уровни и не отменяет их действие.
Условный вывод: MachinePolicy и UserPolicy — Undefined, Process — Undefined, CurrentUser — RemoteSigned, LocalMachine — AllSigned. Эффективна RemoteSigned, поскольку CurrentUser выше LocalMachine. Если же MachinePolicy задана AllSigned, команда для CurrentUser не превращает эффективную политику в RemoteSigned.
Выберите самый подходящий уровень изменения
Для одного рабочего сеанса можно установить RemoteSigned на уровне Process:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process
Get-ExecutionPolicy
Get-ExecutionPolicy -List
Настройка Process относится к текущему сеансу и связанным дочерним процессам, не сохраняется как постоянная настройка пользователя. Закрытие соответствующих процессов завершает её действие. Но она всё равно не перекрывает заданную групповую политику.
Для постоянной работы конкретного пользователя, если правила среды это допускают, используют другой scope:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Постоянная настройка действует до последующего изменения. Уровень LocalMachine затрагивает всех пользователей и для изменения требует запуска с административными правами. Это не обязательный первый шаг для запуска собственного учебного файла. Явно указывайте scope: без него Set-ExecutionPolicy использует LocalMachine.
После команды проверьте именно эффективную политику. Сохранение настройки одного уровня может пройти успешно, а результат всё равно будет определяться более высоким уровнем. Повторять ту же команду с Force бессмысленно: этот параметр не отменяет приоритет групповой политики.
RemoteSigned установлен, но скачанный файл всё ещё блокируется
Следующий вопрос — отмечен ли файл как полученный из интернета. Такой файл отличается от скрипта, созданного локально, даже при одинаковом тексте. На файловой системе с поддержкой соответствующих потоков отметку можно посмотреть так:
Get-Item -LiteralPath '.\reports\inventory.ps1' -Stream Zone.Identifier
Get-Content -LiteralPath '.\reports\inventory.ps1'
Если поток не найден, это не доказательство безопасности: не каждый способ загрузки добавляет отметку. Просмотр содержимого тоже не превращает незнакомый сложный код в проверенный. Выясните происхождение файла и назначение команд, особенно загрузки дополнительного кода и изменений данных.
После проверки конкретный доверенный файл можно разблокировать:
Unblock-File -LiteralPath '.\reports\inventory.ps1'
& '.\reports\inventory.ps1'
Unblock-File удаляет отметку интернет-происхождения у указанного файла, не устанавливает новую Execution Policy и не подписывает скрипт. При AllSigned отсутствие подписи останется отдельным препятствием. Не заменяйте точечную операцию рекурсивной разблокировкой всей папки загрузок: это распространяет доверие на файлы, которые вы не разбирали.
Разовый запуск отдельного процесса
Microsoft также описывает параметр ExecutionPolicy при запуске pwsh.exe. Например, можно открыть отдельный сеанс с RemoteSigned и выполнить один проверенный файл:
pwsh.exe -ExecutionPolicy RemoteSigned -File '.\reports\inventory.ps1'
Команда предполагает установленный PowerShell с доступным pwsh.exe. Она не является инструкцией менять Windows PowerShell на другую версию ради обхода правил организации. Для управляемой среды используйте согласованный способ запуска, подпись или обращение к администратору.
Bypass существует для специально спроектированных сценариев с собственной моделью доверия, например внутри приложения. Для ошибки неизвестного скачанного файла это слабый ответ: исчезновение сообщения не объясняет, что файл сделает. Обычно разумнее установить причину ограничения и выбрать требуемую настройку либо корректно подписанный файл.
Как вернуть настройки и отличить другие ошибки
До постоянного изменения сохраните исходное значение нужного scope. Если там было AllSigned, верните AllSigned; если Undefined — удалите собственную настройку через Undefined. Не называйте последнее «универсальным возвратом к безопасному значению»: после удаления действует следующий применимый уровень.
# Только если исходное значение CurrentUser было Undefined
Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser
Get-ExecutionPolicy -List
Get-ExecutionPolicy
Для временного Process проще завершить использованный сеанс и проверить новое окно. Если после исправления политики возникает «Access denied» при записи в каталог, это уже может быть вопрос прав на файл или ресурсы. Если не найден скрипт, проверьте путь и рабочую папку. Execution Policy не исправляет синтаксис, отсутствующие модули и права доступа.
Хороший результат настройки — известны версия оболочки, эффективный уровень, причина первоначальной блокировки и сделанное изменение. Тогда повторный запуск объясним, а постоянные настройки не оказываются случайным следствием одной учебной ошибки.



