Модули диагностики в Powershell, часть 2.

Всем привет.


Продолжаем тему модулей диагностики в Powershell.

2. Module PSDiagnostics.

                                                            

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

 

Запрос Get-Command -Module PSDiagnostics нам выдаст список из 10-ти функций:

Disable-PSTrace, Disable-PSWSMan CombinedTrace,

Disable-WSManTrace, Enable-PSTrace,

Enable-PSWSManCombinedTrace,

Enable-WSManTrace, Get-LogProperties,

Set-LogProperties, Start-Trace и Stop-Trace

 

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

Итак, что делают функции модуля PSDiagnostics? Обычно, для нахождения подобной информации используется Get-Help. Ниже приведен вывод справки для функции Enable-PSTrace.

PS C:\> help Enable-PSTrace

NAME

    Enable-PSTrace

SYNTAX

    Enable-PSTrace [-Force] [-AnalyticOnly]

ALIASES

    None

REMARKS

    None

 

Да… Понятнее не стало. Однако, одна их отличных вещей, касающихся функций в Windows PowerShell – это диск Function:. Таким образом я могу увидеть содержимое функции и определить, что же она делает.

Итак, что же делает функция Enable-PSTrace? Она вызывает функцию Set-LogProperties и передает ей либо журналы аналитики Windows PowerShell, либо журналы аналитики вместе с журналами отладки, чтобы они были включены. Таким образом, нам нужно посмотреть на код функции Set-LogProperties и определить, что она делает.

 

Функция Set-LogProperties несколько длиннее, но одна вещь видна четко – функция вызывает Wevtutil и включает логи. Она также устанавливает параметры резервного копирования журнала, его максимальный размер и прочие вещи.

 

Функция Get-LogProperties отображает информацию о различных диагностических журналах.

PS C:\> Get-LogProperties Microsoft-Windows-PowerShell/Admin

Name       : Microsoft-Windows-PowerShell/Admin

Enabled    : True

Type       : Admin

Retention  : True

AutoBackup : False

MaxLogSize : 1048985600

 

 

К сожалению, она не поддерживает символы подстановки. 

Естественно, я могу получить имена журналов из утилиты EventViewer. Все что мне нужно для этого сделать – это щелкнуть правой кнопкой мыши на журнале, выбрать Properties – и я могу скопировать имя журнала в буфер.

  

Но все таки это же PowerShell.

 

И мне не обязательно указывать длинные и запутанные имена журналов, поскольку я могу воспользоваться командлетом Get-WinEvent для определения имен журналов Windows PowerShell, и передать их функции Get-LogProperties.

PS C:\> Get-WinEvent -ListLog *powershell* | Foreach {Get-LogProperties $_.logname}

Name       : Windows PowerShell

Enabled    : True

Type       : Admin

Retention  : False

AutoBackup : False

MaxLogSize : 15728640

Name       : Microsoft-Windows-PowerShell/Admin

Enabled    : True

Type       : Admin

Retention  : True

AutoBackup : False

MaxLogSize : 1048985600

Name       : Microsoft-Windows-PowerShell/Operational

Enabled    : True

Type       : Operational

Retention  : False

AutoBackup : False

MaxLogSize : 15728640

 

Если мне нужна информация только об одном журнале, я могу воспользоваться командлетом Where-Object для фильтрации результатов.

 PS C:\> Get-WinEvent -ListLog *powershell* | where logname -match admin | %{Get-LogProperties $_.logname}

Name       : Microsoft-Windows-PowerShell/Admin

Enabled    : True

Type       : Admin

Retention  : True

AutoBackup : False

MaxLogSize : 1048985600

 

Если вы думаете, почему я использую функцию Get-LogProperties вместо командлета Get-WinEvent, то вот его выходная информация:

PS C:\> Get-WinEvent -ListLog *powershell* | where logname -match admin

LogMode   MaximumSizeInBytes RecordCount LogName

Retain            1048985600           0 Microsoft-Windows-PowerShell/Admin

 

Обе команды показывают метод сохранения данных и максимальный размер файла. Но функция Get-LogProperties также сообщает мне включен ли журнал, а также включено ли резервное копирование.

А что же делают остальные функции модуля?

Далее я опираюсь и часто цитирую материал книги "Secrets of PowerShell Remoting", авторов Don Jones and Dr. Tobias Weltner из раздела "Diagnostics and Troubleshooting" (2012).

 

Авторы кинги заявляют что поиск и устранение неисправностей и диагностика в Powershell Remoting может быть одной из самых сложных задач для администратора. Когда Remoting работает, то он работает, но когда с ним проблемы то часто бывает трудно сходу объяснить что пошло не так. Вот как раз для диагностики этого и используют функции модуля PSDiagnostics. Вот оно! По сути, модуль позволяет нам включить подробную информацию журнала трассировки, прежде чем пытаться инициировать само соединение Remoting. Затем можно использовать подробную информацию из журнала, чтобы лучше понять, где происходит сбой Remoting.

 

Начало традиционное, с импорта модуля PSDiagnostics:

ipmo PSDiagnostics

Enable-PSWSManCombinedTrace

 

Команда PSWSManCombinedTrace, которая запускает расширенную диагностику. Для каждого сценария выполянются команды, которые имееют отноешние к Remoting Затем отслеживание отключается командой Disable-PSWSManCombinedTrace, чтобы журнал содержал детали из сессии dc01:

Enter-PSSession dc01

[dc01]: dir

[dc01]: cd ..

[dc01]: exit

Disable-PSWSManCombinedTrace

 

Наконец, как показано на рисунке, мы получили сообщения из журнала.

 

Информация о трассировке хранится в папке установки PowerShell (запустите cd $pshome, чтобы попасть туда, затем перейдите в папку "Traces"). Обычно папка здесь C:\Windows\System32\WindowsPowerShell\v1.0\Traces.

 

Для расширения имени файла .ETL вы можете использовать  Get-WinEvent -path имя_файла.etl для чтения файла.

 

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

Они подробно исследовали журнал Microsoft-Windows-WinRM. Чтобы получить содержимое журнала в удобочитаемом виде, они использовали внутренние утилиты Microsoft wevtutil.exe и logman.exe.

Собственно исходники эксперимента я видел здесь:

Construct-PSRemoteDataObject.ps1

psdiagdemo.ps1

 

Вот их демо-скрипт psdiagdemo.ps1 с коментариями, аналитике поддаются события с кодами 32868 и 32867:

# PSDiagnostics: Utilities to enable/disable PSRP eventlog entries and set/get log properties

# All the utilities use wevtutil.exe or logman.exe

# ETW  - Event Tracing for Windows

# PSRP - PowerShell Remoting Protocol

# see what logs are available for PSRP and WSMan

7 eventvwr

# Import-Module

8 ipmo psdiagnostics

# Get-Command

9 gcm -module psdiagnostics

10 Get-LogProperties Microsoft-Windows-PowerShell/Operational

11 Get-LogProperties Microsoft-Windows-PowerShell/Analytic

# Start tracing .....

12 Enable-PSWSManCombinedTrace

# New-PSSession

13 $s = nsn

# Get-PSSession | Remove-PSSession

14 gsn | rsn

# Finish tracing .....

15 Disable-PSWSManCombinedTrace 

16 dir $pshome\traces

# Get-Command

17 gcm get-winevent -syn

18 get-winevent -path $pshome\traces\pstrace.etl -oldest

19 get-winevent -path $pshome\traces\pstrace.etl -oldest | ? { $_.id -eq '32868' }

20 get-winevent -path $pshome\traces\pstrace.etl -oldest | ? { $_.id -eq '32868' } | % { $_.message }

21 . C:\temp\Construct-PSRemoteDataObject.ps1

22 get-winevent -path $pshome\traces\pstrace.etl -oldest  | ? { $_.id -eq '32868' } | % { $idx = $_.message.indexof("Payload Data: 0x"); $str = $_.message.substring($idx + ("Payload Data: 0x".length));Construct-PSRemoteDataObject $str }

23 del $pshome\traces\pstrace.etl

24 # lets try another scenario

# Start tracing .....

25 Enable-PSWSManCombinedTrace

# Invoke-Command

26 icm . { 1..10 }

# Finish tracing .....

27 Disable-PSWSManCombinedTrace 

28 get-winevent -path $pshome\traces\pstrace.etl -oldest | ? { $_.providername -match "powershell" } | select id,message

29 get-winevent -path $pshome\traces\pstrace.etl -oldest  | ? { $_.id -eq '32867' } | % { $idx = $_.message.indexof("Payload Data: 0x"); $str = $_.message.substring($idx + ("Payload Data: 0x".length));Construct-PSRemoteDataObject $str }

30 del $pshome\traces\pstrace.etl

Вы сможете точно увидеть что WinRM обменивается пакетами. Они отправляются через протокол простого доступа к объектам, поэтому ожидайте увидеть часто слово «SOAP». WSMan - это же web-сервис, и протокол SOAP - это язык общения таких web-сервисов.

 

3. Module TroubleshootingPack.

 

Запрос Get-Command -Module TroubleshootingPack

нам выдаст список из всего 2-х командлетов:

Get-TroubleshootingPack и Invoke-TroubleshootingPack

 

Что именно подлежит диагностике находится в C:\Windows\diagnostics\

Из полученной информации я сделал вывод что эти командлеты могут работать в паре.

 

Например так:

PS C:\Users\Admin> Get-TroubleshootingPack C:\Windows\diagnostics\system\device | Invoke-TroubleshootingPack -Verbose

 

 

Далее следует запрос устройства для диагностики.

Введите код PnP устройства, неполадки с которым необходимо устранить.

:00001

Проверка наличия драйвера...

Проверка подключенности устройства...

Проверка наличия проблем в работе драйвера...

Проверка состояния устройства...

Проблемы не обнаружены

Это все. Надо полагать так выполняется внутренняя диагностика аппаратного обеспечения (драйвера).

Что за код устройства "0001" точно сказать не могу. Я его ввел для эксперитимента.)

На этом пока все.

 

Итак по модулям диагностики  итог следующий:

• PSDiagnostics для диагностики проблем удаленного подключения WSMan
• Microsoft.PowerShell.Diagnostics для диагностики работы самой ОС
• TroubleshootingPack для диагностики аппаратного обеспечения.

 

Ффууух. На этом все. Успехов.