Как легко настроить Windows для работы с сценариями PowerShell

Оглавление:

Как легко настроить Windows для работы с сценариями PowerShell
Как легко настроить Windows для работы с сценариями PowerShell
Anonim
Windows и PowerShell имеют встроенные функции безопасности и конфигурации по умолчанию, предназначенные для предотвращения случайного запуска сценариев в ходе повседневной работы. Однако, если ваши ежедневные действия обычно связаны с написанием и запуском собственных скриптов PowerShell, это может быть скорее неприятностью, чем преимуществом. Здесь мы покажем вам, как обойти эти функции без полного ущерба безопасности.
Windows и PowerShell имеют встроенные функции безопасности и конфигурации по умолчанию, предназначенные для предотвращения случайного запуска сценариев в ходе повседневной работы. Однако, если ваши ежедневные действия обычно связаны с написанием и запуском собственных скриптов PowerShell, это может быть скорее неприятностью, чем преимуществом. Здесь мы покажем вам, как обойти эти функции без полного ущерба безопасности.

Как и почему Windows & PowerShell предотвращает выполнение сценария.

PowerShell - это командная оболочка и язык сценариев, предназначенный для замены CMD и пакетных скриптов в системах Windows. Таким образом, сценарий PowerShell может быть сконфигурирован так, чтобы делать все, что вы могли бы сделать вручную из командной строки. Это приравнивается к практически возможным изменениям в вашей системе, вплоть до ограничений в вашей учетной записи пользователя. Итак, если вы можете просто дважды щелкнуть сценарий PowerShell и запустить его с полными привилегиями администратора, простой однострочный динамик может действительно повредить ваш день:

Get-ChildItem '$env:SystemDrive' -Recurse -ErrorAction SilentlyContinue | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue

НЕ запускайте приведенную выше команду!

Это просто проходит через файловую систему и удаляет все, что может. Интересно, что это не может привести к тому, что система будет неработоспособна так быстро, как вы могли бы подумать - даже при запуске с повышенной сессии. Но если кто-то позвонит вам после запуска этого скрипта, потому что они внезапно не могут найти свои файлы или запустить некоторые программы, «выключить и снова включить», вероятно, просто приведет их в Windows Startup Repair, где им будет сказано, что есть ничего не может быть сделано для решения проблемы. Что может быть хуже, вместо того, чтобы получить скрипт, который просто разрушает их файловую систему, ваш друг может быть обманут в запуске, который загружает и устанавливает службу кейлоггера или удаленного доступа. Затем, вместо того, чтобы задавать вам вопросы о Startup Repair, они могут в конечном итоге спросить у полиции некоторые вопросы о банкротстве банка!

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

  • PowerShell по умолчанию не разрешает выполнение внешнего скрипта. Параметр ExecutionPolicy в PowerShell предотвращает выполнение внешних скриптов по умолчанию во всех версиях Windows. В некоторых версиях Windows по умолчанию не разрешено выполнение скриптов. Мы показали вам, как изменить этот параметр в разделе «Как разрешить выполнение сценариев PowerShell в Windows 7», но мы также рассмотрим его на нескольких уровнях.
  • По умолчанию PowerShell не связан с расширением файла.PS1. Сначала мы познакомились с этим в нашей серии PowerShell Geek School. Windows устанавливает действие по умолчанию для файлов.PS1, чтобы открыть их в Блокноте, вместо отправки их в интерпретатор команд PowerShell. Это необходимо для предотвращения случайного выполнения вредоносных скриптов, когда их просто дважды щелкнуть.
  • Некоторые сценарии PowerShell не будут работать без прав администратора. Даже работая с учетной записью уровня администратора, вам все равно нужно пройти через Контроль учетных записей (UAC) для выполнения определенных действий. Для инструментов командной строки это может быть немного громоздким, если не сказать больше. Мы не хотим отключать UAC, но все же приятно, когда мы можем сделать это немного легче.

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

Изменение ассоциации файлов.PS1.

Первой, и, возможно, прежде всего, досадой, которую нужно обойти, является ассоциация по умолчанию для файлов.PS1. Связывание этих файлов с чем-либо, кроме PowerShell.exe, имеет смысл для предотвращения случайного выполнения нежелательных сценариев. Но, учитывая, что PowerShell поставляется с интегрированной средой сценариев (ISE), специально разработанной для редактирования сценариев PowerShell, почему мы хотим по умолчанию открывать файлы.PS1 в «Блокноте»? Даже если вы не готовы полностью переключиться на включение функций двойного щелчка, вы, вероятно, захотите настроить эти параметры.

Вы можете изменить ассоциацию файлов.PS1 на любую программу, которую вы хотите, на панели управления программами по умолчанию, но перекодирование непосредственно в реестр даст вам немного больше контроля над тем, как файлы будут открыты. Это также позволяет вам устанавливать или изменять дополнительные параметры, доступные в контекстном меню для файлов.PS1. Не забудьте сделать резервную копию реестра, прежде чем вы это сделаете!

Параметры реестра, контролирующие запуск сценариев PowerShell, хранятся в следующем месте:

HKEY_CLASSES_ROOTMicrosoft.PowerShellScript.1Shell

Чтобы изучить эти настройки, прежде чем мы перейдем к их изменению, посмотрите на этот ключ и его под-ключи с помощью Regedit. Клавиша «Shell» должна иметь только одно значение «(по умолчанию)», которое имеет значение «Открыть». Это указатель на действие по умолчанию для двойного щелчка на файле, что мы увидим в под-ключах.

Разверните ключ Shell, и вы увидите три под-клавиши. Каждое из них представляет собой действие, которое вы можете выполнить, что характерно для сценариев PowerShell.

Вы можете развернуть каждую клавишу, чтобы исследовать значения внутри, но они в основном приравниваются к следующим значениям по умолчанию:
Вы можете развернуть каждую клавишу, чтобы исследовать значения внутри, но они в основном приравниваются к следующим значениям по умолчанию:
  • 0 - Запуск с помощью PowerShell. «Запуск с PowerShell» на самом деле является именем опции, уже находящейся в контекстном меню для сценариев PowerShell. Текст просто вытаскивается из другого места вместо того, чтобы использовать имя ключа, как и другие. И это все еще не действие двойного щелчка по умолчанию.
  • Изменить - открыть в PowerShell ISE. Это имеет гораздо больший смысл, чем Блокнот, но вам по-прежнему нужно щелкнуть правой кнопкой мыши файл.PS1, чтобы сделать это по умолчанию.
  • Открыть - открыть в Блокноте. Обратите внимание, что это ключевое имя также является строкой, хранящейся в значении «(по умолчанию)» ключа «Шелл». Это означает, что двойной щелчок по файлу будет «Открыть», и это действие обычно используется для использования Notepad.

Если вы хотите использовать предварительно созданные строки команд, которые уже доступны, вы можете просто изменить значение «(по умолчанию)» в командной строке Shell, чтобы оно соответствовало имени ключа, который соответствует тому, что вы хотите сделать двойным щелчком. Это можно легко сделать изнутри Regedit, или вы можете использовать уроки, извлеченные из нашего учебного пособия по изучению реестра с помощью PowerShell (плюс небольшая настройка PSDrive), чтобы начать создание многоразового скрипта, который может настроить ваши системы для вас. Команды, указанные ниже, должны запускаться из сеанса PowerShell с повышенными полномочиями, аналогично запуску CMD в качестве администратора.

Во-первых, вы захотите настроить PSDrive для HKEY_CLASSES_ROOT, поскольку по умолчанию это не настроено. Команда для этого:

New-PSDrive HKCR Registry HKEY_CLASSES_ROOT

Теперь вы можете перемещаться и редактировать разделы реестра и значения в HKEY_CLASSES_ROOT, как и в обычных HKCU и HKLM PSDrives.

Чтобы настроить двойной щелчок, чтобы напрямую запускать скрипты PowerShell:

Set-ItemProperty HKCR:Microsoft.PowerShellScript.1Shell '(Default)' 0

Чтобы настроить двойной щелчок, чтобы открыть сценарии PowerShell в PowerShell ISE:

Set-ItemProperty HKCR:Microsoft.PowerShellScript.1Shell '(Default)' 'Edit'

Чтобы восстановить значение по умолчанию (устанавливает двойной щелчок, чтобы открыть сценарии PowerShell в Блокноте):

Set-ItemProperty HKCR:Microsoft.PowerShellScript.1Shell '(Default)' 'Open'

Это всего лишь основа для изменения действия двойного щелчка по умолчанию. Мы поговорим подробнее о настройке того, как обрабатываются сценарии PowerShell, когда они открываются в PowerShell из Explorer в следующем разделе. Имейте в виду, что определение масштаба предотвращает перенос PSDrives через сеансы. Таким образом, вы, вероятно, захотите включить строку New-PSDrive в начале любого скрипта конфигурации, который вы создаете для этой цели, или добавить его в свой профиль PowerShell. В противном случае вам нужно будет запустить этот бит вручную, прежде чем пытаться внести изменения таким образом.

Изменение настройки PowerShell ExecutionPolicy.

ExecutionPolicy PowerShell - еще один уровень защиты от выполнения вредоносных скриптов. Для этого есть несколько вариантов и несколько различных способов его установки. От большинства до наименее безопасных доступны следующие варианты:

  • Ограничено - сценарии не разрешены. (Настройка по умолчанию для большинства систем.) Это даже предотвратит запуск сценария вашего профиля.
  • AllSigned - все сценарии должны быть подписаны цифровой подписью доверенным издателем для запуска без запроса пользователя. Скрипты, подписанные издателями, явно определенные как ненадежные, или скрипты, которые вообще не подписаны цифровой подписью, не будут работать. PowerShell запросит у пользователя подтверждение, если скрипт подписан издателем, еще не определенным как доверенный или ненадежный. Если вы не подписывали цифровую подпись своего сценария профиля и не установили доверие к этой сигнатуре, он не сможет работать. Будьте осторожны, какие издатели вам доверяют, поскольку вы все равно можете запустить вредоносные скрипты, если вы доверяете неправильному.
  • RemoteSigned - для сценариев, загруженных из Интернета, это фактически то же самое, что и «AllSigned». Однако сценарии, созданные локально или импортированные из других источников, кроме Интернета, могут запускаться без приглашения на подтверждение. Здесь вам также нужно быть осторожным, какие цифровые подписи вы доверяете, но даже будьте осторожны с незаписанными сценариями, которые вы хотите запустить. Это самый высокий уровень безопасности, при котором у вас может быть сценарий рабочего профиля без необходимости его цифровой подписи.
  • Unrestricted - все сценарии разрешены для запуска, но для сценариев из Интернета требуется запрос подтверждения. С этого момента вы полностью избегаете запуска ненадежных скриптов.
  • Обход - все работает без предупреждения. Будьте осторожны с этим.
  • Undefined - политика не определена в текущей области. Это используется для обеспечения возврата к политикам, определенным в более низких областях (подробнее см. Ниже) или по умолчанию для ОС.

Как указано в описании Undefined, вышеуказанные политики могут быть установлены в одном или нескольких из нескольких областей. Вы можете использовать Get-ExecutionPolicy с параметром -List, чтобы увидеть все области и их текущую конфигурацию.

Области перечислены в порядке приоритета, причем верхняя определенная область переопределяет все остальные. Если политики не определены, система возвращается к настройкам по умолчанию (в большинстве случаев это ограничение).
Области перечислены в порядке приоритета, причем верхняя определенная область переопределяет все остальные. Если политики не определены, система возвращается к настройкам по умолчанию (в большинстве случаев это ограничение).
  • MachinePolicy представляет собой групповую политику, действующую на уровне компьютера. Обычно это применяется только в домене, но может выполняться и локально.
  • UserPolicy представляет собой групповую политику, действующую на пользователя. Это также обычно используется только в корпоративных средах.
  • Процесс - это область, специфичная для этого экземпляра PowerShell. Изменения политики в этой области не повлияют на другие процессы PowerShell и будут неэффективными после завершения этого сеанса. Это можно настроить параметром -ExecutionPolicy при запуске PowerShell или установить его с помощью синтаксиса Set-ExecutionPolicy из сеанса.
  • CurrentUser - это область, которая настроена в локальном реестре и применяется к учетной записи пользователя, используемой для запуска PowerShell. Эта область может быть изменена с помощью Set-ExecutionPolicy.
  • LocalMachine - это область, настроенная в локальном реестре, и применяется ко всем пользователям в системе. Это область по умолчанию, которая изменяется, если Set-ExecutionPolicy запускается без параметра -Scope. Как это применимо ко всем пользователям в системе, его можно изменить только с повышенного сеанса.

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

Чтобы сохранить некоторый баланс между безопасностью и удобством использования, политика, показанная на скриншоте, вероятно, лучше всего. Включение политики LocalMachine в Restricted в основном предотвращает запуск скриптов кем-либо, кроме вас. Конечно, это можно обойти пользователями, которые знают, что делают без особых усилий. Но это должно заставлять любых неквалифицированных пользователей случайно запускать что-то катастрофическое в PowerShell. Имея CurrentUser (то есть: вы), установленный как Unrestricted, вы можете вручную выполнять сценарии из командной строки, как вам нравится, но сохраняете напоминание о предостережении для скриптов, загружаемых из Интернета. Настройка RemoteSigned на уровне Process должна быть выполнена в ярлыке PowerShell.exe или (как будет показано ниже) в значениях реестра, которые управляют поведением сценариев PowerShell. Это позволит легко использовать функции двойного щелчка для запуска любых скриптов, которые вы пишете, в то же время создавая более сильный барьер против непреднамеренного выполнения (потенциально вредоносных) скриптов из внешних источников. Мы хотим сделать это здесь, так как гораздо проще случайно дважды щелкнуть сценарий, чем обычно, называть его вручную из интерактивного сеанса.

Чтобы установить политики CurrentUser и LocalMachine, как показано на скриншоте выше, выполните следующие команды с повышенного сеанса PowerShell:

Set-ExecutionPolicy Restricted Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Чтобы принудительно использовать политику RemoteSigned для сценариев, запускаемых в Проводнике, нам нужно будет изменить значение внутри одного из разделов реестра, которые мы смотрели ранее. Это особенно важно, потому что, в зависимости от вашей версии PowerShell или Windows, настройка по умолчанию может заключаться в обходе всех параметров ExecutionPolicy, кроме AllSigned. Чтобы узнать, какая текущая конфигурация для вашего компьютера, вы можете запустить эту команду (убедитесь, что сначала отображен HKCR PSDrive):

Get-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellCommand | Select-Object '(Default)'

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

(Видел в Windows 7 SP1 x64, с PowerShell 2.0)

'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-file' '%1'

(Видел в Windows 8.1 x64, с PowerShell 4.0)

'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' 'if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & '%1''

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

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

'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1'

Вы также можете изменить настройку в PowerShell, если хотите. Не забудьте сделать это с повышенного сеанса с отображением HKCR PSDrive.
Вы также можете изменить настройку в PowerShell, если хотите. Не забудьте сделать это с повышенного сеанса с отображением HKCR PSDrive.

Set-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellCommand '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1''

Запустите сценарии PowerShell в качестве администратора.

Так же, как плохой идеей полностью отключить UAC, также плохой практикой безопасности запускать сценарии или программы с повышенными привилегиями, если вам действительно не нужны они для выполнения операций, требующих доступа администратора. Таким образом, создание приглашения UAC в действие по умолчанию для сценариев PowerShell не рекомендуется. Однако мы можем добавить новую опцию контекстного меню, чтобы мы могли легко запускать скрипты на повышенных сеансах, когда нам нужно. Это похоже на метод, используемый для добавления «Open with Notepad» в контекстное меню всех файлов, но здесь мы собираемся настроить только сценарии PowerShell. Мы также собираемся перенести некоторые методы, используемые в предыдущей статье, где мы использовали пакетный файл вместо хакеров реестра для запуска нашего сценария PowerShell.

Чтобы сделать это в Regedit, вернитесь в ключ Shell:

HKEY_CLASSES_ROOTMicrosoft.PowerShellScript.1Shell

Там создайте новый под-ключ. Назовите его «Запустить с помощью PowerShell (Admin)». Под ним создайте еще один под-ключ под названием «Command».Затем установите для параметра «(по умолчанию)» значение «Command» значение:

'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File '%1'' -Verb RunAs}'

Выполнение этого же в PowerShell на этот раз действительно потребует трех строк. Один для каждого нового ключа и один для установки значения «(по умолчанию)» для команды. Не забывайте о высоте и картировании HKCR.
Выполнение этого же в PowerShell на этот раз действительно потребует трех строк. Один для каждого нового ключа и один для установки значения «(по умолчанию)» для команды. Не забывайте о высоте и картировании HKCR.

New-Item 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)' New-Item 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' Set-ItemProperty 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList ''-ExecutionPolicy RemoteSigned -File '%1''' -Verb RunAs}''

Также обратите особое внимание на различия между строкой, которая вводится через PowerShell, и фактическим значением, которое входит в реестр. В частности, нам нужно обернуть все это в одиночных кавычках и удвоить внутренние кавычки, чтобы избежать ошибок в синтаксическом анализе команд.

Теперь у вас должна быть новая запись контекстного меню для сценариев PowerShell под названием «Запустить с помощью PowerShell (Admin)».

Новый вариант будет содержать два последовательных экземпляра PowerShell. Первая - это просто пусковая установка для второго, которая использует Start-Process с параметром «-Verb RunAs» для запроса возвышения для нового сеанса. Оттуда ваш скрипт должен иметь возможность запускать с правами администратора после нажатия кнопки UAC.
Новый вариант будет содержать два последовательных экземпляра PowerShell. Первая - это просто пусковая установка для второго, которая использует Start-Process с параметром «-Verb RunAs» для запроса возвышения для нового сеанса. Оттуда ваш скрипт должен иметь возможность запускать с правами администратора после нажатия кнопки UAC.

Последние штрихи.

Есть только несколько дополнительных настроек, которые могут помочь сделать жизнь еще проще. Во-первых, как полностью избавиться от функции «Блокнот»? Просто скопируйте значение «(по умолчанию)» из командной строки в разделе «Редактировать» (ниже) в том же месте в разделе «Открыть».

'C:WindowsSystem32WindowsPowerShellv1.0powershell_ise.exe' '%1'

Или вы можете использовать этот бит PowerShell (с помощью Admin & HKCR, конечно):

Set-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellOpenCommand '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell_ise.exe' '%1''

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

(Без доступа администратора)

'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-NoExit' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1'

(С доступом администратора)

'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File '%1'' -Verb RunAs}'

И, конечно же, мы дадим вам и команды PowerShell. Последнее напоминание: Elevation & HKCR!

(Non-Admin)

Set-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellCommand '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-NoExit' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1''

(Admin)

Set-ItemProperty 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList ''-NoExit -ExecutionPolicy RemoteSigned -File '%1''' -Verb RunAs}''

Принимая его за спин.

Чтобы проверить это, мы собираемся использовать скрипт, который может показать нам настройки ExecutionPolicy на месте и независимо от того, был ли запущен скрипт с разрешениями администратора. Сценарий будет называться «MyScript.ps1» и храниться в «D: Script Lab» в нашей тестовой системе. Код приведен ниже, для справки.

if(([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] 'Administrator')) {Write-Output 'Running as Administrator!'} else {Write-Output 'Running Limited!'} Get-ExecutionPolicy -List

Использование действия «Run with PowerShell»:

Используя действие «Запустить с помощью PowerShell (Admin)», после нажатия кнопки UAC:
Используя действие «Запустить с помощью PowerShell (Admin)», после нажатия кнопки UAC:
Чтобы продемонстрировать ExecutionPolicy в действии в области Process, мы можем заставить Windows подумать, что файл пришел из Интернета с этим битом кода PowerShell:
Чтобы продемонстрировать ExecutionPolicy в действии в области Process, мы можем заставить Windows подумать, что файл пришел из Интернета с этим битом кода PowerShell:

Add-Content -Path 'D:Script LabMyScript.ps1' -Value '[ZoneTransfer]`nZoneId=3' -Stream 'Zone.Identifier'

К счастью, у нас был включен -NoExit. В противном случае эта ошибка просто моргнула бы, и мы бы не знали!
К счастью, у нас был включен -NoExit. В противном случае эта ошибка просто моргнула бы, и мы бы не знали!

Идентификатор Zone.Identifier можно удалить следующим образом:

Clear-Content -Path 'D:Script LabMyScript.ps1' -Stream 'Zone.Identifier'

Полезные ссылки:

  • Запуск сценариев PowerShell из пакетного файла - Дневник программирования Daniel Schroeder
  • Проверка разрешений администратора в PowerShell - Привет, сценарист! Блог

Рекомендуемые: