![\"Hey,](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/q-for-powertip.jpg\" "\\"Hey,")
<\/p>\nSummary<\/b>: Learn how to use Windows PowerShell troubleshooting packs to diagnose and correct problems with remote systems.<\/p>\n
<\/p>\n
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<\/a> an entire desktop.<\/p>\n —TK<\/p>\n 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<\/a> address. I have The Magic Flute<\/a> by Mozart<\/a> cranked up on my Zune HD<\/a> (at least loud enough to cover my operatic ambitions) and I am playing with Windows PowerShell. What could be better?<\/p>\n 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<\/a>. The second blog post was Use PowerShell to Automate Windows Troubleshooting<\/a>. 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<\/a>.<\/p>\n 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<\/a>, and I have posted several guest blogs as well.<\/a> After Windows PowerShell remoting is configured<\/a> it is simple to use Windows PowerShell and the troubleshooting pack cmdlets.<\/p>\n To work interactively in a remote Windows PowerShell session, use the Enter-PSSession<\/b> cmdlet to make a connection to a remote computer. In the example shown here, I connect to a computer named hyperv-box<\/b> with the nwtraders\\administrator<\/b> credentials.<\/p>\n Enter-PSSession -ComputerName hyperv-box -Credential nwtraders\\administrator<\/p>\n<\/blockquote>\n When this command runs, a dialog box appears that prompts me to enter the password for the nwtraders\\administrator<\/b> account. The dialog box is shown in the following image.<\/p>\n 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.<\/p>\n The first step is to see which troubleshooting packs are available on the remote server. I use the dir<\/b> alias for the Get-Childtem <\/a>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.)<\/p>\n [hyperv-box]: PS C:\\> dir C:\\Windows\\diagnostics\\system<\/p>\n Directory: C:\\Windows\\diagnostics\\system<\/p>\n Mode LastWriteTime Length Name<\/p>\n —- ————- —— —-<\/p>\n d—- 7\/14\/2009 1:41 AM Networking<\/p>\n d—- 7\/14\/2009 1:41 AM PCW<\/p>\n<\/blockquote>\n Now I need to import the TroubleShootingPack module<\/a> by using the Import-Module<\/b> cmdlet. After I have accomplished that, I use the Get-Command<\/b> cmdlet with the module<\/i> parameter to ensure that the module loaded properly. These commands are shown here.<\/p>\n [hyperv-box]: PS C:\\> Import-Module troubleshootingpack<\/p>\n [hyperv-box]: PS C:\\> Get-Command -Module tr*<\/p>\n CommandType Name Definition<\/p>\n ———– —- ———-<\/p>\n Cmdlet Get-TroubleshootingPack Get-TroubleshootingPack [-Path…<\/p>\n Cmdlet Invoke-TroubleshootingPack Invoke-TroubleshootingPack [-P…<\/p>\n<\/blockquote>\n To obtain an overview of what the Networking TroubleShooting Pack will accomplish, I use the Get-TroubleShootingPack<\/b> cmdlet and pipe<\/a> the resulting DiagPack information to the Format-List<\/b> cmdlet (fl<\/b> is the alias for Format-List). The command and associated output are shown here.<\/p>\n [hyperv-box]: PS C:\\> Get-TroubleshootingPack C:\\Windows\\diagnostics\\system\\Networkin<\/p>\n g | fl *<\/p>\n Path : C:\\Windows\\diagnostics\\system\\Networking<\/p>\n Id : NetworkDiagnostics<\/p>\n Version : 1.0<\/p>\n Publisher : Microsoft Windows<\/p>\n Name : Windows Network Diagnostics<\/p>\n Description : Detects problems with network connectivity.<\/p>\n MinimumVersion : 6.1<\/p>\n PrivacyLink : http:\/\/go.microsoft.com\/fwlink\/?LinkId=104288<\/p>\n SupportsClient : True<\/p>\n SupportsServer : True<\/p>\n SupportsX86 : True<\/p>\n SupportsAmd64 : True<\/p>\n SupportsIA64 : True<\/p>\n RequiresElevation : True<\/p>\n Interactive : True<\/p>\n RootCauses : {“%InterfaceName%” doesn’t have a valid IP configuration, Anothe<\/p>\n r computer on the network has the same IP address as this comput<\/p>\n er, “%InterfaceName%” doesn’t have a valid IP configuration, “%I<\/p>\n nterfaceName%” doesn’t have a valid IP configuration…}<\/p>\n FoundRootCauses :<\/p>\n Interactions : {Select entry point, Select the network adapter to diagnose, Ple<\/p>\n ase select the issue Windows should troubleshoot, What are you t<\/p>\n rying to do?…}<\/p>\n ExtensionPoint : #document<\/p>\n<\/blockquote>\n The portion that tells me what the troubleshooting pack will detect is in the RootCauses<\/b> portion. I can return only that portion of the results by using the Select-Object<\/b> (select<\/b> is the alias) and expanding the RootCause<\/b> property. The command and associated output is shown here.<\/p>\n [hyperv-box]: PS C:\\> Get-TroubleshootingPack C:\\Windows\\diagnostics\\system\\Networkin<\/p>\n g | select -ExpandProperty rootcauses<\/p>\n Name<\/p>\n —-<\/p>\n “%InterfaceName%” doesn’t have a valid IP configuration<\/p>\n Another computer on the network has the same IP address as this computer<\/p>\n “%InterfaceName%” doesn’t have a valid IP configuration<\/p>\n “%InterfaceName%” doesn’t have a valid IP configuration<\/p>\n “%InterfaceName%” doesn’t have a valid IP configuration<\/p>\n The default gateway is not available<\/p>\n “%InterfaceName%” doesn’t have a valid IP configuration<\/p>\n “%InterfaceName%” doesn’t have a valid IP configuration<\/p>\n “%InterfaceName%” doesn’t have a valid IP configuration<\/p>\n “%InterfaceName%” doesn’t have a valid IP configuration<\/p>\n Another computer on the network has the same IP address as this computer<\/p>\n The default gateway is not available<\/p>\n “%InterfaceName%” doesn’t have a valid IP configuration<\/p>\n Problem with wireless adapter or access point<\/p>\n There might be a problem with the driver for the %InterfaceName% adapter<\/p>\n The Windows wireless service is not running on this computer<\/p>\n Your computer does not meet the requirements for DirectAccess<\/p>\n The Diagnostics Policy Service is not running<\/p>\n The Diagnostics Policy Service is disabled<\/p>\n Windows is in Safe Mode.<\/p>\n %RootCauseName%<\/p>\n %RootCauseName%<\/p>\n %RootCauseName%<\/p>\n %RootCauseName%<\/p>\n %RootCauseName%<\/p>\n %RootCauseName%<\/p>\n %RootCauseName%<\/p>\n An Ethernet cable is not properly plugged in or might be broken<\/p>\n A network cable is not properly plugged in or may be broken<\/p>\n The %InterfaceName% adapter is disabled<\/p>\n<\/blockquote>\n 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<\/b> 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:\\><\/b> portion is part of the prompt and not the actual command).<\/p>\n [hyperv-box]: PS C:\\> Get-TroubleshootingPack C:\\Windows\\diagnostics\\system\\Networkin<\/p>\n g | Invoke-TroubleshootingPack<\/p>\n<\/blockquote>\n The output from walking through this command is shown here.<\/p>\n To automate running the troubleshooting pack, run the Get-TroubleShootingPack<\/b> cmdlet with the answerfile<\/i> parameter. Keep in mind that the location specified for storing the answer file must exist on the remote server. Use the Get-ChildItem<\/b> cmdlet (dir<\/b> is the alias) to ensure that the remote location exists. The command to run the Get-TroubleShootingPack<\/b> cmdlet with the answerfile<\/i> parameter is shown here.<\/p>\n [hyperv-box]: PS C:\\> Get-TroubleshootingPack C:\\Windows\\diagnostics\\system\\Networkin<\/p>\n g -answerfile c:\\fso\\network.xml<\/p>\n<\/blockquote>\n As I answer the questions, the results are stored in the answer file. This interaction is shown here.<\/p>\n When I run the command and pass the answer file, the command runs in an automated fashion.<\/p>\n 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<\/a>..<\/p>\n I invite you to follow me on Twitter<\/a> and Facebook<\/a>. If you have any questions, send email to me at scripter@microsoft.com<\/a>, or post your questions on the Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.<\/p>\n Ed Wilson, Microsoft Scripting Guy<\/b><\/p>\n","protected":false},"excerpt":{"rendered":" Summary: Learn how to use Windows PowerShell troubleshooting packs to diagnose and correct problems with remote systems. 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 […]<\/p>\n","protected":false},"author":595,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[51,31,3,4,134,45],"class_list":["post-15651","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-getting-started","tag-operating-system","tag-scripting-guy","tag-scripting-techniques","tag-troubleshooting","tag-windows-powershell"],"acf":[],"blog_post_summary":" Summary: Learn how to use Windows PowerShell troubleshooting packs to diagnose and correct problems with remote systems. 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 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/15651","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/595"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=15651"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/15651\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=15651"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=15651"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=15651"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"Hey,](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/a-for-powertip.jpg\" "\\"Hey,")
Hello TK,<\/p>\n\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/7077.HSG-2-9-11-01_thumb_4095BF65.jpg\" "\\"Image")
<\/a><\/p>\n\n
\n
\n
\n
\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/1145.HSG-2-9-11-02_thumb_7B4D426E.jpg\" "\\"Image")
<\/a><\/p>\n\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/5861.HSG-2-9-11-03_thumb_645E4B25.jpg\" "\\"Image")
<\/a><\/p>\n