Как писать и как запускать скрипты powershell

Россия+7 (910) 990-43-11

Windows 10 PowerShell – это средство командной строки, которое позволяет выполнять команды и сценарии для изменения параметров системы и автоматизации задач. Это похоже на командную строку, но PowerShell является более эффективным интерфейсом командной строки (CLI), который предоставляет широкий набор инструментов и обеспечивает большую гибкость и контроль (особенно для сценариев).

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

Это означает, что при двойном щелчке .ps1 файла в системе Windows 10 ничего не произойдёт, и если вы пытаетесь выполнить скрипт в PowerShell, вы получите сообщение об ошибке: «не может быть загружен, потому что запрещено выполнение сценариев в этой системе». Тем не менее, запускать сценарии на вашем устройстве довольно просто. Вам просто нужно включить правильную политику выполнения.

В этой версии урока по Windows 10 мы проведём вас шаг за шагом, чтобы вы смогли успешно запустить свой первый скрипт в PowerShell.

Создание файла сценария PowerShell

В Windows 10 файлы сценариев PowerShell можно создавать с помощью практически любого текстового редактора или консоли интегрированной среды сценариев (ISE).

Создание скрипта с помощью блокнота

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

1. Откройте приложение «Блокнот».
2. Создайте или вставьте сценарий. Например: Write-Host ««Поздравляем! Ваш первый скрипт успешно выполнен»»

   Вышеприведенный скрипт просто выводит на экране фразу «Поздравляем! Ваш первый скрипт успешно выполнен».

3. Сохраните файл под любым удобным названием, например, first_script.ps1

Создание сценария с помощью интегрированной среды сценариев

Кроме того, консоль PowerShell ISE можно использовать для кодирования сценариев в Windows 10. Интегрированная cреда сценариев является сложным инструментом, но вы можете начать работу с помощью этих шагов:

1. Откройте системный поиск и введите запрос Windows PowerShell ISE, щелкните правой кнопкой мыши верхний результат, и выберите Запуск от имени администратора или выберите соответствующий параметр в правой колонке.

2. В PowerShell ISE создайте пустой файл .ps1, в котором можно создать или вставить скрипт. Например:

   Write-Host ««Поздравляем! Ваш первый скрипт успешно выполнен»»

   

3. Откройте меню Файл и нажмите кнопку Сохранить.
4. Введите название сценария. Например, first_script_ise.ps1
5. Сохраните скрипт.

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

Запуск файла сценария PowerShell

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

1. Откройте поиск и введите PowerShell, щелкните правой кнопкой мыши в верхний результат и выберите Запуск от имени администратора.
2. Введите следующую команду, чтобы разрешить выполнение скриптов и нажмите клавишу Enter:

   Set-ExecutionPolicy RemoteSigned

3. Укажите тип А и ещё раз нажмите клавишу Enter.

4. Введите следующую команду для запуска скрипта и нажмите клавишу Enter:

   & «C:PATH oSCRIPTfirst_script.ps1»

   В приведенной выше команде обязательно измените PATH oSCRIPT на расположение вашего скрипта.

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

PowerShell в Windows 10 включает четыре политики выполнения:

• Restricted – останавливает выполнение скрипта.
• RemoteSigned – запускает скрипты, созданные на устройстве. Однако, сценарии, созданные на другом компьютере, не будут запускаться, если они не содержат подписи доверенного издателя.
• AllSigned – все скрипты будут работать до тех пор, пока они подписаны надежным издателем.
• Unrestricted запускает любой скрипт без каких-либо ограничений.

В приведенных выше шагах мы использовали команду, чтобы разрешить запуск локальных скриптов в Windows 10. Однако, если вы не планируете регулярно выполнять скрипты, можно восстановить настройки по умолчанию, используя те же инструкции, но на Шаге 4, обязательно используйте Set-ExecutionPolicy Restricted команду.

Источник: https://windows-school.ru/blog/scenarij_powershell_windows_10/2019-03-02-309

Запуск PowerShell скрипта при возникновении определенного события

Мне пришлось столкнуться с необходимостью запускать PowerShell скрипты при возникновении определенного события (Windows Event) при организации DHCP failover. Однако, думаю, что применений может быть масса.

Покопался в сети и нашел статью под названием Trigger a PowerShell Script from a Windows Event. (http://blogs.technet.com/b/wincat/archive/2011/08/25/trigger-a-powershell-script-from-a-windows-event.aspx). Предлагаю Вашему вниманию перевод данной статьи на русский язык.

Этот пример показывает, как сделать две вещи сразу. Запустить скрипт PowerShell при возникновении определенного события Windows Event, а ТАКЖЕ передать нужные параметры Event-а в запускаемый скрипт. Для примера будет использовано тестовое событие сгенерированное при помощи программы EventCreate из командной строки.

Будут показаны следующие шаги:

• Ручное создание и переключение события
• Использования консоли Просмотра Событий (Event Viewer)
• Изменение запланированной задачи для передачи параметров события скрипту
• Запуск и выполнение PowerShell скрипта
• Проверка настроек

• Шаг 1: Создание записи о событии с помощью EventCreate
• C:>eventcreate /T INFORMATION /SO SomeApplication /ID 1000 /L APPLICATION /D «2011-08-29T21:24:03ZC: empSome Test File.txtSuccess»
• Шаг 2: Создаем новое задание в консоли журнала просмотра событий, с помощью контекстного меню «Прикрепить задачу к данному событию (“Attach Task to This Event…”)

Запустите консоль Event Viewer (eventvwr.msc), найдите в журнале событий Windows Logs -> Application событие, созданное на предыдущем шаге. Щелкните по нему ПКМ и выберите меню «Attach Task to This Event…»

Создайте задачу на запуск программы (“Start a Program”) со следующими параметрами:

Программа/скрипт (Program/script): PowerShell.exe

Аргументы (Add arguments): .TriggerScript.ps1 -eventRecordID $(eventRecordID) -eventChannel $(eventChannel)

1. Запуск в (Start in) (вам может понадобиться создать эту папку или указать на существующую папку): c: emp
2. 
3.  Шаг 3: Изменение задачи для передачи деталей события (trigger event) и передача параметров в скрипт PowerShell

Внутри Планировщика Задач (Task Scheduler), выгрузите только что созданную задачу (как файл XML). Кликните правой кнопкой мыши на задачу «Application_SomeApplication_1000» в папке «Event Viewer Tasks», и выберите «Export…«.

С помощью блокнота (Notepad) или другого текстового редактора (желательно, чтобы редактор поддерживал редактирование Unicode, как Блокнот) добавим параметры события (Event parameters), которые необходимо передать. Параметры события, представленные ниже, наиболее часто используются для идентификации события. Заметим, что весь узел и его дочерние элементы необходимо добавить в ветку EventTrigger.

• Event/System/ChannelEvent/System/EventRecordIDEvent/System/Level
• Вот так:
• 
• Из командной строки запустите следующие команды для удаления задания планировщика и пересоздания ее с помощью только что модифицированного файла (я не знаю способа модифицировать задания с использованием измененного XML файла).
• C:>schtasks /delete /TN «Event Viewer TasksApplication_SomeApplication_1000″C:>schtasks /create /TN «Event Viewer TasksApplication_SomeApplication_1000» /XML Application_SomeApplication_1000.xml
• Шаг 4: Создание PowerShell скрипта TriggerScript.ps1, который вызывается заданием планировщика

# Script Name: TriggerScript.ps1# Usage Example (use a valid ID found via Event Viewer XML view of an event): powershell .TriggerScript.

ps1 -eventRecordID 1 -eventChannel Application## Create a fake event or testing with the following command (from an elevated command prompt):# eventcreate /T INFORMATION /SO SomeApplication /ID 1000 /L APPLICATION /D «2011-08-29T21:24:03ZC: empSome Test File.txtSuccess»# Collects all named paramters (all others end up in $Args)param($eventRecordID,$eventChannel)

$event = get-winevent -LogName $eventChannel -FilterXPath «*[System[(EventRecordID=$eventRecordID)]]»[xml]$eventParams = $event.Messageif ($eventParams.Params.TimeStamp) {[datetime]$eventTimestamp = $eventParams.Params.

TimeStamp$eventFile = $eventParams.Params.InputFile$popupObject = new-object -comobject wscript.shell$popupObject.

popup(«RecordID: » + $eventRecordID + «, Channel: » + $eventChannel + «, Event Timestamp: » + $eventTimestamp + «, File: » + $eventFile)

}

1. Шаг 5: Проверка настроек с помощью генерирования нового события, аналогичному созданного в Шаге 1
2. C:>eventcreate /T INFORMATION /SO SomeApplication /ID 1000 /L APPLICATION /D «2011-08-29T21:24:03ZC: empSome Test File.txtSuccess»
3. Вы должны увидеть такое всплывающее окно сообщения:
4. 
5. Не сработало? Проверяем следующее:

• Проверьте наличие события в Event Viewer. Вам может понадобиться обновить просмотр через меню «Обновить» или кнопкой F5.
• Вручную запустите скрипт с реальными параметрами и посмотрите на возможные ошибки (обратите внимание на комментарии в скрипте, с примерами применения). Пока скрипт является “не подписанным”, может потребоваться настроить PowerShell на запуск данного как не подписанного (см. PS> get-help about_Execution_Policies).
• Убедитесь, что задача находится в Планировщике Заданий (Task Scheduler) в папке “Event Viewer Tasks” и посмотрите на историю выполнения задачи (“History”).

Источник: http://winitpro.ru/index.php/2016/01/21/zapusk-powershell-skripta-pri-vozniknovenii-opredelennogo-sobytiya/

PowerShell: Выполнение сценариев отключено в этой системе

В операционной системе Windows 10 имеется мощный инструмент для управления и выполнения различных задач — это PowerShell.

Эта консоль предназначена для администраторов, поскольку она позволяет им контролировать всю операционную систему с помощью сценариев (script).

PowerShell используется многими фоновыми приложениями для внесения изменений в систему и это ставит под угрозу безопасность нашего ПК.

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

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

Это многоуровневая мера безопасности в PowerShell, которая предотвращает запуск вредоносных сценариев и может нанести вред системе. Давайте разберем, как изменить политики безопасности для PowerShell.

Политики выполнения скриптов в PowerShell

Если вы увидели ошибку «Выполнение сценариев отключено в этой системе», то можем проверить конфигурацию политик для запуска сценариев, которые настроены в Windows 10. Откройте PowerShell от имени администратора и:

• Get-ExecutionPolicy -List

Мы можем видеть несколько уровней разрешений политик для запуска сценариев.

Чтобы изменить политику запуска скрипта, вы должны знать различные уровни привилегий, которые мы можем назначить каждому из областей.

• Restricted: заблокировано выполнение любых скриптов, но разрешается работа интерактивных команд.
• RemoteSigned: загруженные скрипты должны быть подписаны доверенным издателем. Локальные скрипты работают без подписи
• AllSigned: разрешает выполнение любого подписанного скрипта, как локального, так и удаленного (загруженного).
• Unrestricted: без ограничений. Вы можете запустить все сценарии, даже те, которые не подписаны.

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

• Set-ExecutionPolicy Unrestricted -Scope CurrentUser — запуск без ограничения для пользователя.
• Set-ExecutionPolicyRestricted -Scope CurrentUser вернуть назад, если будет нужно.

Разрешает без ограничений выполнять сценарии для локального пользователя. Ключ -Scope определяет, к чему применяется изменение политики. Когда вы вводите «CurrentUser«, то применяется только к текущему пользователю, а когда вы вводите «LocalMachine«, он применяется ко всей системе.

Если выше способ не помог вам запустить свой скрипт и ошибка «Выполнение сценариев отключено в этой системе» появляется, то можно снять полностью ограничения. Вы должны понимать, что это большой риск и ваш скрипт должен быть безопасен на 101%. Откройте PowerShell от имени админа и:

• Set-ExecutionPolicy Unrestricted — разрешить выполнение скриптов без ограничений.
• Set-ExecutionPolicy Restricted— вернуть назад по умолчанию.

Источник: https://mywebpc.ru/windows/politiki-vypolneniya-skriptov-v-powershell/

Запуск PowerShell скрипта

Запуск PowerShell скрипта

Данная заметка посвящена описанию настройки необходимых параметров для запуска PowerShell скриптов. Чаще при первом запуске .ps1 скриптов вы видите следующие ошибки:

Файл невозможно загрузить. Файл не имеет цифровой подписи. Скрипт не будет выполнен в системе. Чтобы получить дополнительные сведения, введите команду «Get-Help about_signing». The file cannot be loaded. The file is not digitally signed. The script will not execute on the system. Please see «Get-Help about_Signing» for more details.

или

Запустить программу от ненадежного издателя? Файл опубликован CN=. Этот издатель не помечен как надежный в данной системе. Выполнять следует только скрипты надежных издателей.

[V] Никогда не выполнять [D] Не выполнять [R] Выполнить один раз [A] Всегда выполнять [?] Справка (по умолчанию «D»): Do you want to run software from this untrusted publisher? The file is published by CN=. This publisher is not trusted on your system.

Only run scripts from trusted publishers. [V] Never run  [D] Do not run  [R] Run once  [A] Always run [?] Help (default is «D»):

Данные ошибки и сообщения вызваны настройками политики выполнения Windows PowerShell.

При этом не стоит думать, что эти параметры действительно повышают безопасность ОС, ведь код все равно отработает, если его скопировать в к консоль PowerShell.

Set-ExecutionPolicy Unrestricted LocalMachine

Применить данную команду рекомендуется в консоли PowerShell запущенной от имени администратора. Данная команда разрешит выполнять, на данном компьютере, не подписанные скрипты и скрипты из Интернета.

Конечно, такой подход не применим в корпоративной среде, поэтом разберемся более подробно с данной ситуацией. Посмотреть текущие настройки политики во всех областях применения можно выполнив командлет Get-Executionpolicy с параметром list.

get-executionpolicy -list

Результат выполнения командлета:

Scope	ExecutionPolicy
——	—————
MachinePolicy	Unrestricted
UserPolicy	Undefined
Process	RemoteSigned
CurrentUser	AllSigned
LocalMachine	Restricted

 Данная политика может принимать 6 значений:

Restricted (Политика выполняется по умолчанию. Например если во всех областях применения стоит значение Undefined)
— Допускает отдельные команды, но скрипты выполнять нельзя.

— Препятствует выполнению всех файлов скриптов, включая файлы форматирования и конфигурации (PS1XML), файлы скриптов модулей (PSM1) и профили Windows PowerShell (PS1).

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

— Имеется риск выполнения неподписанных скриптов из источников, отличных от Интернета, а также подписанных, но вредоносных скриптов.

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

— Имеется риск выполнения подписанных, но вредоносных скриптов.

Unrestricted
— Могут выполняться неподписанные скрипты. (Имеется риск выполнения вредоносных скриптов.)

• — Предупреждает пользователя перед выполнением скриптов и файлов конфигурации, загруженных из Интернета.
• Bypass
  — Ничего не блокируется, и никакие предупреждения и запросы не появляются.
• — Эта политика выполнения предназначена для конфигураций, в которых скрипт Windows PowerShell встроен в более крупное приложение, или для конфигураций, в которых Windows PowerShell является платформой для программы, у которой имеется собственная модель обеспечения безопасности.
• Undefined
  — В текущей области не задана политика выполнения.
• — Если политика выполнения во всех областях имеет значение Undefined, действует политика выполнения Restricted, которая является политикой выполнения по умолчанию.
• Существует пять областей применения данной политики и параметров:

MachinePolicy и UserPolicy задаются политиками AD или локальными политиками данного компьютера.
Process — область применения текущая ссесия.

В справке говорится, что её значение хранится в переменной $PSExecutionPolicyPreference однако получить/изменить значение данной политики через переменную не удалось. Измения сделанные на эту область применения ни как не повлияют на другие сессии.

CurrentUser — область применения текущей пользователь. Её значение хранится в разделе реестра HKEY_CURRENT_USER («HKEY_CURRENT_USERSoftwareMicrosoftPowerShell1ShellIdsMicrosoft.PowerShellExecutionPolicy»).

LocalMachine — область применения на всех пользователей текущего компьютера. Она хранится в разделе реестра HKEY_LOCAL_MACHINE(«HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsScriptedDiagnosticsExecutionPolicy»).

У команды get-executionpolicy есть параметр -Scope. С помощью данного параметра можно выбрать область применения для которого отобразиться значение политики.

Get-ExecutionPolicy -scope Process

Get-ExecutionPolicy -scope Process

Результат выполнения командлета: RemoteSigned

При этом Области применения имеют приоритет высшим обладает MachinePolicy, потом UserPolicy, Process, CurrentUser и самый низкий приоритет у LocalMachine.
Поэтому в примере:

Scope	ExecutionPolicy
——	—————
MachinePolicy	Unrestricted
UserPolicy	Undefined
Process	RemoteSigned
CurrentUser	AllSigned
LocalMachine	Restricted

В текущей ссесии результирующая политика будет иметь значение Unrestricted.

Для того что бы узнать значение политики выполнения скриптов для данной сесии, надо применить командлет  Get-ExecutionPolicy без параметров.

Get-ExecutionPolicy

Вывод: Unrestricted

Изменение политики выполнения скриптов PowerShell:

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

-ExecutionPolicy
Указывает значение политики. Может иметь следующие значения:  Restricted, AllSigned, RemoteSigned, Unrestricted, Bypass, Undefined. Данный параметр обязательный для указания. Если не указан, во время выполнения комадлет попросит указать значения.

Вывод:
Укажите значения для следующих параметров:
ExecutionPolicy:

-Scope
Определяет область применения данной политики. Может иметь следующие значения: LocalMachine ,Process, CurrentUser. Если параметр области применения не указан, по умолчанию указывается значение LocalMachine.

 Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process

или

 Set-ExecutionPolicy Unrestricted Process

-Force
С этим параметром командлет не будет требовать подтверждения со стороны пользователя. Например:

 Set-ExecutionPolicy Unrestricted Process -Force

Командлет ничего не выведет на экран и применит значение политики.

-Confirm
Если же вам наоборот мало одного подтверждения. Можно указать параметр Confirm и у вас будет ещё один, дополнительный, запрос на подтверждение ваших действий:

 Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process -confirm

Результат выполнения:

Подтверждение
Вы действительно хотите выполнить это действие?
Выполнение операции «Set-ExecutionPolicy» над целевым объектом «Unrestricted».
[Y] Да — Y  [A] Да для всех — A  [N] Нет — N  [L] Нет для всех — L  [S] Приостановить — S  [?] Справка (значением по умолчанию является «Y»):

Изменение политики выполнения
Политика выполнения защищает компьютер от ненадежных сценариев. Изменение политики выполнения может поставить под угрозу безопасность системы, как описано в разделе справки, вызываемом командой about_Execution_Policies. Вы хотите изменить политику выполнения?
[Y] Да — Y  [N] Нет — N  [S] Приостановить — S  [?] Справка (значением по умолчанию является «Y»):

-WhatIf
С параметром WhatIf командлет не выполняется. А выводит на консоль свои предполагаемые действия без данного параметра.

 Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process -WhatIf

Результат выполниня:

1.  WhatIf: Выполнение операции «Set-ExecutionPolicy» над целевым объектом «Unrestricted».
2. Изменение параметров политики, при запуске консоли.
3. Так же можно задать значение области применения Process при запуске консоли PowerShell c помощью параметра executionpolicy. Пример:

powershell.exe -executionpolicy Unrestricted

Get-ExecutionPolicy -list

Результат выполнения:

Scope	ExecutionPolicy
——	—————
MachinePolicy	Unrestricted
UserPolicy	Undefined
Process	RemoteSigned
CurrentUser	AllSigned
LocalMachine	Restricted

• Изменение параметров политики запуска скриптов, с помощью групповых политик.
• В груповой политике, параметр контролирующая запуск скриптов находиться по пути:
• для MachinePolicy:
• Computer Configuration/Policies/Administrative Templates/Windows Components/Windows PowerShell
• или
• Конфигурация компьютера/Административные шаблоны/Компоненты Windows/Windows PowerShell
• для UserPolicy:
  User Configuration/Policies/Administrative Templates/Windows Components/Windows PowerShell
• или
• Конфигурация пользователя/Административные шаблоны/Компоненты Windows/Windows PowerShell
• Параметр Execution Policy может принимать 3 значения:

ЗНАЧЕНИЕ ПАРАМЕТРА EXECUTION POLICY В ГРУППОВОЙ ПОЛИТИКИ ЗНАЧЕНИЕ ПАРАМЕТРА ОТОБРАЖАЮЩЕЕСЯ В GET-EXECUTIONPOLICY

Разрешить все скрипты. (Allow all scripts)	Unrestricted
Разрешить локальные скрипты и удаленные подписанные скрипты. (Allow local scripts and remote signed scripts)	RemoteSigned
Разрешить только подписанные скрипты. (Allow all scripts)	AllSigned

Нашли ошибку в тексте? Выделите фрагмент текста и нажмите Ctrl+Enter

Источник: https://www.gotoadm.ru/start-powershell-script/

Как запустить скрипт PowerShell

1. Запустите Windows PowerShell и подождите, пока не появится командная строка PS

2. Перейдите в каталог, где находится сценарий

   PS> cd C:my_pathyada_yada (enter)

3. Выполните скрипт:

   PS> .
   un_import_script.ps1 (enter)

Что мне не хватает??

Или: вы можете запустить скрипт PowerShell из cmd.exe следующим образом:

powershell -noexit «& «»C:my_pathyada_yada
un_import_script.ps1″»» (enter)

• в соответствии с этим блогом здесь
• Или вы можете даже запустить скрипт PowerShell из своего приложения на С# 🙂
• Асинхронно выполнять сценарии PowerShell из вашего приложения С#

marc_s 09 янв. '10 в 22:24

источник
поделиться

Если вы используете PowerShell 2.0, используйте параметр PowerShell.exe -File, чтобы вызвать сценарий из другой среды, например cmd.exe. Например:

Powershell.exe -File C:my_pathyada_yada
un_import_script.ps1

Keith Hill 09 янв. '10 в 23:39

источник
поделиться

Если вы хотите запустить script без изменения политики выполнения по умолчанию script, вы можете использовать переключатель обхода при запуске Windows PowerShell.

powershell [-noexit] -executionpolicy bypass -File

Chingiz Musayev 30 янв. '11 в 22:23

источник
поделиться

Тип:

powershell -executionpolicy bypass -File .Test.ps1

ПРИМЕЧАНИЕ. Здесь Test.ps1 находится PowerShell script.

Sudheesh 05 февр. '15 в 22:38

источник
поделиться

У меня была такая же проблема, и я попытался и попытался… Наконец, я использовал:

powershell.exe -noexit «& 'c:DataScheduledScriptsShutdownVM.ps1'»

И поместите эту строку в пакетный файл, и это работает.

Dennis 08 мар. '10 в 13:47

источник
поделиться

powershell -command — < c:mypathmyscript.ps1

Он передает файл script в командную строку PowerShell.

AndyM 01 июл. '10 в 9:32

источник
поделиться

Довольно легко. Щелкните правой кнопкой мыши файл .ps1 в Windows и в меню оболочки выберите «Выполнить с PowerShell».

electronictonic 23 авг. '16 в 14:51

источник
поделиться

Использование файла cmd (BAT):

@echo off
color 1F
echo.

C:Windowssystem32WindowsPowerShellv1.0powershell.exe -ExecutionPolicy Bypass -File «PrepareEnvironment.ps1»

:EOF
echo Waiting seconds
timeout /t 10 /nobreak > NUL

Если вам нужно запустить как администратор:

• Сделайте ярлык, указывающий на командную строку (я назвал ее
  Административная командная строка)
• Откройте свойства ярлыка и перейдите на вкладку Совместимость
• В разделе «Уровень привилегий» установите флажок «Запустить эту программу в качестве администратора».

Kiquenet 17 нояб. '14 в 9:04

источник
поделиться

• Укажите путь к script, то есть настройку пути по cmd:
  $> . c:program fileprog.ps1
• Запустите функцию точки входа PowerShell:
  Например, $> add or entry_func or main

pkm 16 июн. '13 в 9:28

источник
поделиться

Если ваш script имеет имя с расширением .ps1 и вы находитесь в окне PowerShell, вы просто запустите ./myscript.ps1 (если файл находится в вашем рабочем каталоге).

Это правда для меня в любом случае в Windows 10 с PowerShell версии 5.1 в любом случае, и я не думаю, что я сделал что-либо, чтобы сделать это возможным.

rainabba 06 сент. '16 в 19:58

источник
поделиться

Используйте параметр -File перед именем файла. Кавычки заставляют PowerShell думать, что это строка команд.

Engineer 01 авг. '18 в 11:17

источник
поделиться

У меня есть очень простой ответ, который работает:

1. Откройте PowerShell в режиме администратора
2. Выполнить: set-executionpolicy unrestricted
3. Откройте обычное окно PowerShell и запустите свой скрипт.

Я нашел это решение по ссылке, указанной в сообщении об ошибке:
О политиках выполнения

solstinger 17 сент. '19 в 16:04

источник
поделиться

Источник: http://qaru.site/questions/15845/how-to-run-a-powershell-script

PowerShell Scripts (part 1) — Как надо писать скрипты

В статье PowerShell скрипты, модули, профили (введение) я рассказал об общих моментах, когда стоит создать модуль, а когда достаточно обойтись одним файлом со скриптом. Сегодня я более подробно расскажу о скриптах, как их писать и как писать не стоит.

• Скрипт не всегда состоит из функций, иногда скрипт выполняет какую-то довольно простую задачу, причем делает это в одну строку. Тогда, скорее всего, не следует сохранять его в отдельный файл, или оборачивать в функцию, лучше просто вписать его в строку аргументов планировщика заданий: 
• -NoProfile -Command Get-VMIntegrationService -VMName * -Name ‘Time Synchronization’ | ? Enabled | Disable-VMIntegrationService -Passthru
• Для начала покажу несколько популярных вариантов написания функций.

Основные конструкции:

1. Несколько примеров, как делать можно, но не нужно:

Function welcome ($name = '%UserName%') {«Hello, $name»}

Запускаем без аргументов и видим, что было использовано значение по умолчанию

PS> welcome
Hello, %UserName%
PS>

Теперь запуск с аргументом:

PS> welcome Saw-Friendship
Hello, Saw-Friendship
PS>

Простые функции можно запускать еще так (но не следует):

PS> welcome('Saw-Friendship')
Hello, Saw-Friendship
PS>

Не следует потому, что нужно стремиться к единому стилю кода, а этот вариант не работает, если в функцию передается больше одного аргумента

2. Лучше делать так:

Function welcome {
param ($name = '%UserName%')
«Hello, $name»
}

Работает точно так же, поэтому обойдемся без примеров.

Расширенные функции:

1. Используя конструкцию из последнего листинга, мы можем воспользоваться всеми возможностями расширенных функций.

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

3. Представим, что нам нужна функция, умножающая 2 числа с проверкой по нескольким критериям:

1. Числа должны быть целыми
2. В диапазоне от -1000 до 1000
3. значение не может быть пустым

Приведу 2 варианта:

Function multiplication {
param ($a,$b)
if (
($a -is [int] -and $b -is [int]) -and
($a -ne $null -and $b -ne $null) -and
($a -le 1000 -and $b -le 1000) -and
($a -ge -1000 -and $b -ge -1000)
) {
$a * $b
} else {
Write-Error -Message 'аргументы должны быть целыми числами в диапазоне от -1000 до 1000'
}
}
Function multiplication {
[CmdletBinding()]
param (
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][ValidateRange(-1000,1000)][int]$a
,[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][ValidateRange(-1000,1000)][int]$b
)
$a * $b
}

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

Правда пока я писал этот пример, обнаружился забавный нюанс: несмотря на проверку ValidateNotNullOrEmpty, значение может быть и $null и пустой строкой «», но это происходит из-за того, что оба эти варианта замечательно переводятся в тип [INT]

Получается, что даже это будет работать без ошибки

PS> multiplication $null ''

PS>

О том, какие еще конструкции можно использовать, можно узнать, выполнив

Get-Help about_Functions_Advanced_Parameters

• или через браузер
• Но, как показывает практика, ссылки на MS очень ненадежные ????
• Хочу отметить, что даже в простых функциях следует указывать имена параметров при передаче аргументов. Например так:

PS> multiplication -a 100 -b -100
-10000
PS>

1. Может быть, также вы заметили атрибут CmdletBinding, и может даже пробовали обойтись без него и не заметили разницы, так вот я, честно признаюсь, тоже долго её не замечал, пока не начал активно использовать в скриптах Write-Verbose, и вот тогда это становится очень полезной штукой, но об этом чуть позже.
2. Еще несколько полезных примеров:
3. Представим, что мы хотим передавать в функцию число или строку, причем с проверкой на превышение значения, тогда мы пожем комбинировать проверки для разных типов

Function Int2PadString {
[CmdletBinding()]
param (
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][ValidateRange(0,999)][String]$String
)
$String.PadLeft(3,'0')
}

Результат такой:

PS> Int2PadString -String 1
001
PS>

Теперь добавим возможность передачи массива, изменив [String] на [String[]] и работы в конвейере, добавив ValueFromPipeline=$true
Примерно так:

Function Int2PadString {
[CmdletBinding()]
param (
[parameter(Mandatory=$true,ValueFromPipeline=$true)][ValidateNotNullOrEmpty()][ValidateRange(0,999)][String[]]$String
)
$String.PadLeft(3,'0')
}

Передача массива работает

PS> Int2PadString -String (1..3)
001
002
003
PS>

Передача по конвейеру работает:

PS> 1 | Int2PadString
001
PS>

Но передача массива по конвейеру почему-то не работает!
Это происходит потому, что теперь нам нужен цикл и еще небольшое расширение стандартной конструкции — в неё нужно включить блоки Begin, Process и End
На практике редко используются сразу все эти блоки, но я настоятельно рекомендую их объявить, пусть они останутся пустыми, если не нужны:

Function Int2PadString {
[CmdletBinding()]
param (
[parameter(Mandatory=$true,ValueFromPipeline=$true)][ValidateNotNullOrEmpty()][ValidateRange(0,999)][String[]]$String
)

Begin {}
Process {
$String | ForEach-Object {$_.PadLeft(3,'0')}
}
End {}

}

Отлично, теперь можно и массив отправить в конвейер:

PS> 1..3 | Int2PadString
001
002
003
PS>

Конвейер — очень большая тема, останавливаться за подробностями сейчас не буду, скажу только, что при передаче массива по конвейеру нельзя использовать блок Begin для данных, поступающих по конвейеру! Этот блок служит для предварительных вычислений внутри функции, которые необходимо произвести перед началом работы блока Process. А блок End на практике мне приходилось использовать несколько раз, то есть он почти никогда не используется ????

Передача аргументов

Итак всё это нас потихоньку подвело к теме передачи аргументов.

Я уже успел показать несколько вариантов:

1. В скобках (похоже на перегрузку метода)
2. Через именованные параметры
3. По конвейеру

• Теперь рассмотрим детальнее конвейерный вариант и Splatting, а также их комбинирование.
• Часто возникает необходимость передать по конвейеру объекты без предварительной подготовки переменных и колдовства с Select-Object. Для этих целей мы можем воспользоваться магией расширенных функций, а именно ValueFromPipelineByPropertyName и alias
• Сейчас придумаем какую-нибудь бесполезную функцию. Что может бесполезнее, чем обертка над базовой функцией, итак работающей в одну строку ????
• Напишем обертку для изменения времени создания файла (подробный разбор класса [DateTime] был тут)

Function Set-ItemCreationTime {
[CmdletBinding()]
param (
[parameter(Mandatory=$true,ValueFromPipelineByPropertyName=$true)][alias(«PSPath»)][String[]]$Path
,[parameter(Mandatory=$true)][alias(«DateTime»)][DateTime]$CreationTime
)

Begin {}
Process {
$Path | ForEach-Object {
Set-ItemProperty -Path $_ -Name 'CreationTime' -Value $CreationTime -PassThru
}
}
End {}

}

Как я написал выше, здесь происходит несколько интересных вещей:

1. ValueFromPipelineByPropertyName позволяет использовать свойство объекта, переданного через конвейер, как аргумент для именованного параметра
2. У переданного объекта нет свойства Path, у него есть свойство PSPath, но в нашу функцию это свойство передается именно в параметр Path из-за того, что мы добавили нашему параметру Path параметр alias со значением PSPath. Такой вот забавный этот PowerShell, что и у параметров есть параметры ????

Я мог просто создать аргумент PSPath, но это некрасиво, а Path лучше для понимания, да и во многих командлетах он называется именно так.

Вот вам, кстати, подтверждение моих слов про свойство Path у файлов:

PS> ls C:Temp | Get-Member -Name Path
PS>
PS>
PS> ls C:Temp | Get-Member -Name PsPath
TypeName: System.IO.FileInfo
Name MemberType Definition
—- ———- ———-
PSPath NoteProperty string PSPath=Microsoft.PowerShell.CoreFileSystem::C:Temp1.txt
PS>

Таким образом мы можем обозвать параметр функции как нам угодно, но позволить принимать по конвейеру различные объекты. Это хорошо видно в моем скрипте Send-MagicPacket, который на вход по конвейеру принимает вывод разных командлетов: и Get-NetNeighbor и Get-DhcpServerv4Reservation и что-то еще ????

С конвейером вроде понятно, радости нет предела, что еще нужно? Splatting?

Да! Это очень нужная штука для передачи аргументов в функции.

Если его не использовать, то начинается колхоз со склеиванием команд из строк. типа такого:

PS> $str = 'ls -path ' + 'C: emp'
PS> if ($recurse) {$str += ' -recurse '}
PS>
PS> Invoke-Expression $str
Каталог: C: emp
Mode LastWriteTime Length Name
—- ————- —— —-
-a—- 08.02.2019 22:44 91 1.txt
PS>

1. Так писать не нужно… Никогда…
   Потому что для этого уже придуман Splatting
2. Я уже рассказывал о его практическом применении в статье PowerShell — Массовая загрузка данных в ActiveDirectory
3. Но можно посмотреть и в официальной документации
4. или через справку PowerShell

Get-Help about_Splatting

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

[HashTable]$Param = @{Path='C: emp';Recurse=$true}
ls @Param

Работает так же:

PS>
PS> [HashTable]$Param = @{Path='C: emp';Recurse=$true}
PS>
PS> ls @Param
Каталог: C: emp
Mode LastWriteTime Length Name
—- ————- —— —-
-a—- 08.02.2019 22:44 91 1.txt
PS>

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

PS> [HashTable]$Param = @{Path='C: emp';Recurse=$true}
PS>
PS> $Param.Include = '*.txt'
PS>
PS> ls @Param
Каталог: C: emp
Mode LastWriteTime Length Name
—- ————- —— —-
-a—- 08.02.2019 22:44 91 1.txt
PS>

• Сейчас вроде бы всё, хотя есть вероятность, что я буду обновлять эту статью)
• Спрашивайте, критикуйте, подписывайтесь!
• В следующей статье вас ждут вредные советы о функциях

Источник: https://sawfriendship.wordpress.com/2019/03/16/ps_scripts_modules_profiles_1_1/

Выбираем среду разработки на PowerShell и пишем скрипты для Windows

Содержание статьи

В администрировании всегда есть место творчеству.

Хочешь сделать какую-нибудь автоматизацию рутинной задачи? Пожалуйста! Нужно что-то регулярно проверять на активность? Не вопрос! Хочешь обработать какой-нибудь гигантский отчет и вывести только актуальные данные? Тоже можно. Все эти и многие другие задачи лучше всего решать при помощи скриптов, и язык PowerShell в случае с Windows — оптимальный выбор.

Пользователи UNIX и Linux, а с какого-то момента и macOS привыкли к тому, что под рукой всегда есть Bash — немного старомодное, но универсальное и мощное средство, при помощи которого всего парой строк можно творить удивительные вещи. Прописываешь новый скрипт в cron — и готово, он уже крутится на твоем компьютере или на сервере и незаметно делает что-нибудь полезное.

Возвращаясь в Windows (а без этого иногда никак), понимаешь, что скрипты .bat хоть и хороши, но спасают не всегда: очень уж ограниченны их возможности. И если ты до сих пор считал, что PowerShell — это неведомая штуковина, ради которой нужно что-то там поднимать и настраивать, то не спеши с выводами — он, если разобраться, совсем неплох.

0 вышел в составе Windows 7 и Windows Server 2008 R2 и с тех пор присутствует в Windows в качестве стандартного компонента. Его даже включили в Windows XP SP3. PowerShell построен на основе .NET Framework и интегрирован с ним.

PowerShell может обращаться к COM, WMI и ADSI, а также, конечно же, исполняет консольные команды.

В общем, «пошик» имеет крепкие связи с продуктами Microsoft, будь то Active Directory или почтовый сервер Exchange. Это позволяет без подключения к оснастке сервера обращаться к ним через консоль и отдавать команды.

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

Если не вдаваться в подробности, то в PowerShell 2.0 входит около десятка модулей и примерно 350 команд, а в PowerShell 3.0 уже около 2300 командлетов из более чем 70 модулей.

«Хакер» также писал о том, чем отличается самый новый PowerShell пятой версии из Windows 10.

Теперь давай разберемся, где удобнее всего писать код. Можно, конечно, и в «Блокноте», Notepad++ или Sublime. Но это в данном случае не самый грамотный выбор редактора. Лучше всего начинать знакомство с PowerShell, вооружившись идущим в комплекте PowerShell ISE.

PowerShell ISE

Это даже не редактор, а практически полноценная среда разработки. Здесь есть функция IntelliSense, которая позволяет просматривать перечень командлетов и их параметров, переменных, утилит и прочего. Поддерживаются сниппеты, есть возможность расширения набора функций за счет различных аддонов. Очень полезно и окно Commands.

Тем не менее у PowerShell ISE есть и достойные конкуренты. Один из них — Dell PowerGUI.

PowerGUI — это визуальное дополнение к PowerShell. Оно упрощает сборку собственных сценариев до выбора необходимых командлетов. Берешь то, что нужно для решения задачи, и перетаскиваешь части кода, пока не получишь скрипт.

Одна из главных фишек PowerGUI — это Power Packs, готовые скрипты, опубликованные сообществом пользователей и выложенные в свободный доступ. Тут есть и простенькие команды вроде добавления пользователей, и сложные — к примеру, управление свитчами и виртуальными машинами.

Все их легко дополнять и модифицировать в соответствии с нуждами.

powergui

PowerShell Studio 2015 фирмы Sapien — более продвинутая среда, которая рассчитана на совместную разработку одного проекта большим количеством участников.

Если ты когда-нибудь имел дело с Visual Studio, то, думаю, заметишь сходство.

Среди полезных фишек PowerShell Studio — панель Ribbon, поддержка удаленной отладки, а также функции компилятора, которые позволяют включить скрипты в исполняемые файлы. Есть поддержка разных версий PowerShell.

PowerShell Studio 2015

Стоит упомянуть и Script Browser для Windows PowerShell ISE. Это не среда разработки, но весьма интересный инструмент, разработанный в Microsoft. Script Browser открывает доступ к базе готовых скриптов, которые можно использовать в качестве образцов для написания своего кода. А еще эта штука умеет анализировать код, который ты пишешь, и подсказывает, как его улучшить.

Script Browser для Windows PowerShel

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Я уже участник «Xakep.ru»

Источник: https://xakep.ru/2016/12/06/powershell-scripts-examples/