Глава 10. PowerShell

Я не думаю что в человеческом сознании существуют какие либо вопросы о том что PowerShell на самом деле эволюция командной строки, однако причина, по которой многие из нас всё ещё по умолчанию взаимодействуют по- старому состоит в том, что старый интерфейс всё ещё имеет возможность осуществлять то, что нам нужно делать на наших серверах. Кроме того, что в действительности содержит командная строка, так это возможность те же самые вещи, которые мы всегда делали из командной строки, и ничего более. Помимо реализации этого существует множество функций, которые вы можете применять в GUI для выполнения того, что нельзя сделать внутри окна командной строки.

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

Большая часть функциональности, которую обычно будут применять администраторы сервера, приходит в виде cmdlet (произносится как команд- леты). Это команды, которые вы исполняете в строке приглашения PowerShell, однако вы можете представлять их себе как инструменты, вместо простых команд. Cmdlet можно использовать как для получения информации от сервера, так и для настройки информации и параметров на сервере. Многие cmdlet имеют интуитивно понятные названия, которые начинаются с get или set и аналогичны тому способу, которым работает большая часть интерфейсов командной строки, причём каждый cmdlet имеет различные переключатели или переменные, которые могут настраиваться и выступать в качестве флагов в самом конце такого cmdlet чтобы делать особые вещи. Поезным будет понять, что cmdlet всегда строятся на синтаксисе глагол- существительное. Вы определяете то действие, которое вы собираетесь осуществить, например get или set, а затем ваше существительное является местом внутри Windows, которым вы пытаетесь манипулировать. Вот некоторые простые примеры cmdlet из PowerShell чтобы представить вам сущность того, как они выглядят и того как они именуются в достаточно простых вариантах:

Если вы когда- либо попадёте в бедственное положение по поводу имени или синтаксиса определённой команды, TechNet имеет полные описания посвящённые каждому cmdlet внутри PowerShell. Это может быть чрезвычайно полезным, однако иногда вы не желаете тратить время на выход в Интернет просто для того, чтобы найти нужное название команды, которую вы просто забыли именно сейчас. Один из наиболее полезных cmdlet в PowerShell отображает вам всех доступных вам cmdlet. Не забываете проверять Get-Command:

Стоп, это страницы и страницы cmdlet! Вместо того чтобы листать весь перечень чтобы найти ту, которую вы ищете, проще отфильтровать этот список на основе любого критерия по вашему желанию. Если вы заинтересованы в поиске только команд, которые связаны с адресацией IP, мы могли бы предпринять такую попытку:

Get-Command –Name *IPAddress*
 	   

Наш cmdlet Get-Command в сочетании с параметром -Name позволяет вам выборочно отыскивать полезные элементы в PowerShell, которые относятся к любому названию или части названия:

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

Когда я начал применять PowerShell, я испытывал соблазн делать именно это, причём постоянно. Однако чем больше я применял его, тем больше я начинал погружаться в тот самый графический интерфейс, тем больше я начинал осознавать, что не только я один применяю PowerShell. Большая часть Инструментов GUI администрирования также использует PowerShell! Даже не отдавая себе в этом отчёт, вы применяете PowerShell для достаточного числа задач внутри операционной системы Windows Server. Когда вы открываете такую консоль управления для того чтобы выполнить некоторые изменения в своём сервере, выполняете свои настройки, а затем щёлкаете по кнопке Go или Finish, как данная консоль помещает вашу настройку на её место? PowerShell. Под капотом, в своей основе, сама консоль имеет информацию о вашем вводе, подключает эту информацию в cmdlet-ы PowerShell и выполняет их чтобы осуществить настоящую работу по настройке.

Таким образом, если вы ещё колеблетесь чтобы приступить к использованию PowerShell потому что он ощущается по- другому, или вы не доверяете тому, что процесс будет таким же как если бы вы работали в самом GUI, забудьте обо всём этом. Потому что во многих случаях когда вы кликаете мышью для изменения настроек своего сервера, вы на самом деле в любом случае пользуетесь cmdlet-ами PowerShell.

Чем больше вы пользуетесь PowerShell, тем более мощным он становится. Помимо выполнения для особого случая, отдельных команд и cmdlet-ов, у вас имеется возможность строить пространные сценарии, которые могут исполнять все виды различных вещей. Я уже упоминал, что PowerShell имеет схожесть с обычным языком программирования, а сценарии (script) являются тем местом, с которого мы начнём продвигаться по этой территории. PowerShell предоставляет возможность создания файлов сценария, причём скоро мы это будем делать для своих целей, которые можно сохранять для простого исполнения тех же самых сценариев снова и снова. Также могут применяться переменные, как и при любом другом кодировании, так что вы можете предоставлять различный ввод и объекты, которые могут использоваться данными сценариями чтобы делать их более гибкими и выжимать даже большую функциональность из них.

Если существует какая- либо одна область ге я думаю мы в качестве администраторов сервера могли бы лучше выполнять задания или использовать данную находящуюся в нашем распоряжении технологию, то это применение PowerShell в наполнении основной модели централизованного управления Microsoft. Когда у нас имеется задание, которое мы должны выполнить на сервере, нашей стратегией по умолчанию будет зарегистрироваться на этом сервере (обычно через RDP), а затем приступить к выполнению данной работы. Регистрация на данном сервере становится всё более и более необходимой, и мы можем сохранить много времени применяя инструменты централизованного управления, которые доступны нам. PowerShell является одним из таких инструментов. Вместо того, чтобы осуществлять Удалённый доступ к такому серверу, просто воспользуйтесь приглашением PowerShell на своей локальной машине чтобы достичь удалённого сервера и изменить данные настройки на нём.

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

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

Это достаточно просто, но самая первая вещь, которую нам необходимо сделать, это получить PowerShell открытым для начала его использования. Консоль PowerShell встроена по умолчанию во всех последних версиях Windows, поэтому вы можете выполнить её прямо из своего меню Start, ткнув в свой рабочий стол, или получить к ней доступ любым другим способом, которым вы обычно открываете любое приложение.

Так как я предпочитаю применять свою клавиатуру для чего угодно, способ, которым я обычно открываю PowerShell заключается в фиксации WinKey и нажатии R для открытия приглашения Run, наборе powershell и нажатии Enter:

Как вы можете увидеть из предыдущего снимка экрана, я только что зарегистрировался в качестве локального администратора на своём сервере, а моё приглашение PowerShell было открыто с повышенными полномочиями. Это видно из того факта, что само слово Administrator также приводится в самом верхнем заголовке данного окна PowerShell. Важно отметить, что в точности как и в случае с командной строкой, вы можете открыть приглашение PowerShell с полномочиями любого обычного пользователя, или с повышенными - с привилегиями Администратора. Обычно более безопасно работать в рамках обычного сеанса PowerShell, который не имеет повышенных прав, пока ваша задача, которую вы пытаетесь реализовать, не потребует таких дополнительных разрешений.

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

Если вы кликните правой клавишей по своей кнопке Start и не найдёте варианта для PowerShell, а вместо него всего лищь открытие приглашения Командной строки, не пугайтесь. Это является вариантом настроек; у вас имеется возможность отображать в быстром меню задач либо приглашение Командной строки, либо вариант PowerShell. Если вы щёлкните правой кнопкой по Панели задач и выберите Taskbar settings (Настройки Панели задач), вы обнаружите некую возможность с названием Replace Command Prompt with Windows PowerShell in the menu when I rightclick the start button or press Windows key+X (Замена приглашения Командной строки на Windows PowerShell в вашем меню при правом клике меню Пуск или нажатии Windows key+X). Переключение этого параметра выполнит обратную перестановку в вашем меню быстрого администрирования на будущее между этими двумя интерфейсами командной строки.

У вас также имеется вариант входа в приглашение PowerShell изнутри существующего окна командной строки. Обычно, когда вы работаете в командной строке, вы не можете применять какие- либо cmdlet-ы. Давайте пройдём далее и сделаем этот выстрел. Откройте обычное окно приглашения Командной строки и попробуйте набрать один из упомянутых ранее cmdlet. Допустим, вы набираете Get-NetIPAddress для отображения нам того, какие IP адреса располагаются внутри данной системы. Упс - вы получили отказ, так как приглашение Командной строки не распознало cmdlet Get-NetIPAddress.

Теперь наберите powershell и нажмите Enter. Вместо открытия отдельного окна PowerShell, ваше приглашение изменится, однако само окно приложения останется тем же самым. Вы теперь имеете оболочку PowerShell изнутри чёрного окна командной строки, и вы можете начинать применять cmdlet как вам вздумается. Запустите снова Get-NetIPAddress и теперь получите некую информацию:

Вы можете выйти из режива powerShell обратно в обычный режим командной строки набрав exit.

Политика исполнения по умолчанию

Когда вы работаете со своим PowerShell напрямую в интерфейсе командной строки, вы просто открываете PowerShell, начинаете набирать cmdlet-ы и запускаете для выполнения работы. Однако, одно из основных преимуществ использования PowerShell получается, когда вы начинаете выполнять создание, сохранение и исполнение сценариев. Если вы открываете PowerShell, создаёте сценарий, а затем пытаетесь его исполнить, вы иногда обнаруживаете, что он не исполняется, выдавая большое неряшливое сообщение об ошибке, например такое:

Этого не должно происходить в только что установленном экземпляре Windows Server 2019, однако может иметь место, если у вас имеется какой- либо GPO, применённый к вашему новому серверу или если вы используете другую операционную систему и пытаетесь выполнять некие сценарии PowerShell, вы можете обнаружить себя застрявшим с одним из таких сообщений об ошибке прямо при входе. Хотя в основе некоторых версий Windows лежит блокирование исполнения сценариев по умолчанию является расширением безопасности,это может вызвать досаду в работе когда вы пытаетесь сделать что- то. К счастью, если вы встретитесь с этой проблемой, её решение является простым. Вам просто необходимо отрегулировать DEP (Default Execution Policy, Политику исполнения по умолчанию) внутри PowerShell, с тем, чтобы разрешить исполнение сценариев для их надлежащего исполнения.

Это не просто переключатель ВКЛЮЧИТЬ/ ВЫКЛЮЧИТЬ. Существует пять различных уровней в рамках Политики исполнения по умолчанию, причём важно понимать каждую из них с тем, чтобы вы могли настроить свою DEP надлежащим образом, основываясь на той безопасности, которую вы хотите разместить в своих серверах. Вот описания каждого из этих уровней, в порядке безопасности от наивысшей к меньшей.

Restricted

Политика Restricted (Ограничения) допускает исполнение команд и cmdlet, однако останавливает исполнение их при собрании воедино в сценарий.

AllSigned

Здесь для исполнения любого сценария требуется его подпись доверенным центром публикации. Когда установлено AllSigned (Всё подписано), все написанные вами сценарии должны быть размещены посредством процесса утверждения (validation) и подписи (sign), прежде чем ему будет дозволено исполнение.

RemoteSigned

RemoteSigned (Удалённая подпись) является политикой по умолчанию в Windows Server 2019. Для сценариев, которые были загружены из Интернета, она требует, чтобы такие сценарии были обязательно подписаны цифровой подписью из центра публикации, которому вы доверяете. Однако, если вы выбрали создание своего собственного сценария, она позволит таким локальным сценариям исполняться без требования подобной цифровой подписи.

Unrestricted

Сценариям разрешается исполнение (Без ограничения), причём как подписанным, так и не имеющим подписи. Вы всё ещё будете получать предупредительное сообщение при исполнении сценария, который был загружен из Интернета.

Режим Bypass

В режиме Bypass (Обхода) ничто не блокируется и никакие предупредительные сообщения не выдаются при исполнении сценариев. Другими словами, вы предоставлены сами себе.

Порой отдельные политики исполнения не соответствуют всем этим потребностям, в зависимости от того, как вы применяете сценарии PowerShell. DEP может быть расширен и далее, путём настройки Execution Policy Scope (Сферы действия политики), которая позволяет вам настраивать различные политики исполнения для различных сторон вашей системы. Например, имеются три сферы, которые могут манипулировать Process (Процессом), CurrentUser (Текущим пользователем) и LocalMachine (Локальной машиной). По умолчанию, на DEP воздействует LocalMachine, так что любой исполняемый сценарий придерживается данной DEP. Однако, если вам необходимо изменить такое поведение с тем, чтобы для каждого CurrentUser или даже персонального Process была установлена отличная DEP.

Если у вас нет уверенности в текущем состоянии вашего DEP, или вы подозреваете что некто мог изменить её, вы легко можете просмотреть назначенную в настоящий момент политику исполнения простым cmdlet, вызываемым как Get-ExecutionPolicy. Как вы можете увидеть на следующем снимке экрана, у меня установлена Restricted, что объясняет моё сообщение об ошибке, которое я получил когда пытался выполнить сценарий:

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

Set-ExecutionPolicy Unrestricted
 	   

Помните, что прямо сейчас вы исполняете PowerShell в данной локальной системе (в моём случае я зарегистрирован на своём сервере WEB3), а следовательно единственная политика исполнения которую я могу настроить это локальная для моей системы WEB3. Если я пожелаю изменить эту настройку глобально, или же для какой- то группы машин в одно и то же самое время, мне следует применять для такого изменения Групповую политику. Местоположением внутри Групповой политики для настройки политик исполнения сценариев PowerShell выступает Computer Configuration | Policies | Administrative Templates | Windows Components | Windows PowerShell | Turn on script execution. {Прим. пер.: и это одна из причин почему при установке Windows Server имеет смысл оставлять основной локализацией USA - потому что искать как это будет по- русски утомительно и в разных версиях может приводить к разным результатам.}

Прежде чем вы начнёте перемещаться внутри PowerShell, существует одно важное замечание, на которое я хочу указать. Начните применять нажатие на клавишу Tab, когда вы находитесь внутри приглашения PowerShell! Если вы наберёте первые несколько букв любой команды или cmdlet, а затем нажмёте Tab, оставшаяся часть имени данного cmdlet-а будет автоматически заполнено на экране.

Если я наберу get-co, а затем нажмуTab, моё приглашение автоматически дополнится до полного Get-Command. Так как существует множество cmdlet, которые начинаются с get-co, если вы нажмёте Tab несколько раз, вы сможете заметить, чо они зациклены по всем доступным cmdlet, которые начинаются с этих букв.

Tab также работает с именами фала и папки. Например, я загрузил заплатку, которую необходимо установить на некий сервер. Я хочу запустить это исправление при помощи приглашения PowerShell, которое я уже открыл, однако я не хочу тратить целую минуту или даже больше чтобы набирать гигантское имя файла данного исправления. Я уже переместился в ту папку, где расположена моя заплатка, и теперь я просто набрал первые несколько букв из имени её файла и нажал на клавишу Tab, PowerShell расширит оставшуюся часть имени файла. Здесь всё что мне остаётся сделать, так это нажать Enter для запуска такой установки:

Когда я начал включать PowerShell в свои повседневные рабочие дела, я нашёл полезным хранить перечень наиболее часто применяемых команд и cmdlet поблизости. Пока вы не достигнете момента, когда они запомнятся и станут второй натурой, если у вас нет быстрого и простого способа воспроизводить эти команды, существует вариант что вы так и не соберётесь применять их и вернётесь к старым методам настройки своих серверов. Вот перечень некоторых из элементов, которые я постоянно применяю при построении серверов. Некоторые из них являются обычными командами, которые также работают из командной строки, а некоторые являются cmdlet-ами, но все они полезны при работе внутри окна PowerShell:

Сколько сотен раз вы пользовались переключателем /? в командной строке для вытаскивания некоторой дополнительной информации о той команде, которую вы хотите исполнить? Предоставляемая такой функцией подсказки информация может иногда выявлять разницу между полезной командой, либо совершенно ненужной. PowerShell имеет аналогичную функцию, но вы не можете просто /? в конце своего cmdlet, так как пробел после cmdlet в PowerShell означает, что вы собираетесь определить некий параметр, который будет использован в данном cmdlet. Например, если мы попытаемся воспользоваться /? с cmdlet Restart-Computer, чтобы выяснить больше информации о том, как применять Restart-Computer, он не распознает знак вопроса в качестве допустимого параметра и выведет следующее:

Вместо этого внутри PowerShell присутствует даже более мощная функция подсказки. Сама по себе, Get-Help является cmdlet, и как и любой другой cmdlet, нам необходимо применять информацию вслед за cmdlet чтобы определять и вытаскивать ту информацию, поиском которой мы занимаемся. Поэтому вместо применения Get-Help в конце команды, как мы это делали со знаком вопроса, мы применяем её как сущность.

Исполнение самой по себе Get-Help только предоставит нам дополнительную информацию о самой команде Get-Help, что может оказаться полезным для просмотра, однако прямо сейчас мы более интересуемся поиском того как мы можем применять Get-Help для предоставления нам дополнительной информации по cmdlet-ам, которые мы бы хотели исполнить, например, функции Restart-Computer. Что нам нужно сделать, это применить Get-Help в качестве cmdlet, а затем определить другой cmdlet в качестве параметра, передаваемого Get-Help поместив между ними пробел:

Get-Help Restart-Computer
 	   

Предоставляемая Get-Help информация очень объёмна, во многих случаях она имеет всю ту информацию, которую вы можете обнаружить в TechNet. Не забудьте начать применение Get-Help для получения дальнейших сведений обо всех cmdlet в PoweShell!

При поиске информации в PowerShell я зачастую сталкиваюсь с таким случаем, что мне предоставляется настолько много информации, что мне трудно её сортировать. Пытались ли вы найти полезный cmdlet при помощи Get-Command, или, быть может, отыскивали определённый синоним посредством Get-Alias? Вывод таких cmdlet-ов может быть ошеломительно длинным. Хотя мы и обсуждали некоторые параметры, которые вы можете применять чтобы обрезать такой вывод, например, определяя параметр -Name, существует пара параметров форматирования, которые могут быть применены для прикрепления к cmdlet, чтобы модифицировать вывод его данных.

Format-Table

Цель Format-Table достаточно проста, он берёт данные из вывода от команды и помещает их в табличный формат. Это обычно делает такую информацию более простой для чтения и для обработки. Давайте рассмотрим пример. Мы пару раз применяли Get-NetIPAddress, однако, давайте будем честными, её вывод слега неряшлив. Исполнение самого по себе данного cmdlet на моей виртуальной машине, которая имеет только один NIC назначенный ей, имеет результатом шесть страниц данных внутри моего окна PowerShell:

Если просто добавить Format-Table в мой cmdlet Get-NetIPAddress, создаваемые данные намного удобнее для глаз, хотя всё ещё предоставляет мне ту важную информацию, которую я в на самом деле разыскиваю - как применять IP адреса к имеющейся системе:

Get-NetIPAddress | Format-Table
 	   

Некоторые из вас могут быть знакомы с cmdlet, имеющим название Select-Object, который может выполнять ту же самую функцию, что и Format-Table. Хотя Select-Object и кажется более широко известным cmdlet, в моей практике он в действительности менее мощный чем Format-Table, и поэтому я предлагаю вам потратить немного времени и поупражняться именно с тем, который мы обсуждали здесь.

Format-List

Аналогично тому способу, которым работает Format-Table, вы можете применять Format-List чтобы выводить перечень свойств. Давайте выполним быструю пробу. Мы уже знаем что Get-Command снабжает нас доступными cmdlet внутри PowerShell, причём по умолчанию он представляет их нам в табличном формате.

Если мы желаем просматривать данный вывод наоборот, в виде некоторого списка, с большими подробностями предоставляемыми для каждого cmdlet, мы можем запросить Get-Command выводить свои данные вместо этого в виде перечня:

Get-Command | Format-List
 	   

Это приведёт к чрезвычайно длинному выводу информации, причём настолько длинному, что моё окго PowerShell имело проблему при отображении всего этого. Возможно, нам следует слегка уменьшить информацию, сузив фокусировку. Давайте отыщем все cmdlet, которые содержат слово Restart причём в формате списка:

Get-Command –Name *Restart* | Format-List
 	   

Большинство администраторов сервера знакомы с концепцией создания пакетных (batch) файлов для применения в мире командной строки. Имеете серии команд, которые вы хотите исполнять последовательно? Необходимо выполнять эту последовательность команд множество раз на различных серверах снова и снова в дальнейшем? Накидываете множество команд вовнутрь текстового документа и затем сохраняете его с расширением файла .BAT, что имеет результатом некий пакетный файл, который может исполняться на любом компьютере Windows, последовательно исполняя эти команды, которые сохраняют вам время и усилия перебора этих команд вновь и вновь внутри интерфейса командной строки.

Сценарии (script) в PowerShell имеют ту же идею, однако более мощную. Команды в приглашении командной строки полезны, однако имеют ограничения, в то время как cmdlet PowerShell имеют возможность манипулировать чем угодно внутри вашей операционной системы. При помощи PowerShell мы даже имеем возможность ссылаться на элементы внутри переменных окружения или всего реестра, мы легко можем выполнять команды на удалённых системах, а также мы можем даже использовать внутри сценария powerShell переменные, в точности так же, как мы бы делали это в любом полном языке программирования.

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

Создание файла .PS1 - файла сценария PowerShell - почти в точности та же самая идея что и создание файла .BAT. Всё что вам необходимо сделать, это открыть текстовый документ, применяя ваш любимый редактор, набросать последовательность команд или cmdlet, а затем сохранить этот файл, поименовав его FILENAME.PS1. Поскольку ваша среда PowerShell позволяет исполнять сценарии - смотрите ранее в этой главе о Политике исполнения по умолчанию - у вас теперь имеется возможность дважды кликнуть по такому файлу .PS1, либо же запустить его из любого приглашения PowerShell, чтобы исполнить последовательность cmdlet внутри такого сценария. Давайте сделаем попытку и проверим что мы можем получить простой сценарий поднятым и работающим.

Так как вы собираетесь создавать сценарии, которые обслуживают некоторую цель, давайте подумаем о примере из реальной жизни. Я немного работаю с серверами терминалов - простите меня, серверами RDS - и распространённый запрос от пользователей состоит в регистрации того, какие пользователи на каком сервере регистрировались. Простой способ сбора такой информации состоит в создании сценари регистрации который записывает информацию о сеансе пользователя в файл, как только они зарегистрировались. Чтобы выполнить это, я должен создать некий сценарий, который я могу настроить на выполнение при процессе регистрации. Чтобы сделать этот сценарий слегка более интересным и гибким для дальнейшего пути, я собираюсь применить некоторые переменные для своего имени пользователя, текущих даты и времени, а также записи самого имени сервера RDS, в которому осуществляется регистрация. Таким образом я могу просматривать общий набор регистраций в будущем и легко выполнять сортировку по пользователям на каких- либо серверах. Я намерен воспользоваться Notepad для создания такого сценария. Открываю новый экземпляр Notepad, ввожу в нём приводимые ниже команды, а потом сохраняю их в качестве C:\Scripts\UserReporting.ps1.

$User = $env:username
$RDSH = $env:computername
$Date = Get-Date
echo $User,$Date,$RDSH | Out-File C:\Scripts\Reporting.txt –append
 	   

Наверное, вы можете сказать, что делает данный сценарий, но давайте всё равно пройдёмся по нему. Во- первых, мы определяем три переменные. Я сообщаю сценарию чему должна быть равна $User вне зависимости от того что отображает переменная среды с системным именем пользователя. $RDSH будет именем того сервера, в котором зарегистрирован этот пользователь, причём его мы также получаем из переменных среды окружения сервера. Третьей определяемой переменной выступает $Date, которая просто извлекает текущую системную данную через вызов cmdlet PowerShell с именем Get-Date.

После распихивания этой информации по переменным PowerShell я затем вывожу эти три элемента в некий текстовый файл, котороый расположен на жёстком диске моего сервера.

Если я выполню данный сценарий несколько раз, после этого я могу открыть свой файл UserReporting.txt и увидеть что при каждом исполнении моего сценария он успешно регистрирует определённые мной переменные в данном файле отчёта:

Если быть честным, собрав воедино этот простой маленький сценарий, мы всего лишь осуществили выполнение нескольких попыток. У меня не было некоторой доступной для прочтения его копии, и мне потребовалось проверить пару этих строк по отдельности в PowerShell, прежде чем я удостоверился что он будет работать в моём сценарии. Я также попытался вытащить имя пользователя не применяя переменную окружения, а это не сработало. Почему я испытываю столько трудностей в сборе воедино таких простых строк кода? Потому что я набирал эти строки в Notepad, у меня абсолютно не было понимания будут они работать или нет когда я сохранил их и попробовал исполнить данный сценарий. Весь текст был просто чёрным на белом фоне, и я полностью доверился своим собственным знаниям и способностям составления сценария чтобы совместить нечто что на самом деле работает.

К счастью, у нас имеется доступ к PowerShell ISE (Integrated Scripting Environment, Интегрированной среде сценариев). Это программа которая по умолчанию устанавливается в Windows Server 2016, это оболочка сценария которая позволяет вам писать сценарии PowerShell и помогает вам на всём их пути. Давайте пройдём далее и откроем её. Если вы кликните правой кнопкой по самой иконке PowerShell, вы обнаружите опцию запуска Windows PowerShell ISE прямо в этом меню:

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

Также полезен синий мини-экран PowerShell, который занимает нижнюю часть окна разработки внутри ISE. В основном, когда вы вводите некие команды в верхнем пространстве, то что происходит, так это подсказки вам от ISE помогает вам удостовериться, что они будут работать, цветовыми кодами вводимых cmdlet и параметров для их более простой идентификации, а затем вы можете кликнуть по зелёной стрелке в верхней панели задач, которая помечена как Run Script (Выполнить сценарий). Даже если вы ещё не сохранили где- либо свой сценарий, ISE запустит ваши команды и предоставит ниже в окне приглашения PowerShell результаты. Это позволяет нам проверять свой сценарий, либо проверять изменения, которые вы вносите в некий существующий сценарий, без необходимости сохранять такой файл и затем запускать его отдельно из реального окна PowerShell:

Ещё лучше то, что вы имеете возможность выделения отдельных разделов своего сценария и выбирать запуск только отдельных фрагментов кода. Это позволяет вам проверять отдельные разделы сценария или же делать нечто творческое, например, сохранять один большой файл сценария PS1 наполненным распространёнными командами PowwerShell, которые вы повседневно можете применять, а когда вам требуется выполнять только одну из них, вы можете просто выделить необходимый текст, который вы и желаете запустить, а затем щёлкнуть по кнопке Запуска выбранного (F8, RunSelection). Выделяя текст перед запуском сценария изнутри ISE, у вас будут задействованы лишь выделенные cmdlet. На приводимом далее снимке экрана вы можете наблюдать, что в моём фкайле сценария перечислено множество cmdlet, но был исполнен только выделенный:

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

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

Существует всего пара элементов, которые необходимо иметь работающими и включёнными на ваших удалённых серверах чтобы позволить проникнуть вашему PowerShell в них с другой машины. Если все ваши сервера Windows Server 2019, а на самом деле, даже если они все Windows Server 2012 и выше, тогда удалённый PowerShell включён по умолчанию и вы можете пропустить пару следующих разделов здесь. Однако, если вы попытаетесь воспользоваться PowerShell удалённо, а он не будет работать у вас, будет важным, чтобы вы понимали как он устроен под капотом. Таким образом вы сможете найти в нём неисправности и вручную установить удалённые возможности в случае, если вы столкнётесь с проблемами, либо работаете на более старых операционных системах, в которых данные шаги могут быть необходимыми. Также возможно, что у вас уже есть существующие политики безопасности, которые отключают компоненты, применяемыми возможностями удаленного подключения PowerShell, поэтому, если вы обнаружите, что ваш удалённый доступ заблокирован, это именно те элементы, которые необходимо изучить в этих системах.

Служба WinRM

Одним из фрагментов вашей мозаики удалённого управления является служба WinRM. Просто убедитесь, что эта служба работает. Если вы имеете её остановленной по какому- то из видов предпочтений защиты или безопасности, вам необходимо вернуть эти изменения обратно и сделать эту службу опять поднятой и исполняющейся чтобы применять PowerShell удалённо.

Вы, конечно, можете проверить состояние своей службы WinRM из services.msc, либо, поскольку мы пользуемся в данной главе PowerShell, вы можете убедиться в этом следующей командой:

Get-Service WinRM
 	   

Enable-PSRemoting

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

Enable-PSRemoting -Force
		

Применение -Force в конце команды Enable-PSRemoting вызывает раскатку команды без запросов на подтверждения. Имеется несколько различных моментов, которые Enable-PSRemoting выполняет здесь в фоновом режиме. Во- первых он пытается запустить имеющуюся службу WinRM. Зачем я уже сказал что вы должны проверять вручную? по той причине, что если он отключён как часть стратегии блокировки вы будете вмешиваться в это процесс. WinRM до применения Enable-PSRemoting увеличивает шансы на успех при запуске самого cmdlet Enable-PSRemoting. Есть ещё два других момента, выполняемых этой командой: запуск процесса ожидания для удалённых подключений и создание некого правила межсетевого экрана в системе для того чтобы разрешить обмену успешно проистекать.

Если вы пытаетесь применять PowerShell удалённо в крупном масштабе, стоит подумать о регистрации в каждом обособленном серервере и запуске этой команды. К счастью, вам это не требуется! Как и в случае с большинством функций из мира Microsoft, мы можем применить Групповую политику для автоматического внесения этих изменений. Создайте новый объект Групповой политики (GPO), скомпонуйте и отфильтруйте его соответствующим образом чтобы он применялся только к тем серверам, для которых требуется централизованное управление, а затем настройте такую установку: Computer Configuration | Policies | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service.

Установите Allow remote server management through WinRM в Enabled следующим образом:

Допуск машин из других доменов и рабочих групп

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

Set-Item wsman:\localhost\client\trustedhosts Win10Client
		

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

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

При помощи –ComputerName

Многие доступные в PowerShell cmdlet, в частности те, которые начинаются с Get-, могут применяться с имеющимся параметром –ComputerName. Это определяет, что данная команда, которую вы намереваетесь исполнить, должна быть выполнена на удалённой системе, которая определяется в разделе –ComputerName. Для нашего примера удалённого PowerShell, я воспользуюсь приглашением PowerShell на своём компьютере клиента Windows 10 для доступа к информации на одном из своих серверов в моей сетевой среде. Я хочу выполнить запрос к своей службе WinRM чтобы убедиться что она поднята и исполняется. Для этой цели я выполняю удалённое подключение к WEB3, причём вы видите в получаемом выводе, что я для начала выполнил опрос своей локальной службы WinRM, которую я случайно отключил в своей рабочей станции Win10.

Вы видите, что моя локальная служба WinRM отображается как Stopped, однако когда я вызываю ту же самую команду для определения запроса ComputerName на WEB3, он достигает его и выдаёт отчёт мне что необходимая служба WinRM, тем не менее, успешно Running в этом сервере WEB3:

Hostname
Get-Service WinRM
Get-Service WinRM -ComputerName WEB3
 	   

В качестве альтернативы я, возможно, захочу увидеть все установленные на WEB4 в настоящий момент роли:

Get-WindowsFeature –ComputerName WEB4 | Where Installed
 	   

Параметр –ComputerName может даже одновременно принимать множество имён серверов. Если я желаю проверить состояние службы WinRM на нескольких своих серверах применив одну команду, я могу сделать нечто навроде этого:

Get-Service WinRM –ComputerName WEB1,WEB2,DC1
 	   

При помощи Enter-PSSession

С другой стороны, иногда у вас имеется множество различных cmdlet, которые вы бы хотели выполнить на определённом сервере. В данном случае, имеет больший смысл вызвать полную возможность, весь экземпляр удалённого PowerShell на такой удалённый сервер. Если вы откроете PowerShell в своей локальной системе и примените cmdlet Enter-PSSession, ваше приглашение PowerShell будет полностью удалённо представлять PowerShell на таком удалённом сервере. Затем у вас появляется возможность выполнять в этом приглашении команды, причём они будут исполняться так, если бы вы располагались в приглашении PowerShell в консоли этого сервера. Опять же, я регистрируюсь на своём клиентском компьютере Windows 10 и открываю PowerShell. После этого я применяю следующую команду для удалённого соединения со своим сервером WEB4:

Enter-PSSession –ComputerName WEB4
 	   

Вы отметите изменение своего приглашения, состоящее в том, что я теперь работаю в контексте своего сервера WEB4.

Команды, которые я буду исполнять начиная с этого момента и далее будут выполняться на WEB4. Давайте убедимся в этом. Если я просто проверю $env:computername, вы можете ведеть, что она представляет мне имя хоста WEB4:

И чтобы ещё больше убедиться в этом, если я проверю установленные на нём роли и свойства Windows, вы сможете увидеть, что у меня в распоряжении установленная роль Web Сервера, а также Отказоустойчивый кластер (Failover Clustering) из ранних глав данной книги. Совершенно очевидно, что эти элементы не установлены на моей машине Windows 10, PowerShell вытаскивает эти данные с моего сервера WEB4:

Get-WindowsFeature | Where Installed
 	   

Это достаточно мощный пример. Мы располагаемся за своим локальным настольным компьютером, имеем некий удалённый сеанс PowerShell, исполняющийся на нашем сервере WEB4, и теперь имеем возможность вытаскивать все виды информации из WEB4, так как это в точности так, если бы мы работали в PowerShell прямо на этом сервере. Давайте пройдём ещё дальше и попытаемся изменить настройки в WEB4, просто чтобы проверить что мы можем это. Может быть мы сможем установить новую функциональность на такой сервер. Я иногда применяю клиента Telnet, однако вижу, что в настоящий момент он не установлен на WEB4:

Get-WindowsFeature –Name *telnet*
 	   

Применив cmdlet Add-WindowsFeature, я должен буду иметь возможность быстро выполнить работу по установке этой функциональности:

Add-WindowsFeature Telnet-Client
 	   

Данная возможность PowerShell является мощным напонителем, причём не только для ваших серверов с полностью накачанным графическим интерфейсом Практики Рабочего стола, но также и для взаимодейтсвия с вашими сосредоточенными на безопасности развёртываниями Сервера ядра. Ознакомдение с работой сеансов PowerShell будет существенным для успеха оснащения Сервера ядра в вашей инфраструктуре.

Существует также некая новая и мощная функциональность в PowerShell, предоставляемая чем- то с названием DSC (Desired State Configuration, Настройка нужного состояния). DSC является некоторой подключаемой к PowerShell платформой управления, которая предоставляет какие- то новые функции и cmdlet, которые могут использовать в своих интересах ваши сценарии чтобы включить некоторые по- настоящему крутые свойства. Как подразумевает само название, она делает возможной встраивание настроек вовнутрь PowerShel, которые будут предоставлять желаемое состояние (desired state). Что я имею в виду под этим? Ну, в общем смысле, то,что делает DSC, так это то, что она гарантирует что построенные вами сценарии PowerShell всегда будут работать одним и тем же образом, причём в любых серверах, к которым они применяются. Достаточно просто построить некий сценарий таким образом, чтобы он правильно исполнялся на сервер, на котором вы в настоящее время работаете, однако если вы попробуете накатить тот же самый сценарий на другом сервере, который может располагаться в другом Подразделении (OU), или иметь иметь отличающиеся элементы установленными на нём для начала, такой сценарий может производить другие результаты в сравнении с теми, для которых он предназначался. DCS был создан для противодействия подобным отличиям.

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

DSC также помогает предотвращать нежелательные изменения на серверах. Если ваш сценарий с включённой поддержкой DSC определит, что конкретная служба должна исполняться на протяжении всего времени на ваших серверах, и эта служба останавливается по какой- то причине, DSC в этом случае может помочь раскрутить назад ей с тем, чтобы вы не испытывали неких потерь. Наоборот, допустим, у вас имеется сценарий, который настраивает сервер на определённый набор стандартов, а другая персона из обслуживающего персонала ИТ приходит и выставляет эти настройки на сервере под себя - возможно, он регистрируется и останавливает целенаправленно останавливает данную службу по некоторой причине. Именно в этих ситуациях DSC может вмешиваться и устанавливать сервер обратно в нужное состояние, в котором он находился первоначально. DSC является вашей няней сценариев, образно выражаясь. Она помогает строить конфигурации, которые будут оставаться единообразными на множестве платформ, и будет затем работать над обеспечением того, чтобы такие настройки всегда оставались верными. После этого вы можете пребывать в уверенности, что ваши серверы всегда работают внутри контекста, который вы определили в качестве желаемого состояния.

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

Окончательной целью DSC является сохранение всего постоянным и согласованным по всем серверам и службам. Возможности и доступ DSC для обогащения всё большего и большего числа мест в операционной системе постоянно растёт, поскольку роли переписываются для принятия параметров и наблюдения DSC. Окончательно, и я верю что это будет целью Microsoft, чтобы каждый сервер, исполняющий сценарий настройки DSC, гарантировал, что он постоянно работает внутри ваших стандартов и помогает поддерживать 99.999% рабочего состояния.

Существует очень много материалов по DSC, которые можно изучать, и я побуждаю вас исследовать эту тему ещё, раз уж вы знакомы с созданием и применением сценариев PowerShell. Вот некторые великолепные отправные точки для чтения по теме Настроек желаемого состояния:

В Windows Server 2019 мы наблюдаем множество мест, в которых выполнение задач администрирования при помощи PowerShell является рекомендуемым способом взаимодействия с вашими серверами. Факт состоит в том, что GUI управления всего лишь являются оболочками, исполняющими сценарии PowerShell и что в скором будущем опцией по умолчанию для установки Windows Server является Сервер ядра, так как мы можем предположить что выхолощенные (headless), ориентированные на командную строку сервера станут нашими основными серверами. Даже хотя PowerShell на самом деле входит в состав ядра функциональности нашей операционной системы начиная с Server 2012, до сих пор я полагаю, что большинство администраторов рассматривают PowerShell в качестве альтернативного варианта управления серверами. Да, я знаю это имеет место, и я должен начать при менять его, и сами сценарии выглядят просто шикарно, однако я всё ещё могу выполнять всё что пожелаю в старой командной строке или своей кнопкой мыши. Такое старое понимание быстро меняется.

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