1) Новый общий параметр PipelineVariable
PipelineVariable позволяет вам сохранять результаты переданной по конвейеру команды (или часть переданной по конвейеру команды) как переменную, которая может передаваться далее через конвейер.
Список общих параметров в PowerShell 4.0
PS > [Management.Automation.Internal.CommonParameters].GetProperties().Name
Verbose
Debug
ErrorAction
WarningAction
ErrorVariable
WarningVariable
OutVariable
OutBuffer
PipelineVariable
PS > [Management.Automation.Internal.CommonParameters].GetProperty(«PipelineVariable»).GetCustomAttributes(«AliasAttribute»).AliasNames
pv
Формат(значение переменной без знака $):
-PipelineVariable <String>
Alias: pv
Пример:
Получить список служб, отфильтровать по свойству DependentServices(если службы зависят от данной службы) и вывести результат в формате RootService,Name
PS > Get-Service | Where DependentServices |
Foreach {($s=$_)}| Select -Exp DependentServices | Select @{n=»RootService»;e={$s.Name}},Name
RootService Name
——- —-
AudioEndpointBuilder AudioSrv
BFE SharedAccess
BFE RemoteAccess
BFE PolicyAgent
BFE NisSrv
BFE NisDrv
BFE MpsSvc
BFE IKEEXT
CryptSvc AppIDSvc
Dhcp WinHttpAutoProxySvc
Общий параметр PipelineVariable позволяет нам избавиться от Foreach {($s=$_)}|
PS > Get-Service -PipelineVariable s| Where DependentServices |
Select -Exp DependentServices | Select @{n=»RootService»;e={$s.Name}},Name
RootService Name
——- —-
AudioEndpointBuilder AudioSrv
BFE SharedAccess
BFE RemoteAccess
BFE PolicyAgent
BFE NisSrv
BFE NisDrv
BFE MpsSvc
BFE IKEEXT
CryptSvc AppIDSvc
Dhcp WinHttpAutoProxySvc
Получить список модулей процесса PowerShell и вывести результат в формате ProcName,ModuleName,FileSystemRights,IdentityReference
Get-Process powershell -PipelineVariable p | Foreach {$_.Modules} -pv m |
Foreach {(Get-Acl $_.FileName).Access} |
Select @{n=»ProcName»;e={$p.Name}},@{n=»ModuleName»;e={$m.ModuleName}},FileSystemRights,IdentityReference
ProcName ModuleName FileSystemRights IdentityReference
——— ———- —————- ——————
powershell powershell.exe ReadAndExecute, Synchronize NT AUTHORITY\SYSTEM
powershell powershell.exe ReadAndExecute, Synchronize BUILTIN\Administrators
powershell powershell.exe ReadAndExecute, Synchronize BUILTIN\Users
powershell powershell.exe FullControl NT SERVICE\TrustedInstaller
powershell ntdll.dll ReadAndExecute, Synchronize NT AUTHORITY\SYSTEM
powershell ntdll.dll ReadAndExecute, Synchronize BUILTIN\Administrators
powershell ntdll.dll ReadAndExecute, Synchronize BUILTIN\Users
powershell ntdll.dll FullControl NT SERVICE\TrustedInstaller
Предосторожности при работе с общим параметром PipelineVariable:
1) Указывать имя переменной без знака — $_
2) Не использовать с командами, которые «блокируют» конвейер (Sort-Object,Group-Object,Measure-Object, оператор () и т.д. )
Данные команды,сначала объединяют все данные из конвейера, производят действия над объектами и передают вывод дальше, тем самым «блокируют» конвейер.
(Get-Service -PipelineVariable s) | Foreach {$s} – Получим пустой вывод
PS > Get-Process -PipelineVariable p | Sort Id | Foreach {«$($p.Name) has $($_.Modules.Count)»}
WLIDSVCM has 0
WLIDSVCM has 0
WLIDSVCM has 0
WLIDSVCM has 0
WLIDSVCM has 5
WLIDSVCM has 0
3) Переменная удаляется после выхода из конвейера
2) Изменение в поведении свойства DefaultCommandPrefix в манифесте модуля
Данный ключ позволяет предотвратить конфликты в названии имен команд модуля, путем добавления префикса. Параметр –Prefix командлета Import-Module имеет приоритет над свойством DefaultCommandPrefix(Т.е. если в манифесте DefaultCommandPrefix=»ABC»,а при импорте модуля Import-Module MyModule –Prefix ZZZ ,то у команд будет префикс ZZZ).
В Windows PowerShell 3.0 если модуль использует свойство DefaultCommandPrefix в своем манифесте или если пользователь импортирует модуль с параметром Prefix свойство ExportedCommands модуля показывает команды в модуле без префикса. Команды также могут быть запущены без префикса, с использованием синтаксиса: ModuleName\CommandName
В Windows PowerShell 4.0 если модуль использует ключ DefaultCommandPrefix в своем манифесте, или если пользователь импортирует модуль с параметром Prefix свойство ExportedCommands модуля показывает команды в модуле с префиксом. При запуске команды с помощью модуля используя синтаксис ModuleName\CommandName, имена команд должны включать префикс.
Пример:
Предположим, в манифесте модуля SampleModule определено свойство DefaultCommandPrefix с префиксом «Abc» и экспортирует командлет Get-SampleCommand.
В Windows PowerShell 3.0:
C:\> $m = Get-Module SampleModule -ListAvaiable
C:\> $m.ExportedCommands | Format-List
Key : Get-SampleCommand
Value : Get-SampleCommand
В Windows PowerShell 4.0:
C:\> $m = Get-Module SampleModule -ListAvailable
C:\> $m.ExportedCommands | Format-List
Key : Get-AbcSampleCommand
Value : Get-AbcSampleCommand
Как мы видим, что корректные данные получаем только в PowerShell 4.0.
В Windows PowerShell 3.0:
C:\> Import-Module SampleModule
C:\> SampleModule\Get-SampleCommand
<no error — command is executed>
C:\> SampleModule\Get-AbcSampleCommand
<CommandNotFoundException>
В Windows PowerShell 4.0:
C:\> Import-Module SampleModule
C:\> SampleModule\Get-SampleCommand
<CommandNotFoundException>
C:\> SampleModule\Get-AbcSampleCommand
<no error — command is executed>
В PowerShell 3.0 при указании префикса мы получим исключение(команда не найдена – CommandNotFoundException) , без префикса исключение не возникает и происходит выполнение команды. В PowerShell 4.0 при указании префикса исключения не возникает и происходит выполнение команды, без указания возникает исключение(команда не найдена – CommandNotFoundException) .
Workaround: Для PowerShell 3.0 можно воспользоваться module-qualified синтаксисом:
Import-Module ActiveDirectory -Prefix ABC
$m = Get-Module ActiveDirectory
& $m Get-ABCADUser -Filter *
3) Изменения в отладчике Windows PowerShell 4.0
Данный пункт был заимствован у Paul Higinbotham(Windows PowerShell team) — Remote Script Debugging in Windows PowerShell
Отладчик в Windows PowerShell 4.0 включает два основных улучшения: возможность отладки сценариев в удаленных сессиях и поддержка workflow(также в удаленных сенсах). В предыдущих версиях Windows PowerShell отладка сценариев была ограничена только локальной машиной. При использовании точек останова в предыдущих версиях Windows PowerShell в удаленных сеансах приводило к возникновению ошибок. В Windows PowerShell 4.0 можно установить точки останова в удаленных сеансах и отлаживать удаленный запуск сценариев из командной строки Windows PowerShell , что и при отладке на локальном компьютере. Для использования удаленной отладки, требуется чтобы версия Windows PowerShell на исходном и конечном компьютере была 4.0. Кроме того в консоли Windows PowerShell поддерживается удаленная отладка, но она не поддерживается в Windows PowerShell ISE.
Отладка сценариев в Windows PowerShell консоли всегда начинается одинаково. Для этого используйте Set-PSBreakpoint , чтобы задать точку останова: строку, команду или переменную в сценарии, а затем запустить скрипт. Когда дойдет до точки останова, выполнение скрипта останавливается и консоль переходит в режим отладчика.
Командная строка изменяется, чтобы указать, что консоль работает в режиме отладки, и из этой строки, можно выполнить команды, такие как Help (‘h’, ‘?’), List source (‘list’, ‘l’), Show call stack (‘k’), и команды возобновления (например, Continue, StepInto, и StepOut).
Пример 1: Отладка скриптов в консоли
PS > Set-PSBreakpoint -Script C:\DebugTest1.ps1 -Line 1
ID Script Line Command Variable Action
— —— —- ——- ——— ——
0 DebugTest1.ps1 1
PS > C:\DebugTest1.ps1
Entering debug mode. Use h or ? for help.
Hit Line breakpoint on ‘C:\DebugTest1.ps1:1’
At C:\DebugTest1.ps1:1 char:1
+ $Title = «Debugging Test»
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
[DBG]: PS >> stepOver
At C:\DebugTest1.ps1:2 char:1
+ $Count = 100
+ ~~~~~~~~~~~~
[DBG]: PS >> $Title
Debugging Test
[DBG]: PS >> Get-Process powershell
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
——- —— —— —— —— —— — ————
360 26 76180 84356 617 2,11 3024 powershell
[DBG]: PS >>
Процесс отладки удаленного сценария Windows PowerShell почти идентичен локальной отладки. Отладка – это интерактивный процесс, так для отладки сценария в удаленном сеансе, необходимо сначала установить интерактивный сеанс с которого можно отлаживать. Это делается с помощью командлета Enter-PSSession, где вы можете ввести существующий удаленный сеанс или создать новый. Для отладки сценариев в удаленной сессии для начала требуется установить интерактивную сессию. Это делается с помощью командлета Enter-PSSession с помощью него можно установить новую сессию или указать существующий сеанс.
Пример 2: Создание нового удаленного сеанса и запуск интерактивной сессии
PS C:\> Enter-PSSession –ComputerName localhost
[localhost]: PS C:\>
Существует одно существенное отличие между отладкой локальных и удаленных сценариев. Когда отладка и вывод данных остановлен в отладчике во время удаленной отладки скриптов, данные поступают на клиенте через отдельные и асинхронные потоки. Потому что мы не хотели,чтобы перезаписывались выходные данные или другая отладочная информации, Windows PowerShell подавляет выходные данные сценария в то время как отладчик находится в режиме остановки(Stop). Недостатком является то, что некоторые выходные данные сценария могут прибыть позже, чем ожидалось.
Пример 3: Консоль удаленной отладки скриптов
Для использования удаленной отладки, требуется чтобы версия Windows PowerShell на исходном и конечном компьютере была 4.0.
PS C:> Enter-PSSession $env:COMPUTERNAME
[SRV]: PS C:> Set-PSBreakpoint DebugTest1.ps1 1
ID Script Line Command Variable Action
— —— —- ——- ——— ——
0 DebugTest.ps1 1
[SRV]: PS C:> .\DebugTest1.ps1
Entering debug mode. Use h or ? for help.
Hit Line breakpoint on ‘C:\DebugTest1.ps1:1’
At C:\DebugTest1.ps1:1 char:1
+ $Title = «Debugging Test»
+ ~
[SRV]: [DBG]: PS C:>> list 1
1:* $Title = «Debugging Test»
2: $Count = 100
[SRV]: [DBG]: PS C:>> stepOver
At C:\DebugTest1.ps1:2 char:1
+ $Count = 100
+ ~
[SRV]: [DBG]: PS C:>>
Отладка в отключенных сеансах
Удаленная отладка Windows PowerShell также поддерживает отключенные сеансы, которые были добавлены в Windows PowerShell 3.0. Сценарий отладки состояние остановки(Stop) сохраняется в отключенном сеанс, что позволяет отлаживать сценарий, когда соединение будет восстановлено.
В Windows PowerShell 3.0 удаленный сеанс может быть отключен одним из двух способов.Первым из них является ручной отключение, при выполнении командлета Disconnect-PSSession или Invoke-Command –InDisconnectedSession. Во-вторых, через надежные соединения — автоматическое отключение. То есть, если в сеансе теряется сетевое подключение, то сеанс автоматически отключается после четырех минут при попытке восстановить сетевое подключение.
В Windows PowerShell 4.0, есть и третий путь отключения удаленного сеанса , при достижении точки останова в скрипте в удаленном сеансе. Сценарий в удаленном сеансе останавливается в отладчике, и удаленный сеанс отключается от клиента. Для отладки или продолжения сценария, вы должны использовать командлет Enter-PSSession для установки интерактивного сеанса отладки с консоли Windows PowerShell. В сеансе отладки, вы можете отлаживать скрипт или продолжить выполнение скрипта.
Вы можете определить, является ли отключенный сеанс остановленным в отладчике, подключившись к нему через Connect-PSSession, и, глядя на свойство Availability сеанса. Если он остановлен в отладчике, Availability == ‘RemoteDebug’.
После того, как удаленный сеанс остановлено в отладчике и отключен, у вас есть только два варианта о том, как поступить с сессией. Сессии можно отлаживать с помощью командлета Enter-PSSession, или вы можете убить сессии с помощью командлета Remove-PSSession.
При запуске сценария в отключенном сеансе, сценарий выполняется на удаленном компьютере и выходные данные помещаются в буфер на удаленном компьютере. Обычно вам требуется подключиться и получить его вывод, выполнив командлет Receive-PSSession. Однако если сценарий остановился в удаленном сеансе в точке останова в отладчике, Receive-PSSession не будет работать, и вы получите предупреждающее сообщение, что сеанс будет остановлен в отладчике.
Чтобы продолжить, необходимо отладить удаленного сценария в интерактивном сеансе с использованием командлета Enter-PSSession. В этой интерактивной сессии можно выполнить отладку сценария или пусть скрипт выполняеться до завершения, удалив все точки останова и использовать команду Continue отладчика.
Пример 4: Отладка отключенного сеанса
PS > $session = Invoke-Command -Cn localhost -ScriptBlock { Set-PSBreakpoint C:\DebugTest1.ps1 5;C:\DebugTest1.ps1 } -InDisconnectedSession
PS > $session
Id Name ComputerName State ConfigurationName Availability
— —- ———— —— —————— ————
2 Session1 localhost Disconnected Microsoft.PowerShell None
PS > Connect-PSSession $session
Id Name ComputerName State ConfigurationName Availability
— —- ———— —— —————— ————
2 Session1 localhost Opened Microsoft.PowerShell RemoteDebug
PS > Receive-PSSession $session
WARNING: The remote session command is currently stopped in the debugger. Use the Enter-PSSession cmdlet to connect
interactively to the remote session and automatically enter into the console debugger.
PS > Enter-PSSession $session
WARNING: You have entered a session that is currently stopped at a debug breakpoint inside a running command or script.
Use the Windows PowerShell command line debugger to continue debugging.
Entering debug mode. Use h or ? for help.
Hit Line breakpoint on ‘C:\DebugTest1.ps1:5’
At C:\DebugTest1.ps1:5 char:1
+ $Count
+ ~
[localhost]: [DBG]: PS \Documents>> continue
100
Отладка удаленных сеансов с Invoke-Command
Windows PowerShell поддерживает запуск сценариев синхронно на удаленных машинах, используя командлет Invoke-Command. В предыдущем разделе, привели пример об использовании Invoke-Command для установки точки останова и запуск файла сценария на удаленной машине с помощью параметра -InDisconnectedSession. Invoke-Command немедленно отключает сессию и скрипт выполняется асинхронно в удаленном сеансе.
Затем отлаживаем удаленный сеанс с помощью Enter-PSSession. В этом случае мы делаем то же самое за исключением мы оставим сессию подключенной во время выполнения сценария. Когда достигается точка останова , сеанс автоматически отключается. Затем подключаемся к удаленной сессии снова и продолжаем отладку.
Пример 5: Отладка отключенного сеанса, часть 2
PS > $session = New-PSSession -ComputerName localhost
PS > $session
Id Name ComputerName State ConfigurationName Availability
— —- ———— —— —————— ————
1 Session1 localhost Opened Microsoft.PowerShell Available
PS > Invoke-Command -Session $session -ScriptBlock { Set-PSBreakpoint C:\DebugTest1.ps1 -Line 1 }
ID Script Line Command Variable Action PSComputerName
— —— —- ——- ——— —— —————
0 DebugTest1.ps1 1 localhost
PS > Invoke-Command -Session $session -ScriptBlock { C:\DebugTest1.ps1 }
WARNING: Session Session1 with instance ID f22a31b0-4d45-42a9-b066-bfcd63dbeb73 on computer localhost has been
disconnected because the script running on the session has stopped at a breakpoint. Use the Enter-PSSession cmdlet on
this session to connect back to the session and begin interactive debugging.
PS > $session
Id Name ComputerName State ConfigurationName Availability
— —- ———— —— —————— ————
1 Session1 localhost Disconnected Microsoft.PowerShell None
PS > Enter-PSSession $session
WARNING: You have entered a session that is currently stopped at a debug breakpoint inside a running command or script.
Use the Windows PowerShell command line debugger to continue debugging.
Entering debug mode. Use h or ? for help.
Hit Line breakpoint on ‘C:\DebugTest1.ps1:1’
At C:\DebugTest1.ps1:1 char:1
+ $Title = «Debugging Test»
+ ~
[localhost]: [DBG]: PS \Documents>> stepOver
At C:\DebugTest1.ps1:2 char:1
+ $Count = 100
+ ~
[localhost]: [DBG]: PS \Documents>>
Отлично описан процесс отладки!
Спасибо!