Use PowerShell Troubleshooting Packs to Diagnose Remote Problems

Summary: Learn how to use Windows PowerShell troubleshooting packs to diagnose and correct problems with remote systems.

Hey, Scripting Guy! Question

  Hey, Scripting Guy! I need to troubleshoot remote systems. In the past, we have always configured Remote Desktop on our servers to allow for remote management. The problem is that many of our remote offices have absolutely terrible bandwidth. This is especially true in the late afternoon when the applications update our central servers with the day’s transactions. Although Remote Desktop is great when connected at LAN speeds, it is not so great for accessing a heavily loaded server via a can and string WAN. There have been times when I have actually clicked the wrong item in a management tool because the screen updates were coming so slowly. Luckily, Windows always seems to prompt before anything disastrous happens—like dropping a table from a SQL database or deleting all of the events from the Security event log. It would be great if I could just use Windows PowerShell for troubleshooting and not incur the overhead involved in remoting an entire desktop.

—TK

Hey, Scripting Guy! Answer Hello TK,

Microsoft Scripting Guy Ed Wilson, here. Today is a cool day. I had two meetings cancel, so I am free for the day. I decided to spend much of the morning catching up on email that’s been sent to the Scripter@Microsoft.com address. I have The Magic Flute by Mozart cranked up on my Zune HD (at least loud enough to cover my operatic ambitions) and I am playing with Windows PowerShell. What could be better?

This is the third in a series of blog posts that detail working with the Windows PowerShell troubleshooting pack cmdlets. Monday’s blog post was Use PowerShell to Troubleshoot Your Windows 7 Computer. The second blog post was Use PowerShell to Automate Windows Troubleshooting. Please refer to these two blog posts for background information that is assumed in today’s blog.Tommorow I will talk about using Windows PowerShell and Scheduled Tasks with the Troubleshooting Module to automate troubleshooting.

TK, by using Windows PowerShell remoting, you can indeed work with the troubleshooting pack cmdlets on a remote server or workstation. I have written several Hey Scripting Guy! blogs about Windows PowerShell remoting, and I have posted several guest blogs as well. After Windows PowerShell remoting is configured it is simple to use Windows PowerShell and the troubleshooting pack cmdlets.

To work interactively in a remote Windows PowerShell session, use the Enter-PSSession cmdlet to make a connection to a remote computer. In the example shown here, I connect to a computer named hyperv-box with the nwtraders\administrator credentials.

Enter-PSSession -ComputerName hyperv-box -Credential nwtraders\administrator

When this command runs, a dialog box appears that prompts me to enter the password for the nwtraders\administrator account. The dialog box is shown in the following image.

Image of dialog box

It is interesting that the Windows PowerShell console in which I entered the command was not an elevated Windows PowerShell console. But because I specified an administrator account, the Windows PowerShell prompt that returned from the remote machine was elevated.

The first step is to see which troubleshooting packs are available on the remote server. I use the dir alias for the Get-Childtem cmdlet to see what has been installed. The command and results are shown here. (The Windows PowerShell prompt changes to indicate the name of the remote server in square brackets.)

[hyperv-box]: PS C:\> dir C:\Windows\diagnostics\system

Directory: C:\Windows\diagnostics\system

Mode LastWriteTime Length Name

—- ————- —— —-

d—- 7/14/2009 1:41 AM Networking

d—- 7/14/2009 1:41 AM PCW

Now I need to import the TroubleShootingPack module by using the Import-Module cmdlet. After I have accomplished that, I use the Get-Command cmdlet with the module parameter to ensure that the module loaded properly. These commands are shown here.

[hyperv-box]: PS C:\> Import-Module troubleshootingpack

[hyperv-box]: PS C:\> Get-Command -Module tr*

CommandType Name Definition

———– —- ———-

Cmdlet Get-TroubleshootingPack Get-TroubleshootingPack [-Path…

Cmdlet Invoke-TroubleshootingPack Invoke-TroubleshootingPack [-P…

To obtain an overview of what the Networking TroubleShooting Pack will accomplish, I use the Get-TroubleShootingPack cmdlet and pipe the resulting DiagPack information to the Format-List cmdlet (fl is the alias for Format-List). The command and associated output are shown here.

[hyperv-box]: PS C:\> Get-TroubleshootingPack C:\Windows\diagnostics\system\Networkin

g | fl *

Path : C:\Windows\diagnostics\system\Networking

Id : NetworkDiagnostics

Version : 1.0

Publisher : Microsoft Windows

Name : Windows Network Diagnostics

Description : Detects problems with network connectivity.

MinimumVersion : 6.1

PrivacyLink : http://go.microsoft.com/fwlink/?LinkId=104288

SupportsClient : True

SupportsServer : True

SupportsX86 : True

SupportsAmd64 : True

SupportsIA64 : True

RequiresElevation : True

Interactive : True

RootCauses : {“%InterfaceName%” doesn’t have a valid IP configuration, Anothe

r computer on the network has the same IP address as this comput

er, “%InterfaceName%” doesn’t have a valid IP configuration, “%I

nterfaceName%” doesn’t have a valid IP configuration…}

FoundRootCauses :

Interactions : {Select entry point, Select the network adapter to diagnose, Ple

ase select the issue Windows should troubleshoot, What are you t

rying to do?…}

ExtensionPoint : #document

The portion that tells me what the troubleshooting pack will detect is in the RootCauses portion. I can return only that portion of the results by using the Select-Object (select is the alias) and expanding the RootCause property. The command and associated output is shown here.

[hyperv-box]: PS C:\> Get-TroubleshootingPack C:\Windows\diagnostics\system\Networkin

g | select -ExpandProperty rootcauses

Name

—-

“%InterfaceName%” doesn’t have a valid IP configuration

Another computer on the network has the same IP address as this computer

“%InterfaceName%” doesn’t have a valid IP configuration

“%InterfaceName%” doesn’t have a valid IP configuration

“%InterfaceName%” doesn’t have a valid IP configuration

The default gateway is not available

“%InterfaceName%” doesn’t have a valid IP configuration

“%InterfaceName%” doesn’t have a valid IP configuration

“%InterfaceName%” doesn’t have a valid IP configuration

“%InterfaceName%” doesn’t have a valid IP configuration

Another computer on the network has the same IP address as this computer

The default gateway is not available

“%InterfaceName%” doesn’t have a valid IP configuration

Problem with wireless adapter or access point

There might be a problem with the driver for the %InterfaceName% adapter

The Windows wireless service is not running on this computer

Your computer does not meet the requirements for DirectAccess

The Diagnostics Policy Service is not running

The Diagnostics Policy Service is disabled

Windows is in Safe Mode.

%RootCauseName%

%RootCauseName%

%RootCauseName%

%RootCauseName%

%RootCauseName%

%RootCauseName%

%RootCauseName%

An Ethernet cable is not properly plugged in or might be broken

A network cable is not properly plugged in or may be broken

The %InterfaceName% adapter is disabled

Those appear to be exactly the checks I am interested in seeing. Therefore, I call the troubleshooting pack by passing it to the Invoke-TroubleShootingPack cmdlet. Because this runs interactively, I have to answer several questions. The command to invoke the troubleshooting pack appears here (this is a single command that has wrapped on the line. The [hyperv-box]: PS C:\> portion is part of the prompt and not the actual command).

[hyperv-box]: PS C:\> Get-TroubleshootingPack C:\Windows\diagnostics\system\Networkin

g | Invoke-TroubleshootingPack

The output from walking through this command is shown here.

Image of output

To automate running the troubleshooting pack, run the Get-TroubleShootingPack cmdlet with the answerfile parameter. Keep in mind that the location specified for storing the answer file must exist on the remote server. Use the Get-ChildItem cmdlet (dir is the alias) to ensure that the remote location exists. The command to run the Get-TroubleShootingPack cmdlet with the answerfile parameter is shown here.

[hyperv-box]: PS C:\> Get-TroubleshootingPack C:\Windows\diagnostics\system\Networkin

g -answerfile c:\fso\network.xml

As I answer the questions, the results are stored in the answer file. This interaction is shown here.

Image of question/answer interaction

When I run the command and pass the answer file, the command runs in an automated fashion.

TK that is all there is to using the troubleshooting pack against a remote computer. Troubleshooting Week will continue tomorrow when I will talk about using Windows PowerShell and Scheduled Tasks with the Troubleshooting Module to automate troubleshooting..

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy