А АThursday, 4 January 2018

Модули диагностики в 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 для диагностики аппаратного обеспечения.
 
Ффууух. На этом все. Успехов.
 

No comments:

Post a Comment

А что вы думаете по этому поводу?

Версия на печать

Популярное

Медиа облако