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.


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 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 :

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



"%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.








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, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Comments (2)

  1. hassan says:

    Windows 7 Offline Privacy Statement for the Microsoft Error Reporting Service

    For the most up-to-date privacy information, see the online Windows 7 Privacy Statement at:


    The Microsoft Error Reporting Service helps Microsoft and Microsoft partners diagnose problems in the software you use and provide solutions. Not all problems have solutions, but when solutions are available, they are offered as steps to solve a problem you’ve reported or as updates to install. To help prevent problems and make software more reliable, some solutions are also included in service packs and future versions of the software.

    The Microsoft Error Reporting Service also provides Setup Repair, an error reporting service that may run during Windows setup if a problem occurs.


    Many Microsoft software programs, including Windows 7, are designed to work with the reporting service. If a problem occurs in one of these software programs, you might be asked if you want to report it.  If you host virtual machines using a Windows operating system, reports generated by the Windows operating system for the Microsoft Error Reporting Service might include information about virtual machines.

    The reporting service collects information that is useful for diagnosing and solving the problem that has occurred, such as:

     *  Where the problem happened in the software or hardware

     *  The type or severity of the problem

     *  Files that help describe the problem

     *  Basic software and hardware information

     *  Possible software performance and compatibility problems

    These reports might unintentionally contain personal information. For example, a report that contains a snapshot of computer memory might include your name, part of a document you were working on, or data that you recently submitted to a website. If a report is likely to contain this type of information, Windows will ask if you want to send this information, even if you have enabled automatic reporting through the “Recommended settings” option in setup, or Control Panel. This gives you the opportunity to review the report before sending it to Microsoft. Reports including files and data might be stored on your computer until you have an opportunity to review and send them, or after they have been sent.

    If an error report contains personal information, Microsoft does not use the information to identify you or contact you. In addition, if you enable automatic reporting through the "Recommended settings" option in setup, or in Control Panel, the reporting service will send basic information about where problems occur automatically, but these reports will not have the detail described above.

    After you send a report, the reporting service might ask you for more information about the error you experienced. If you choose to provide your phone number or e-mail address in this information, your error report will be personally identifiable. Microsoft might contact you to request additional information to help solve the problem you reported.

    The Microsoft Error Reporting Service generates a globally unique identifier (GUID) that is stored on your computer and sent with error reports to uniquely identify your computer. The GUID is a randomly generated number; it does not contain any personal information and is not used to identify you. We use the GUID to distinguish how widespread the feedback we receive is and how to prioritize it. For example, the GUID allows Microsoft to distinguish between one customer experiencing a problem one hundred times and one hundred customers experiencing the same problem once.


    Microsoft uses information about errors and problems to improve Microsoft products and services as well as third-party software and hardware designed for use with these products and services. Microsoft employees, contractors, vendors, and partners might be provided access to information collected by the reporting services. However, they will use the information only to repair or improve Microsoft products and services and third-party software and hardware designed for use with Microsoft products and services.

    Microsoft might share aggregate information about errors and problems. Microsoft uses aggregate information for statistical analysis. Aggregate information does not contain specific information from individual reports, nor does it include any personal or confidential information that might have been collected from a report.

    Except as described in this statement, personal information you provide will not be transferred to third parties without your consent. We occasionally hire other companies to provide limited services on our behalf, such as performing statistical analysis. We will only provide those companies the personal information they need to deliver the service, and they are prohibited from using that information for any other purpose.

    Microsoft may access or disclose information about you, including the content of your communications, in order to: (a) comply with the law or respond to lawful requests or legal process; (b) protect the rights or property of Microsoft or our customers, including the enforcement of our agreements or policies governing your use of the software; or (c) act on a good faith belief that such access or disclosure is necessary to protect the personal safety of Microsoft employees, customers, or the public.

    Information collected by or sent to Microsoft by Windows 7 may be stored and processed in the United States or any other country in which Microsoft or its affiliates, subsidiaries, or service providers maintain facilities. Microsoft abides by the safe harbor framework as set forth by the U.S. Department of Commerce regarding the collection, use, and retention of data from the European Union.


    If you choose the recommended settings during Windows 7 setup, basic information about errors will be sent automatically to Microsoft. If a more detailed error report is required, you will be prompted to review it before it is sent. You can change this setting at any time by going to Action Center in Control Panel.


    Microsoft is committed to helping protect the security of your information. We use a variety of security technologies and procedures to help protect your information from unauthorized access, use, or disclosure. For example, we store the information you provide on computer systems with limited access, which are located in controlled facilities.


    If you have questions about this privacy statement, please contact us by submitting your questions online to Privacy Feedback at:

    Windows 7 Offline Privacy Statement for the Microsoft Error Reporting Service

    c/o Microsoft Privacy Response Center

    Microsoft Corporation

    One Microsoft Way

    Redmond, Washington 98052 USA

  2. kiquenet says:

    Using Troubleshooting packs and powershell remoting, in a session non interactive?

Skip to main content