powershell функции в скрипте
Powershell функции в скрипте
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов рунета Pyatilistnik.org. В прошлый раз мы с вами очень подробно разобрали, как производится подключение к удаленному рабочему столу в разных операционных системах. Сегодня я вам так же хочу упростить жизнь и научить классным возможностям PowerShell. Мы научимся бороться с рутиной, созданием и использованием функций PowerShell, которые войдут в вашу жизнь так, что вы уже больше не сможете без них представить свое рабочее окружение, ведь проще запомнить одну команду, чем вспоминать, где располагаются ваши скрипты, какое у них имя и так далее.
Что такое функции PowerShell?
По своему опыту хочу отметить, что если вы очень часто используете какие-то сценарии, то старайтесь переводить и сохранять их в функции, это будет экономить много времени, не забывайте делиться этими функциями в галереи PowerShell или github, давайте помогать друг другу.
Представим себе ситуацию, что у вас есть какие-то повседневные задачи, которые вы решаете через скрипты PowerShell, например:
Вариантов ваших повседневных или часто выполняемых задач можете быть огромное количество, главный посыл, что все это можно упростить, создав функции и модули, которые проще использовать и вызывать, чем постоянно вспоминать, где у вас тот или иной скрипт.
Как создавать функции в PowerShell
Иногда мне приходится удалять старые профили с серверов, там я использую утилиту delprof2.exe, о которой я подробно уже писал. Там где мне нужна автоматизация, я создал bat-файл и все живет своей жизнью, а для разовых вещей я использую скрипт. Периодически я его теряю или забываю, где он лежит. поэтому я решил превратить его в функцию, которую легко смогу вызывать по ключевому имени.
Затем, чтобы получить результат, нам нужно присвоить его переменной:
Получив результат, мы воспользуемся foreach циклом для анализа каждой строки, чтобы увидеть, что она собой представляет. Игнорируемый профиль выглядит так:
Нам нужно получить оттуда несколько фрагментов данных. Помимо того факта, что это игнорируемый профиль, я хотел бы собрать имя профиля и причину. Итак, немного магии регулярных выражений, например:
Далее, мы можем построить возвращаемый объект:
Включенные профили немного проще, дополнительной информации для анализа нет. Итак, регулярное выражение будет выглядеть так:
Это дает нам больше полезных данных, которые мы можем использовать в возвращаемом объекте:
Поскольку нам действительно нужно иметь возможность определять параметры для этой функции и мы также хотим иметь возможность принимать ввод с некоторыми параметрами. Для param блока мы можем начать с ( Parameter() для краткости исключаю настройки):
Так что нам понадобится пара циклов foreach, чтобы получить все переключатели в массиве:
Затем, поскольку мы запускаем его на удаленном компьютере, мы должны проверить возможность подключения, все же вы знакомы с командой ping:
И теперь наша команда будет выглядеть так:
Кстати, еще очень удобно использовать функции PowerShell для утилиты robocopy, очень много можно выполнить разных сценариев.
Финальная версия созданной функции PowerShell
Теперь все объединим в единую функцию PowerShell.
Как запускать функцию PowerShell?
Тут два варианта запуска:
Можете просто запустить ваш сценарий, но проблема в том, что все это будет работать в текущей сессии, как только вы разлогинитесь или перезагрузите систему, вам заново нужно будет повторять все шаги.
Что такое модуль PowerShell?
Это означает, что мы можем загрузить набор команд в наш сеанс PowerShell. В более старых версиях PowerShell вам необходимо вручную загружать модули в сеанс, чтобы использовать команды этого модуля.
Например, давным-давно вам нужно было импортировать модуль Active Directory, чтобы использовать команды PowerShell Active Directory. Выглядит это вот так:
Обратите внимание, сколько разных командлетов импортирует один модуль.
Чтобы показать все модули, которые установлены и могут быть импортированы, запустите
Модули хранятся в папке
Как сохранить свою функцию как модуль сценария
Откройте PowerShell ISE, щелкните «Файл» и выберите «Сохранить». Чтобы сделать вашу функцию доступной для всех пользователей, сохраните ее в ProgramFiles\WindowsPowerShell\Modules\Get-InactiveUserProfiles.
Это означает, что вы должны создать там папку с тем же именем, что и ваш файл. Выберите Тип psm1.
Щелкните Сохранить. Закройте все сеансы PowerShell. Снова откройте PowerShell и запустите Get-Module, чтобы просмотреть новый модуль сценария.
А вот и ваш новый модуль и его функция:
Начиная с PowerShell 3.0 ваш модуль импортируется автоматически, а это означает, что ваша команда доступна мгновенно. Нет необходимости импортировать ваш модуль. Теперь мы можем проверять наличие неактивных профилей пользователей локально или удаленно! Давай попробуем, чтобы проверить локальный компьютер введите:
Или если бы мы хотели получить только те профили, которые начинаются с «А» и не использовались более 20 дней:
Помните, что мы можем принимать как входные, так и выходные объекты конвейера? Да, так что мы можем сделать несколько довольно интересных вещей, например, если вам нужно очистить профиль на нескольких компьютерах:
Это будет список профилей со всех компьютеров, возвращенных в этом запросе к AD, которые не являются профилем Administrator и не были использованы в течение 10 дней. Обратите внимание, что я использую командлет Where-Object для фильтрации только тех профилей, которые соответствуют этим критериям. Так что вы даже можете использовать Export-Excelи при необходимости создать хороший отчет для руководителя.
Функции безопасности PowerShell
В PowerShell доступно несколько функций, предназначенных для повышения безопасности среды написания скриптов.
Политика выполнения
Политика выполнения PowerShell — это функция безопасности, управляющая условиями, при которых PowerShell загружает файлы конфигурации и запускает скрипты. Эта функция помогает предотвратить выполнение вредоносных скриптов. Можно также использовать параметр групповой политики, чтобы задать политики выполнения для компьютеров и пользователей. Политики выполнения применяются только к платформе Windows.
Ведение журнала модулей и блоков сценариев
Функция ведения журнала модуля позволяет включить ведение журнала для выбранных модулей PowerShell. Эта настройка эффективна для всех сеансов на компьютере. События выполнения конвейера для указанных модулей записываются в журнал Windows PowerShell в средстве просмотра событий.
Ведение журнала блоков скриптов включает ведение журнала для обработки команд, блоков скриптов, функций и скриптов независимо от того, выполняется ли вызов в интерактивном режиме или посредством автоматизации. Эти сведения записываются в журнал событий Microsoft-Windows-PowerShell/Operational.
Дополнительные сведения см. в следующих статьях:
Ограниченный языковой режим
Управление приложением
Windows 10 включает две технологии: управление приложениями в Защитнике Windows (WDAC) и AppLocker, которые можно использовать для управления приложениями. Они позволяют создать интерфейс блокировки в соответствии с конкретными сценариями и требованиями вашей организации.
Когда речь идет о выборе между WDAC или AppLocker, клиентам обычно рекомендуется использовать управление приложениями с помощью WDAC, а не AppLocker. Платформа WDAC постоянно совершенствуется, и планируется добавить поддержку от платформ управления Microsoft. Несмотря на то, что AppLocker будет по-прежнему принимать исправления безопасности, новые усовершенствования функций не планируются.
WDAC был впервые реализован в Windows 10, позволяя контролировать, какие драйверы и приложения можно запускать на устройствах Windows 10 организации. WDAC разрабатывался как функция безопасности в соответствии с критериями обслуживания, определенными Центром Microsoft по реагированию на угрозы (MSRC).
AppLocker создан на основе функций управления приложениями в рамках политики ограниченного использования программного обеспечения. AppLocker содержит новые возможности и расширения, позволяющие создавать правила для разрешения или запрещения запуска приложений на основе уникальных удостоверений файлов, а также указывать, какие пользователи или группы могут запускать эти приложения.
Критерии обслуживания безопасности
Для PowerShell действуют Критерии обслуживания безопасности Майкрософт для Windows. В таблице ниже приведены функции, которые удовлетворяют или не удовлетворяют этим критериям.
| Функция | Тип |
|---|---|
| Блокировка системы — с использованием Управления приложениями в Защитнике Windows | Функция безопасности |
| Ограниченный языковой режим — с использованием управления приложениями в Защитнике Windows (WDAC) | Функция безопасности |
| Блокировка системы — с использованием AppLocker | Углубленная защита |
| Ограниченный языковой режим — с использованием AppLocker | Углубленная защита |
| Политика выполнения | Углубленная защита |
Дополнительные сведения об AppLocker и управлении приложениями в Защитнике Windows (WDAC) см. в разделе Элементы управления приложениями для Windows и Доступность функций WDAC и AppLocker.
Advanced PowerShell vol. 1: повторное использование кода
Привет! Как большой поклонник и активный практик PowerShell я часто сталкиваюсь с тем, что мне необходимо повторно использовать ранее написанные куски кода.
Собственно, для современных языков программирования code reuse — это обычное дело.
PowerShell в этом вопросе не отстает, и предлагает разработчикам (написателям скриптов) сразу несколько механизмов обращения к написанному ранее коду.
Вот они по возрастанию сложности: использование функций, дот-сорсинг и написание собственных модулей.
Рассмотрим их все порядку.
В качестве решения лабораторной задачи напишем скрипт, который расширяет раздел C:\ до максимально возможного размера на удаленном Windows-сервере LAB-FS1.
Такой скрипт будет состоять из одной строки и выглядеть так:
Работает это так. Сначала PowerShell устанавливает удаленное соединение с сервером LAB-FS1 и запускает на нем локально набор команд, заключенный в фигурные скобки параметра -ScriptBlock. Этот набор в свою очередь последовательно передает команде diskpart три текстовых параметра, а diskpart выполняет (по очереди) повторное сканирование разделов, выбор раздела C:\ и расширение его до максимально возможного размера.
Как видите, скрипт крайне простой, но в то же время крайне полезный.
Рассмотрим, как правильно упаковать его для повторного использования.
1. Использование функций
Самый простой вариант.
Здесь для функции ExtendDisk-Remotely заданы два параметра:
Сохраним скрипт под именем Example-01-Functions.ps1 и запустим:
Видим, что наша функция успешно вызвалась и расширила раздел C:\ на сервере LAB-FS1.
2. Дот-сорсинг
Усложняем ситуацию. Наша функция по расширению разделов оказалась так хороша, что мы хотим прибегать к ее использованию и в других скриптах. Как быть?
Создадим отдельный файл для всех наших функций и назовем его Example-02-DotSourcing.ps1.
Его содержимое будет таким:
Это объявление функции (без вызова), которая теперь хранится у нас в отдельном файле и может быть вызвана в любой момент с помощью техники, которая называется dot-sourcing. Синтаксис выглядит так:
Внимательно посмотрите на первую строку кода и проанализируйте ее содержимое: точка, пробел, путь к файлу с описанием функции.
Такой синтаксис позволяет нам подключить к текущему скрипту содержимое файла Example-02-DotSourcing.ps1. Это то же самое, что использовать директиву #include в C++ или команду using в C# — подключение кусков кода из внешних источников.
После подключения внешнего файла мы уже во второй строке можем вызвать входящие в него функции, что мы успешно и делаем. При этом задотсорсить внешний файл можно не только в теле скрипта, но и в «голой» консоли PowerShell:
Техникой дотсорсинга можно пользоваться, и она будет у вас работать, однако гораздо удобнее пользоваться более современным способом, который мы рассмотрим в следующем разделе.
3. Написание собственного модуля PowerShell
Внимание: Я использую в работе PowerShell версии 4.
Одна из его особенностей заключается в том, что он автоматически подгружает в оперативную память модули по мере обращения к ним, без использования командлета Import-Module.
В старых версиях PowerShell (начиная с 2) написанное ниже будет работать, но может потребовать дополнительных манипуляций, связанных с предварительным импортом модулей перед их использованием.
Мы же будем рассматривать современные среды.
Усложняем ситуацию еще раз.
Независимо от того, сколько функций для повторного использования вы написали, пусть даже одну, сразу оформляйте ее в отдельный модуль. Написание собственных модулей — это самый простой, лучший, современный и грамотный метод повторного использования кода в PowerShell.
Что такое модуль Windows PowerShell
Чтобы понять, куда сохранять, посмотрим содержимое переменной окружения PSModulePath.
Видим, что по умолчанию у нас есть три папки, в которых PowerShell будет искать модули.
Значение переменной PSModulePath можно редактировать с помощью групповых политик, задавая таким образом пути к модулям для всей сети, но это другая история, и рассматривать ее сейчас мы не будем. Зато будем работать с папкой C:\Users\Administrator\Documents\WindowsPowerShell\Modules и сохраним наш модуль в нее.
Код остается неизменным:
Меняется лишь папка, в которую сохраняется файл, и его расширение.
Наш модуль готов, и мы можем проверить, что он виден в системе:
Модуль виден, и в дальнейшем мы можем вызывать его функции без предварительного объявления их в теле скрипта или дотсорсинга.
PowerShell будет воспринимать нашу функцию ExtendDisk-Remotely как «встроенную» и подключать ее по мере необходимости:
На этом всё: мы можем написать десятки собственных модулей, править код включенных в них функций и использовать их в любой момент, не думая о том, в каком скрипте необходимо поменять название функции или путь к дотсорсному файлу.
4. Другие advanced-возможности
Как я уже писал, я люблю PowerShell, и если сообществу интересно, могу написать еще с десяток статей о его расширенном функционале. Вот примеры тем для обсуждения: добавление справки к написанным функциям и модулям; как заставить вашу функцию принимать значения из конвейера и какие это особенности это накладывает на написание скрипта; что вообще такое конвейер и с чем его едят; как с помощью PowerShell работать с базами данных; как устроены расширенные функции и какими свойствами могут обладать их параметры и т.д.
Интересно?
Тогда попробую выдавать по одной статье в неделю.
PowerShell. Пользовательские функции для пользователей
Привет! Довольно часто в своей работе приходиться пользоваться самостоятельно написанными функциями и таскать куски кода между разными скриптами. На Хабре уже есть довольно хорошая статья про Повторное использование кода от Mroff, но была необходимость пойти немного дальше, задокументировать и как-то описать свои функции. Как оказалось, поиск выдавал довольно сухую информацию в основном по общей структуре функции и не более того. Упорство было вознаграждено, и я решил поделиться полученной информацией. Добро пожаловать под кат, где мы научимся вносить в свои функции информацию для потомков и коллег.
Давайте для начала разберем стандартную структуру функции в PowerShell. Выглядит она следующим образом
Сложности никакой нет, но появились дополнительные параметры, которые нам упрощают жизнь:
Mandatory – Принимает два значения True обязательный для заполнения и False необязательный;
HelpMessage – Справка по переменной;
ParameterSetName – Имя переменной к которой относятся данные параметры;
Position – Позиция переменной при вызове функции;
Вроде бы все хорошо теперь у нас есть переменная, у которой есть описание, но для того что бы его узнать необходимо выполнить следующий код:
PowerShell ответит нам одной строкой в которой будет написано: Путь до проверяемого ресурса.
В какой-то степени удобно, но если мы привыкли работать с PowerShell, то знаем команду Get-Help которая выводит подробную информацию о функции с примерами ее использования и переменными, которые необходимо передавать.
Немного усложним задачу и подготовим функцию информация о которой по запросу Get-Help будет выводиться в полном объеме:
Давайте разберем что же мы такого написали:
– В данном блоке написаны параметры для справки PowerShell.
.SYNOPSIS – блок для краткого описание функции
.DESCRIPTION – блок для полного описание функции
.EXAMPLE – блок для примера использования функции, может быть несколько
.PARAMETR Имя параметра – блок для описания переменной, для каждой переменной свой блок.
Как вы могли заметить текстовый комментарий начинается со следующей строки после ключевого названия раздела и может быть многострочным. Окончанием комментария считается закрывающий тег #> или следующий блок.
Теперь все пользовательские функции можно использовать централизованно и вам не придется вспоминать какой параметр за что отвечает, а также какой тип данных использует та или иная переменная.
Что такое Windows PowerShell и с чем его едят? Часть 3: передача параметров в скрипты и функции, создание командлетов
Во второй части цикла рассматривались основы языка программирования PowerShell, а сейчас стоит разобраться с использованием написанного на нем кода для задач администрирования. Самый очевидный способ это сделать — запустить сценарий. Кроме него существует возможность создания собственных командлетов.
Оглавление:
Позиционные параметры
В функциях позиционные параметры используются аналогично:
Print-Args «Ноль» «Один»
Описанный выше способ позволяет передать в сценарий или функцию любое количество параметров, но при вызове необходимо соблюдать порядок их следования, а обращаться к ним можно только по индексу массива — это не всегда удобно.
Блок Param()
В сценариях и функциях намного удобнее использовать именованные параметры. В предыдущей статье мы рассказывали об одном способе их описания:
Корпорация Microsoft рекомендует использовать блок Param() — этот синтаксис более универсален и позволяет задавать не только аргументы функций, но и параметры сценариев:
В теле функции это выглядит так:
Если список аргументов функции невелик, блок Param() только загромоздит конструкцию, но во многих случаях он делает код более читаемым и является помимо прочего элементом хорошего стиля программирования.
Дополнительные атрибуты параметров
При описании аргументов функции или параметров скрипта можно задать их дополнительные атрибуты. Самый простой пример — принудительная установка типа:
Помимо приведения типов можно использовать атрибут [parameter()]:
С его помощью нетрудно сделать параметр обязательным. Обратите внимание на одновременное использование нескольких атрибутов — в этом случае они идут друг за другом:
Position позволяет указать порядок следования параметра (по умолчанию он соответствует порядку объявления):
У атрибута [Parameter()] есть и другие аргументы, полный список которых доступен на сайте Microsoft. Там же описаны прочие атрибуты, с помощью которых можно провести валидацию переданных значений, проверить их с использованием регулярных выражений и т.д. Перечислим некоторые:
[Alias()] устанавливает псевдоним для параметра:
Оператор приведения типов [string[]] означает, что значение параметра — строковый массив.
[AllowEmptyString()] разрешает пустую строку в качестве обязательного параметра:
[AllowEmptyCollection()] разрешает пустой массив в качестве обязательного параметра:
[ValidatePattern()] проверка с использованием регулярного выражения:
[ValidateLength()] проверяет длину строкового параметра:
Передача параметров через конвейер
В первой статье цикла мы рассказывали о возможности передачи данных в командлеты через конвейер (pipeline). В PowerShell командлеты и функции возвращают объекты или массивы объектов (результаты стейтментов), а также получают их на входе. Чтобы это увидеть, препарируем один из командлетов при помощи Get-Help:
ValueFromPipelineByPropertyName обычно используют при необходимости передать несколько параметров, чтобы не возникало путаницы, при этом аргумент можно применять одновременно с ValueFromPipeline:
Как видите, получать параметры через конвейер могут и скрипты, но все же практическое применение описанных выше атрибутов характерно скорее для расширенных функций, которые будут рассмотрены ниже.
Структура тела функции
В языке PowerShell функция может включать три необязательных блока заключенного в операторные скобки кода — Begin, Process и End. Выглядит она примерно так:
Атрибут [CmdletBinding()] и расширенные функции
Параметр -Force применяется для подавления запросов на проведение различных операций;
-WhatIf нужен для эмуляции запуска и отображения информации о последствиях выполнения функции (команды) без этого параметра. Обычно используется, если функция может выполнить деструктивные действия.
-Confirm требует подтверждения и также используется, если функция может выполнить деструктивные действия.
Low — функция незначительно воздействует на систему и не создает существенных рисков потери данных.
Medium — среднее воздействие с незначительным риском потери данных в результате деструктивных действий.
High — код создает высокий риск потери данных в результате деструктивных действий.
Модули сценариев и создание командлетов
Стандартный набор выглядит примерно так:
C:\Users\%UserName%\Documents\WindowsPowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\Windows\System32\WindowsPowerShell\v1.0\Modules
В этой статье мы достаточно подробно разобрали передачу параметров в функции и скрипты. Следующая часть цикла будет посвящена объектно-ориентированному программированию.