В одном из предыдущих постов (см. Вызов Troubleshooting Pack средствами командной строки) я опрометчиво “пообещался” написать на эту тему. Что же, публичные обещания нужно выполнять . Тем более, что приведенные примеры использования msdt пригодны для выполнения на локальной машине или в сессии удаленного рабочего стола. При этом запускается GUI мастер. А если это необходимо выполнить удаленно, без подключения по RDS, и GUI, соответственно будет недоступен?

Немного предыстории. Powershell имеет следующие возможности удаленного выполнения команд:

• многие “родные командлеты” поддерживают параметр –computername и, соответственно, могут быть выполнены удаленно (способ 1);
• организация удаленной сессии в PowerShell (способ 2);
• вход в удаленную сессию через службу WinRM и запуск шелла WinRS, с последующим запуском PowerShell (способ 3).

В контексте моих сегодняшних рассуждений, будет использоваться способ №2.

1. Итак, включаем возможность удаленного подключения к PowerShell:

Enable-PSRemoting

Этим мы включаем WinRM. На удаленной машине тоже должен быть включен WinRM и открыты соответствующие “лазейки” в брандмауре, допустим, посредством применения групповой политики на OU компьютера. Это можно и нужно сделать заблаговременно, и  это вдобавок дает некоторые преимущества в мониторинге и удаленном администрировании рабочих станции (теоретически, в небольшой ущерб безопасности).

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

Set-Item WSMan:localhostClientTrustedHosts *

Это, на самом деле, плохой, но рабочий вариант: мы, фактически, говорим, что “нужно  верить всем хостам”. Звездочку можно заменить на имя машины (или IP).

2. Входим в удаленную сессию PowerShell:

Enter-PSSession 10.0.67.57 или

Enter-PSSession testws.kalima.msft

Теперь мы находимся в PowerShell на удаленной машине.

3. Командлеты, отвечающие за TroubleShooting находятся в подгружаемом модуле. Загружаем его:

import-module troubleshootingpack

4. Теперь выполняем нужные нам командлеты в конвеере:

Get-TroubleshootingPack -Path C:WindowsDiagnosticsSystem[имя_директории] | Invoke-TroubleshootingPack

При выполнении этого конвеера потребуется некое мастерство: набираем вплоть до C:WindowsDiagnosticsSystem и далее жмем {TAB} для автоподстановки директории с конкретным TroubleShooting паком. Выбор его осуществляем по имени папки, допустим:

Get-TroubleshootingPack -Path C:WindowsDiagnosticsSystemPower | Invoke-TroubleshootingPack

Дополнительное преимущество: можно получить .xml логи (debugReport.xml, ResultReport.xml, Results.xsl) проделанных действий и их результата, для этого командлеты запускаются в таком синтаксисе:

Get-TroubleshootingPack -Path C:WindowsDiagnosticsSystemPower | Invoke-TroubleshootingPack -Result C:PSLogs

5. Запускается интерактивный текстовой(!) мастер. Проходим его.

6. Удостоверяемся еще раз, что все разрешилось “само-собой” и покидаем удаленную сессию:

Exit-PSSession

На этом все. Пробуйте. Пользуйтесь.