Найбезпечніший спосіб виправити помилку «Execution Policy Restricted» у Windows PowerShell — це не копіювати найширшу команду, яку ви знайдете. Спочатку визначте, яка політика виконання дійсно діє, а потім оберіть найвужчу зміну, яка відповідає тому, що ви намагаєтеся запустити.
Поточна документація Microsoft також наголошує на важливості контексту версії. Документація Windows PowerShell 5.1 вказує Restricted як політику виконання за замовчуванням для клієнтських комп’ютерів Windows. Поточна документація PowerShell 7.6 визначає Default як RemoteSigned у Windows. Однак, якщо всі області дії мають значення Undefined, Microsoft все одно документує ефективне резервне значення на клієнтських комп’ютерах Windows як Restricted. Практичний висновок простий: не робіть висновків про вашу політику на основі версії Windows або навчального посібника. Виконуйте команди політики на машині, де виникає помилка.
Цей посібник порівнює основні способи виправлення за областю дії, стійкістю, впливом на адміністрування та моделлю довіри. Мета полягає в тому, щоб запустити легітимний скрипт, не послаблюючи систему більше, ніж необхідно.
За політики Restricted PowerShell дозволяє виконувати окремі команди, але не дозволяє запускати файли скриптів. Це включає скрипти PowerShell та пов’язані з ними файли конфігурації або скрипти модулів. Microsoft описує політику виконання як функцію безпеки, яка контролює умови завантаження скриптів і файлів конфігурації. Це не є межею безпеки; Microsoft явно зазначає, що користувач все одно може вводити команди в інтерактивному режимі. Прочитайте поточну документацію about_Execution_Policies для PowerShell 7.6 та документацію політики виконання Windows PowerShell 5.1.
Типова помилка повідомляє, що файл .ps1 не може бути завантажений, оскільки запуск скриптів вимкнено; зафіксуйте точне повідомлення перед зміною політики.
Це розрізнення важливе. Політика виконання може допомогти запобігти випадковому запуску скриптів, але встановлення RemoteSigned або Bypass не робить скрипт надійним. Спочатку перегляньте скрипт і його джерело.
Виконайте ці дві команди:
Get-ExecutionPolicy
Get-ExecutionPolicy -List
Перша повертає ефективну політику для поточної сесії. Друга перелічує політики, застосовані на рівнях MachinePolicy, UserPolicy, Process, CurrentUser та LocalMachine. Microsoft рекомендує саме Get-ExecutionPolicy -List для перегляду політик, які можуть впливати на сесію. Див. Get-ExecutionPolicy.
Перевіряйте всі області дії, замість того щоб вважати, що значення LocalMachine є тим, що контролює сесію.
Якщо MachinePolicy або UserPolicy визначені, зупиніться, перш ніж намагатися застосувати локальний обхідний шлях. Ці значення надходять із групової політики та можуть перевизначати налаштування політики виконання, зроблені за допомогою PowerShell. На керованому робочому комп’ютері правильним наступним кроком зазвичай є дотримання процесу організації або звернення до ІТ-відділу.
| Варіант | Стійкість | Адміністративні права | Основний компроміс | Найкраще застосування |
|---|---|---|---|---|
Unblock-File при використанні RemoteSigned | Для конкретного файлу | Зазвичай не потребує підвищення прав для вашого власного файлу | Ви явно довіряєте одному завантаженому файлу; інші завантажені непідписані файли залишаються під дією RemoteSigned | Один переглянутий скрипт, завантажений з Інтернету |
Process RemoteSigned | Лише поточний процес PowerShell | Без зміни LocalMachine | Низька стійкість, але завантажені непідписані файли все одно можуть потребувати розблокування | Тимчасова сесія розробки або усунення несправностей |
CurrentUser RemoteSigned | Зберігається для вашого облікового запису користувача | Не потребує зміни для всіх користувачів | Зручно для регулярного локального скриптингу; ширше, ніж зміна на одну сесію | Особиста робоча станція розробника |
LocalMachine RemoteSigned | Зберігається для всіх користувачів | Потребує підвищення прав | Ширший вплив на весь комп’ютер | Спільний комп’ютер, де адміністратор навмисно хоче застосувати ту саму політику для всіх користувачів |
AllSigned | Залежить від області дії | Залежить від області дії | Вимагає підписів навіть для локально створених скриптів; додає накладні витрати на сертифікати та процес підписання | Організації з процесом підписання коду |
Bypass | Залежить від області дії; зазвичай використовується на рівні Process | Залежить від області дії | Блокування скриптів, попереджень або запитів від політики виконання відсутні | Контрольована автоматизація з власною моделлю довіри та безпеки, а не випадкове постійне налаштування |
Вам не потрібно відкривати PowerShell з підвищеними правами лише для зміни області дії CurrentUser або Process. Microsoft зазначає, що підвищення прав необхідне при зміні політики для локального комп’ютера, тобто LocalMachine. Це корисний компроміс: якщо лише вашому обліковому запису потрібен локальний скриптинг, зміна політики для всіх користувачів додає область дії без додаткової вигоди.
Запуск від імені адміністратора доречний для навмисної зміни LocalMachine, але він не потрібен для областей дії Process або CurrentUser.
Рекомендація за потребою: використовуйте CurrentUser для облікового запису розробника, який регулярно запускає локально створені скрипти. Зберігайте LocalMachine для адміністратора, який навмисно хоче, щоб таке саме налаштування впливало на всіх користувачів.
Для багатьох особистих машин для розробки практичним постійним вибором є:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
RemoteSigned дозволяє запускати локальні скрипти без вимоги підпису, тоді як скрипти, позначені як завантажені з Інтернету, потребують довіреного цифрового підпису, якщо ви явно не розблокуєте файл. Це зберігає корисне розрізнення між кодом, який ви створили локально, і кодом, отриманим з іншого джерела.
Ця ілюстрація показує команду RemoteSigned для всього комп’ютера, оскільки область дії пропущена; LocalMachine є областю дії за замовчуванням. Краще вказувати область дії явно, щоб вплив був навмисним.
Поширеною помилкою є запуск Set-ExecutionPolicy RemoteSigned без -Scope. Microsoft документує LocalMachine як область дії за замовчуванням при встановленні політики виконання. Саме тому краще бути конкретним:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Зміна набуває чинності негайно; PowerShell не потрібно перезапускати для змін CurrentUser або LocalMachine.
Якщо ви усунюєте несправності або запускаєте довірений локальний скрипт один раз, уникайте постійних змін для користувача або комп’ютера. Вужчим варіантом є:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Область дії Process застосовується лише до поточної сесії PowerShell. Microsoft зазначає, що вона зберігається в змінній середовища $Env:PSExecutionPolicyPreference і видаляється при закритті процесу.
Якщо більший додаток, інсталятор або контрольоване середовище автоматизації вже має власну модель безпеки, PowerShell також надає Bypass:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Bypass на рівні Process зникає, коли процес PowerShell закривається, але він також видаляє попередження та блокування політики виконання для цієї сесії.
Компроміс: область дії Process мінімізує стійкість, але Bypass є ширшим, ніж RemoteSigned всередині цієї сесії. Microsoft описує Bypass як такий, що нічого не блокує і не показує попереджень чи запитів, і зазначає, що він призначений для сценаріїв, де інший додаток надає модель безпеки. Для нормальної інтерактивної сесії усунення несправностей спочатку використовуйте Process RemoteSigned, якщо у вас немає конкретної причини для Bypass.
Для окремого одноразового процесу Windows PowerShell ви також можете запустити:
powershell.exe -ExecutionPolicy RemoteSigned -File .\script.ps1
Для PowerShell 7 виконуваний файл — це pwsh.exe. Налаштування політики виконання через командний рядок все одно не перевизначає політику виконання, нав’язану груповою політикою.
RemoteSigned по-різному обробляє файли, позначені як такі, що походять з Інтернету. Microsoft документує командлет Unblock-File як такий, що видаляє цю позначку зони Інтернету, дозволяючи переглянутому непідписаному скрипту запускатися під дією RemoteSigned.
Спочатку огляньте скрипт. Якщо ви довіряєте джерелу і переглянули вміст, виконайте:
Unblock-File -Path .\script.ps1
Ви також можете використати прапорець Unblock у діалоговому вікні властивостей файлу. Microsoft стверджує, що Unblock-File виконує ту саму базову операцію. Див. Unblock-File.
Розблокування одного переглянутого завантаженого скрипту є вужчим заходом, ніж послаблення політики для всіх скриптів на машині.
Ви можете перевірити, чи має файл альтернативний потік даних Zone.Identifier, за допомогою:
Get-Item .\script.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue
Microsoft зазначає, що методи завантаження не завжди позначають файли однаково, тому відсутність цього потоку не є доказом того, що скрипт безпечний.
AllSigned вимагає, щоб усі скрипти та файли конфігурації були підписані довіреним видавцем, включаючи скрипти, створені локально. Це надає організації послідовний процес довіри до видавця, але також створює операційні накладні витрати: скрипти потребують підписів Authenticode, а користувачі повинні довіряти відповідним видавцям.
Документація Microsoft about_Signing пояснює, як PowerShell перевіряє підписи скриптів і як працюють запити щодо довірених видавців.
Рекомендація за потребою: AllSigned має сенс, якщо ваша організація вже має сертифікати підписання коду, контроль публікації та процес оновлення підписаних скриптів. Для окремого розробника, який пише локальні утилітарні скрипти, RemoteSigned зазвичай пов’язаний з меншими тертями, зберігаючи при цьому перевірку походження з Інтернету.
PowerShell надає дві області дії політики, які надходять із групової політики: MachinePolicy та UserPolicy. Документація Microsoft щодо групової політики стверджує, що налаштування Turn on Script Execution може нав’язувати поведінку Restricted, RemoteSigned або AllSigned для керованих користувачів і комп’ютерів. Це налаштування знаходиться за шляхом:
Administrative Templates\Windows Components\Windows PowerShell
Див. about_Group_Policy_Settings.
Якщо Get-ExecutionPolicy -List показує визначені MachinePolicy або UserPolicy, локальна команда Set-ExecutionPolicy може не дати очікуваної ефективної поведінки. Практичним рішенням є запит відповідної політики у адміністратора, використання підписаного скрипту, якщо це потрібно, або використання затвердженого методу розгортання.
Перед зміною постійної області дії запишіть її поточне значення:
Get-ExecutionPolicy -Scope CurrentUser
Get-ExecutionPolicy -Scope LocalMachine
Якщо пізніше вам потрібно буде видалити значення політики, яке ви встановили, Microsoft документує встановлення цієї області дії як Undefined:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Undefined
Не запускайте навмання Set-ExecutionPolicy Restricted лише тому, що це показано на скріншоті. Без вказівки області дії команда за замовчуванням націлена на LocalMachine, і «Restricted» могло не бути попереднім значенням цієї області дії.
Скріншот ілюструє зміну на Restricted, але реальне відкочування повинно відновити область дії та значення, які ви записали, а не вгадувати попередню конфігурацію.
Нарешті, перевірте як ефективну політику, так і скрипт:
Get-ExecutionPolicy
Get-ExecutionPolicy -List
.\script.ps1
Успішний запуск скрипту підтверджує, що безпосередній симптом усунено; повторно перевірте список політик, щоб переконатися, що ви не залишили ширшу область дії зміненою ненавмисно.
| Ваша ситуація | Рекомендована початкова точка | Чому |
|---|---|---|
| Ви завантажили один скрипт з джерела, якому довіряєте | Залиште RemoteSigned і використовуйте Unblock-File після перегляду | Змінює довіру для одного файлу, а не для всіх скриптів |
| Вам потрібні скрипти лише в поточній сесії усунення несправностей | Process RemoteSigned | Закривається разом із сесією і зберігає обмеження щодо походження з Інтернету |
| Ви регулярно пишете та запускаєте власні скрипти | CurrentUser RemoteSigned | Постійна зручність для одного користувача без впливу на всіх на ПК |
| Ви адмініструєте спільну робочу станцію | Оцініть LocalMachine RemoteSigned або організаційну політику | Послідовна поведінка для всіх користувачів, але ширший вплив |
| Ваша компанія вимагає скриптів, контрольованих видавцями | AllSigned через процес підписання та політики організації | Послідовна вимога до підписів ціною накладних витрат на підписання |
| Інсталятор або контрольована система автоматизації має власну модель безпеки | Розгляньте Bypass на рівні Process | Призначено для контрольованих сценаріїв хоста; уникайте робити це випадковим постійним значенням за замовчуванням |
| Визначено MachinePolicy або UserPolicy | Дотримуйтесь ІТ або групової політики | Локальні зміни області дії не є правильним повноваженням |
-Scope може вплинути на LocalMachine, тоді як зміна Process зникає при виході.Для більшості особистих скриптів у Windows CurrentUser RemoteSigned є розумним постійним вибором, коли ви регулярно запускаєте локально створені скрипти, тоді як Unblock-File є вужчим вибором для одного переглянутого скрипту, завантаженого з Інтернету. Для тимчасової сесії усунення несправностей Process RemoteSigned мінімізує стійкість. Bypass має легітимну роль у контрольованій автоматизації, але його компроміс полягає в тому, що блокування та попередження політики виконання видаляються для цього процесу. На керованих комп’ютерах до групової політики слід ставитися як до авторитету, а не як до перешкоди, яку потрібно обійти.
Отже, найкраще виправлення — це не одна політика для всіх. Це найменша область дії та найменш дозвільна поведінка, яка все ще підтримує запуск потрібного вам довіреного скрипту.
Виправте помилку незгенерованого Prisma Client, перевіривши генератор, схему, шлях виводу, імпорти, версії, налаштування монорепозиторію та кроки збірки під час розгортання.
Виправте помилку Git «не вдалося отримати локальний сертифікат емітента», визначивши механізм довіри, встановивши правильний ланцюжок ЦС та зберігаючи перевірку SSL увімкненою.
Виправте помилки таймауту мережі MongoDB у Mongoose, визначивши тип таймауту, перевіривши доступність Atlas або TCP, виправивши URI та налаштувавши таймаути лише за необхідності.
Виправте помилку обмеженої політики виконання PowerShell, перевіривши область дії та групову політику, а потім обравши RemoteSigned, Unblock-File або тимчасовий параметр сесії.
Виправте конфлікти залежностей-партнерів npm ERESOLVE, визначивши несумісний діапазон пакетів, узгодивши версії, використовуючи npm explain та npm ls, а також розглядаючи legacy-peer-deps або force лише як контрольовані резервні варіанти.
Виправте помилки відмови у підключенні Redis на 127.0.0.1:6379, перевіривши сервер, порт, мережу Docker, redis.conf, автентифікацію та TLS.
Виправте помилки 500 у серверних компонентах Next.js, аналізуючи логи сервера, перевіряючи запити даних та змінні середовища, обробляючи помилки та перевіряючи збірку для продакшену.
Діагностуйте та виправляйте помилку CrashLoopBackOff у Kubernetes у локальному Minikube, перевіряючи стан пода, попередні логи, причини завершення роботи, проби, конфігурацію, ліміти пам’яті та стан кластера.
Виправте помилку «Docker Desktop Engine Stopped» у Windows 11, перевіривши статус Docker, оновивши та перезавантаживши WSL 2, підтвердивши віртуалізацію та використавши діагностику перед скиданням налаштувань.
Виправте помилку 'process is not defined' у Vite, замінивши використання process.env у стилі Node.js, правильно налаштувавши змінні VITE_ та перевіривши залежності.
