Глава 14. Устранение неисправностей при помощи PowerShell

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

Существует три широких класса проблем с которым вы сталкиваетесь:

Синтаксические ошибки чрезвычайно распространены - в особенности когда вы набираете на клавиатуре не очень хорошо. Запросто можно набрать Get-ChildTiem вместо Get-ChildItem. Хорошая новость состоит в том, что пока вы не разрешите свои синтаксические ошибки, ваш сценарий не способен запускаться успешно. Существует несколько способов избежания синтаксических ошибок и упрощения соответствующей задачи их нахождения и удаления. Один из простейших способов состоит в применении хорошего редактора кода, например, VS Code. Точно так же как и Microsoft Word, VS Code выделяет потенциальные синтаксические ошибки чтобы помочь вам выявить их, исправить и устранить.

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

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

У вас может иметься работающая система или служба, которая, если вам не повезёт, при некоторых обстоятельствах, может превращаться в проблематичную. Best Practices Analyzer позволяет вам изучать ядро служб Windows чтобы гарантировать вам их работу наилучшим из возможных способов.

Вы также можете сталкиваться с ошибками времени исполнения. Например, ваш сценарий добавления и настройки некого пользователя в вашем AD сталкивается с проблемой времени исполнения. Соответствующая служба в DC (domain controller, контроллере домена) может рухнуть, ваш NIC (network interface controller, контроллер сетевого интерфейса) в вашем DC способен отказывать или же установленный сетевой путь от пользователя к его контроллеру домена может обладать отказавшим маршрутом или же он снабжён неверной таблицей маршрутизацией. Проверка сетевого соединения гарантирует что имеющийся сетевой путь от вашего пользователя к соответствующим серверам работает как требуется. Однако вам также потребуется обеспечить что ваша сетевая конфигурация сама по себе верна.

Решение сетевых проблем, помимо базового подключения может представлять вызов для их разрешения, поскольку может возникать большое число потенциальных проблем. Многие из проблем просты в диагностике и их разрешении. Вы можете найти их в нашем рецепте Устранение сетевых неисправностей. Для решения более сложных проблем вам может потребоваться более подробное изучение вашего сетевого стека для получения дополнительных подробностей. Для получения гигантского числа сведений по устранению ошибок полезны модуль и командлет Get-NetView, которые сетевые профессионалы могут применять для разрешения проблем.

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

PowerShell Script Analyzer это модуль PowerShell, производимый командой PowerShell, который анализирует ваш код и предоставляет возможности для улучшения. Вы можете выгрузить самую последнюю версию этого модуля из Галереи PowerShell.

Когда для разработки своего кода вы пользуетесь редактором VS Code, вам следует знать, что Script Analyzer встроен в VS Code. Итак, по мере разработки вами своего сценария PowerShell, VS Code выделяет все те ошибки, которые выявляет Script Analyzer. Таким образом, VS Code помогает вам сразу писать код лучше.

Другой функциональной возможностью PowerShell Script Analyzer является его способность повторного форматирования кода PowerShell для лучшей читабельности. У вас имеется множество установок, которые вы можете настраивать чтобы сообщать Script Analyzer как ему надлежит повторно форматировать ваш код.

Этот рецепт пользуется SRV1, присоединённому к домену хосту Windows Server 2022.

На Шаге 1 для обнаружения модуля PSScriptAnalyzer в Галерее PowerShell вы пользуетесь командой Find-Module. Получаемый вывод выглядит подобно приводимому ниже:

На Шаге 2 вы устанавливаете модуль PSScriptAnalyzer, что не производит вывод. На Шаге 3 для выявления команд внутри этого модуля вы пользуетесь командой Get-Command со следующим выводом:

PowerShell Script Analyzer применяет некий набор правил, которые определяют потенциальные проблемы с вашими сценариями. На Шаге 4 для изучения доступных типов правил вы пользуетесь Get-ScriptAnalyzerRule с подобным приводимому далее выводом:

Вы можете просмотреть одно из правил Script Analyzer, как это показано на Шаге 5 с примерно таким выводом:

На Шаге 6, который не производит консольного вывода, вы создаёте некий файл с проблемами, которые способен выявить Script Analyzer и предоставить вам решение этих проблем. На Шаге 7 вы проверяете вновь созданный файл сценария с подобным следующему выводом:

На Шаге 8 вы пользуетесь командой Invoke-ScriptAnalyzer для проверки файла C:\Foo\Bad.ps1 на потенциальные проблемы. Вывод с этого шага выглядит так:

Второй функцией Script Analyzer является переформатирование файла сценария для улучшения схемы расположения сценария. На Шаге 9 вы определяете простую функцию для её переформатирования. Этот шаг не выдаёт консольного вывода.

Представление того, что составляет хорошую схему расположения кода можно изменять. Script Analyzer позволяет вам определять настройки, которые руководят тем как вы желаете выполнять переформатирование соответствующего кода. На Шаге 10 вы определяете некие настройки правила, что не производит вывод.

На Шаге 11 вы активируете форматирование нашего сценария при помощи предписанных на нашем предыдущем шаге настроек. Вот вывод с этого шага:

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

На Шаге 1 вы просматриваете подробности относительно модуля PSScriptAnalyzer. Обратите внимание, что автор этого модуля на протяжении длительного времени был участником команды PowerShell. Что интересно, Джим выполнял некоторые демонстрации в самом начале, когда Microsoft показывала Monad (как тогда именовался PowerShell) на PCS осенью 2003.

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

Шаг 12 устанавливает некое правило, которое заставляет форматирование Script Analyzer помещать открывающую фигурную скобку блока сценария в отдельной строке. Есть разные мнения относительно того является ли это хорошим подходом. У вас всегда есть выбор. Имеются и прочие варианты форматирования, например, выравнивание символа = в наборе операторов присваивания и много прочих. Соответствующая документация для этих правил не особенно полезна, однако вы можете начать отсюда: https://www.powershellgallery.com/packages/PSScriptAnalyzer/1.19.1/Content/Settings%5CCodeFormatting.psd1.

Один из способов избежания осуществления устранения ошибок состоит в развёртывании ваших служб более безотказным или, по крайней мере, менее чувствительным к проблемам образом. Существует множество способов развёртывания вашей среды и работы с ней, причём некоторые из них явно лучше прочих. Например, наличие двух контроллеров домена, двух серверов DNS в интегрированных зонах AD, а также обладание двумя серверами DHCP в неком отказоустойчивом взаимодействии, что подразумевает, что вы можете сталкиваться с большим числом проблем в этих центральных службах и всё ещё развёртывать надёжную службу для конечных пользователей. Хотя вам всё равно может потребоваться устранение неполадок для решения любых проблем, ваши службы продолжат работу надлежащим образом, причём ваши пользователи и не узнают о некой проблеме.

Совместно с экспертами отрасли, MVP и другими специалистами, команды продукции Microsoft разработали рекомендации относительно того как вам следует развёртывать инфраструктуру Windows. Некоторые команды продуктов, например, Exchange, публикуют подробные инструкции и разработали автономные инструменты.

BPA (Best Practices Analyzer) Windows Server это встроенный инструментарий Windows Server, который анализирует ваши серверы на площадке для строгого соблюдения рекомендациям. Некие рекомендации это руководство, которое эксперты отрасли согласовали как наилучший способ настройки ваших серверов. Например, большинство экспертов AD рекомендует чтобы вы обладали по крайней мере двумя контроллерами домена в каждом домене. Однако для целей проверки среды это может оказываться избыточным. Таким образом, хотя рекомендации это то, к чему следует стремиться, порой они могут не соответствовать вашим потребностям. Тем самым, при рассмотрении результатов BPA следует пользоваться определённым взглядом.

Для Windows Server 2022 BPA поставляется с 14 моделями BPA. Каждая модель это набор правил, которые вы можете использовать для проверки своей среды. Команда AD собрала модель BPA для AD, Microsoft/Windows/DirectoryServices, которую вы можете исполнять для определения проблем с контроллером домена AD.

В этом рецепте вы создаёте в DC1 создаёте сеанс удалённого PowerShell. Для запуска командлетов BPA вы пользуетесь командлетом Invoke-Command, позволяя в данном рецепте анализировать соответствующую модель AD.

В этом рецепте применяется SRV1, присоединённый к домену Windows Server 2022 в домене Reskit.Org. Вам также потребуются для данного рецепта в рабочем состоянии контроллеры домена из Reskit.Org (DC1 и DC2).

На Шаге 1 в своём контроллере домена, DC1, удалённый сеанс PowerShell. Этот шаг не производит вывод. На Шаге 2 вы запускаете в DC1 команду Get-Module при помощи созданного удалённого сеанса. Вывод этого шага выглядит примерно так:

На Шаге 3 вы выявляете все содержащиеся в модуле BPA (из DC1) команды с подобным следующим выводом:

На Шаге 4 вы выявляете имеющиеся доступными в DC1 модели Вот как выглядит вывод:

На Шаге 5 для запуска модели BPA DirectoryServices в DC1 вы применяете команду Invoke-BpaModel. Активация этой модели производит некоторый минимальный вывод, примерно такой:

Для получения подробных результатов сканирования BPA вы пользуетесь командой Get-BpaResult, как вы это можете наблюдать на Шаге 6, который производит такой вывод:

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

На Шаге 6 вы выполняете выборку результатов сканирования, которые вы выполнили на нашем предыдущем этапе. Полученные результаты показывают три основополагающие проблемы:

Для некой среды проверок эти проблемы могут быть не важными для большинства частей и вы, вероятно, можете игнорировать их. Когда вы пользуетесь Hyper-V для тестирования ВМ, вы можете настроить Hyper-V на обновление локального времени этих виртуальных машин, по крайней мере для тех контроллеров домена, которые вы запускаете в ВМ. В тестовой среде обладание резервным копирование AD. А запуск контроллера домена в Hyper-V, по крайней мере для среды тестирования, это не проблема для самых последних поддерживаемых версий Windows Server.

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

В данном рецепте вы выполняете некоторые основные действия по устранению неполадок в локальном SRV1, присоединённом к домену хосте под управлением Windows Server 2022. Общая теория состоит в том, что любая сетевая проблема заключается в DNS (пока вы не докажете обратное). Вы начинаете данный рецепт с получения полного доменного имени (FQDN), fully qualifed domain name своего хоста и значения IP адреса его DNS сервера, а затем проверяете работает ли этот сервер DNS.

Затем вы применяете сконфигурированный сервер DNS на предмет определения значений имён Контроллеров домена в своём домене и убеждаетесь что способны достигать каждого Контроллера домена как по порту 389 (LDAP), так и по 445 (для GPO). Затем вы проверяете доступность шлюза по умолчанию. Наконец, вы тестируете возможность достижения удалённого хоста по порту 80 (http) и по порту 443 (HTTP поверх SSL/ TLS).

В большинстве случаев, эти запускаемые на поражённом хосте простые тесты должны помочь обнаружить вам некоторые из наиболее распространённых проблем.

Этот рецепт пользуется SRV1, присоединённым к домену хосту под управлением Windows Server 2022. В этом хосте вы установили PowerShell 7 и VS Code.

На Шаге 1 вы создаёте некую переменную для удержания значения FQDN своего хоста. Этот шаг не производит вывод.

На Шаге 2 вы пользуетесь Get-DNSClientServerAddress для получения IP адресов DNS серверов которые вы (или DHCP) сконфигурировали в этом хосте. Вот как выглядит этот вывод:

На Шаге 3 вы проверяете доступны ли настроенные DNS серверы с подобным приводимому ниже выводом:

На Шаге 4 вы определяете имя resource record (RR, записи ресурса) DNS для соответствующих записей SRV, зарегистрированных активными Контроллерами домена для заданного домена. Соответствующий вывод выглядит так:

На Шаге 5 вы выполняете выборку RR SRV для Контроллеров домена из своего домена. Каждая RR представляет некий сервер, который способен действовать в качестве Контроллера домена в домене Reskit.Org. Вот как выглядит вывод на этом шаге:

На Шаге 6 вы проверяете все выявленные Контроллеры домена на предмет связи по LDAP, что приводит к подобному выводу:

Для каждого агента Групповой политики хоста под выгрузку GPO из некого Контроллера домена этот хост пользуется неким подключением SMB к совместному ресурсу SYSVOL в соответствующем контроллере домена. На Шаге 7 вы проверяете возможность подключения к порту SMB 445 каждого Контроллера домена. Вот как примерно выглядит вывод с этого шага:

На Шаге 8 вы проверяете способен ли ваш хост достигать своего настроенного по умолчанию шлюза. Вывод с этого шага отображается примерно так:

На Шаге 9 вы проверяете можно ли достигать внешний хост на основе Интернета при помощи ICMP (синоним ping). Вот что мы получаем в выводе:

На Шаге 10 вы проверяете можете ли вы достигать тот же самый сервер через порт HTTP, порт 80, со следующим выводом:

На Шаге 11 вы проверяете можете ли вы достигать тот же самый сервер через порт HTTP поверх SSL/ TLS, порт 443, с таким выводом:

На Шаге 1 вы создаёте переменную для содержания значения FQDN своего хоста. Вы можете пожелать применять её для обеспечения того что ваш хост надлежащим образом регистрирует FQDBвашего хоста в соответствующем сервере DNS. Когда вызывает проблемы неверная регистрация, вы можете пожелать адаптировать этот сценарий на проверку правильной регистрации RR DNS.

На Шаге 4 вы создаёте название RR DNS, которое вы будете применять далее, на Шаге 5, для запроса всех записей SRV с этим именем. AD применяет DNS в качестве службы локации - каждый Контроллер домена регистрирует записи SRV для предания гласности его доступности в качестве службы Контроллера домена. Такая запись SRV содержит название FQDN представляемого Контроллера домена. Служба Windows Netlogon в Контроллере домена регистрирует все соответствующие записи SRV всякий раз при запуске такой службы, либо каждые 24 часа. Одной из технологий устранения неисправностей служит применение Restart-Service для перезапуска службы Netlogon в каждом Контроллере домена.

Когда вы обладаете крупной сетевой средой с маршрутизацией, вы можете пожелать перейти к проверке своего шлюза по умолчанию, выполняемую тут на Шаге 8 на более ранний этап для промышленной версии этого рецепта, возможно, перед Шагом 3. Когда вы не можете достигать своего шлюза по умолчанию, а ваши сервер DNS и Контроллеры DNS пребывают в различных подсетях, более ранние этапы, скорее всего завершатся отказом по причине проблемы шлюза по умолчанию.

На Шаге 9, Шаге 10 и Шаге 11 вы проверяете связь с удалённым хостом поверх ICMP и портов 80 и 443. Некий хост или какой- то промежуточный маршрутизатор способны обрывать обмен ICMP, при этом допуская во многих случаях обмен по 80/443. Поэтому, просто когда не выполняется ping до необходимого предложенного пункта, либо вовсе отказывает - это может быть спланированным вариантом согласно архитектуре.

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

Get-NetView это инструмент, который собирает подробности относительно вашей сетевой среды, которые способны помочь вам в решении сетевых проблем.

Модуль Get-NetView содержит единственную функцию, Get-NetView. Когда вы запускаете эту команду, она вытаскивает воедино гигантский диапазон сведений о сетевой среде и создаёт некий ZIP файл, содержащие подробности жизнеспособности относительно вашей сетевой среды. По умолчанию, Get-NetView создаёт этот вывод на вашем рабочем столе.

Вывод Get-NetView содержит следующие подробности:

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

Данный рецепт пользуется SRV1, присоединённым к домену хостом Windows Server 2022 . На этом хосте вы обладаете установленными PowerShell 7 и VS Code.

На Шаге 1 вы отыскиваете в Галерее PS модуль Get-NetView. Вот как примерно выглядит вывод с этого шага:

На Шаге 2 вы устанавливаете самую последнюю версию этого модуля, что не производит вывод. <На Шаге 3 вы проверяете какая версия (или версии) модуля Get-NetView располагаются в SRV1, что создаёт такой вывод:

На Шаге 4 вы импортируете модуль Get-NetView. На Шаге 5 вы создаёте в устройстве C:\ новую папку, которая будет содержать вывод, производимый Get-NetView. Эти шаги не производят вывод.

На Шаге 6 вы запускаете Get-NetView. На каждом конкретном шаге соответствующая команда регистрирует некоторые сведения о сетевой среде и выводит комментарии исполнения. Эта команда производит великое множество вывода, некое подмножество которого выглядит следующим образом:

На Шаге 7 вы просматриваете папку вывода на предмет тех файлов, которые создал Get-NetView, с подобным следующему выводом:

На Шаге 8 вы просматриваете подробные сведения, созданные Get-NetView со следующим выводом:

На Шаге 9 вы изучаете выработанную Get-NetView конфигурацию IP, которая выглядит так:

На Шаге 3 вы проверяете версию (версии) модуля Get-NetView в своей системе. В данном случае, вы можете наблюдать версию 1.0, которой снабжается соответствующая редакция Windows Server (запущенного в SRV1), а также самую последнюю версию, полученную из Галереи PowerShell. На этом шаге вы устанавливаете данный модуль вместо его обновления. Вы не можете обновлять установочные версии какого бы то ни было модуля до тех пор и пока вы не установите её в явном виде. Затем, продвигаясь далее, вы можете воспользоваться Update-Module для получения любых обновлений.

На Шаге 7 вы просматриваете выведенные Get-NetView файлы. Как вы можете наблюдать, в этой папке вывода имеется некая папка и файл архива ZIP. Get-NetView добавляет все сетевые сведения в отдельный файлы в этой папке вывода и затем сжимает все эти сведения в единственный файл архива, который вы можете отсылать техническим специалистам сетевой среды для разрешения проблем.

На Шаге 9 вы просматриваете один из множества фрагментов сведений, созданных Get-NetView. В данном случае вы просматриваете сведения о конфигурации IP, включая значение IP адреса, маску подсети и шлюз по умолчанию. Занимательно, что этот разработчик применяет ipconfig.exe для создания этих сведений без применения переключателя /all. Это означает, что вы не можете наблюдать в данном выводе имеющиеся настройки адресов IP серверов DNS.

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

Когда PowerShell встречает точку прерывания, он приостанавливает обработку и представляет вам отладочное приглашение на ввод, как вы обнаружите в данном рецепте. Затем вы можете изучить полученные до сих пор результаты и выполнить дополнительные команды чтобы чтобы убедиться что ваш сценарий производит ожидавшийся вами вывод. Когда ваш сценарий добавляет некого пользователя в установленный AD, а затем исполняет с этим пользователем некое действие (например, добавление этого пользователя в группу), вы имеете возможность останавливать свой сценарий сразу после выполненной команды Add-ADUser. В этот момент вы можете применить команду Get-ADUser или иную команду для проверки добавил ли ваш сценарий такого пользователя ожидаемым образом. Затем вы можете воспользоваться оператором continue для восстановления работы своего сценария. PowerShell далее продолжит исполнение вашего сценария пока не завершится или не встретит вновь точку прерывания.

Данный рецепт пользуется SRV1, подключённым к домену хоста контроллера из вашего домена Reskit.Org. Вы уже установили в этом хосте PowerShell 7 и VS Code.

На Шаге 1 вы создаёте какой- то сценарий, который позволит вам изучить отладку сценария PowerShell. На Шаге 2 вы сохраняете этот файл на устройстве C:. Эти шаги не производят вывод.

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

На Шаге 4 вы устанавливаете точку прерывания своего сценария в определённой строке. На Шаге 5 вы настраиваете другую точку прерывания, на этот раз при каждом вызове конкретной команды Get-CimInstance. На Шаге 6 вы настраиваете точку прерывания на останов при каждой записи в заданную переменную $M. Установка этих трёх точек прерывания не производит никакого вывода (поскольку вы конвейером отправляете вывод соответствующей команды в Out-Null).

На Шаге 7 Вы просматриваете те точки прерывания, которые вы установили на данный момент в текущем сеансе PowerShell. Данный вывод выглядит так:

Обладая тремя взведёнными точками прерывания, на Шаге 8 вы запускаете свой сценарий. PowerShell останавливает исполнение по достижению самой первой точки прерывания (в строке 4 этого сценария) со следующим выводом:

В получаемом приглашении на ввод DBG вы можете ввести любую команду PowerShell, например, просмотреть текущее значение переменной $J, ч то вы и исполняете на Шаге 9. Вот что вы получаете:

На Шаге 10 вы просматриваете текущее значение переменной $K. Поскольку PowerShell прекратил исполнение до того как он способен записать значенеи в этой переменной, этот шаг не отображает никакого значения и вот что вы можете наблюдать:

Для продолжения выполнения сценария, на Шаге 11 вы набираете continue, что производит вывод, подобный приводимому ниже:

Как и на нашем предыдущем шаге, вы можете изучить выполненные на данный момент действия нашего сценария. Вы продолжаете данный сценарий, набрав continue на Шаге 12 подобным образом:

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

На Шаге 4 вы устанавливаете точку прерывания в строке, указывая PowerShell на необходимость останова по достижению им этой конкретной строки (и столбца) из нашего сценария. На Шаге 5 вы устанавливаете точку прерывания команды, сообщая PowerShell о необходимости прерываться всякий раз, когда ваш сценарий активирует определённую команду, в данном случае Get-CimInstance. На Шаге 6 вы устанавливаете точку прерывания переменной - вы запрашиваете у PowerShell останов при каждом считывании или записи этой конкретной переменной.

На Шаге 8 вы исполняете этот снаряжённый сценарий, который прерывается в своей первой точке прерывания. В своей консоли прерывания, как вы наблюдаете на Шаге 9, вы можете просматривать значение любой переменной, например, $J. При отладке вам приходится задавать себе вопрос является ли наблюдаемое вами значение тем, которое вы ожидали обнаружить. На Шаге 10 вы также просматриваете значение $K. Поскольку PowerShell ещё пока не обработал соответствующий этап назначения, данная переменная не обладает никаким значением.

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

После того как вы продолжите снова, ваш сценарий достигнет заключительной точки прерывания, сразу перед тем как PowerShell активирует Get-CimInstance и назначит его вывод в $BIOS. Из своей отладочной консоли вы можете активировать соответствующий командлет чтобы проверить что вывод тот что и требовался.

Окончательно, на Шаге 13 вы продолжаете исполнение до завершения своего сценария. Обратите внимание, что вы не видите обычного приглашения на ввод PowerShell.

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