![\"Hey,](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/q-for-powertip.jpg\" "\\"Hey,")
<\/p>\nSummary<\/b>: Microsoft Scripting Guy Ed Wilson shows how to use Windows PowerShell and scheduled tasks to automate troubleshooting your computer.<\/p>\n
<\/p>\n
Hey, Scripting Guy! We have a website that is currently hosted on a rather unreliable server. I am tired of constantly being harassed by management that the server is inaccessible. Unfortunately, we do not have the budget to move the site to different hardware. I would like to use the troubleshooting cmdlets to ensure the website is accessible. In addition, I would like to automate this so that it runs every hour as a scheduled task.<\/p>\n
— BR<\/p>\n
<\/p>\n
![\"Hey,](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/a-for-powertip.jpg\" "\\"Hey,")
Hello BR,<\/p>\n
Microsoft Scripting Guy Ed Wilson here. One of the things I love to do is to use a Windows PowerShell command with the Task Scheduler in Windows 7<\/a>. To me it is the perfect blending of flexibility, power, and convenience. I have written quite a bit about using Windows PowerShell with the Task Scheduler<\/a>, and a quick review of some of those articles might be worthwhile. In addition, you may want to review the articles from earlier in the week about working with the troubleshooting packs.<\/p>\n This is the fourth in a series of articles detailing working with the troubleshooting pack cmdlets. Monday’s article was Use PowerShell to Troubleshoot Your Windows 7 Computer<\/a>. Tuesday’s article was Use PowerShell to Automate Troubleshooting of Windows<\/a>. Yesterday’s article<\/a> was about using the troubleshooting packs to diagnose remote problems. Please refer to these three articles for background information that is assumed in today’s article.<\/p>\n The first thing to do when thinking about scheduling a Windows PowerShell command is to ensure the command works properly on its own. There are several steps that I need to accomplish to use the Task Scheduler to test my access to a website using the troubleshooting pack. The steps are listed here:<\/p>\n 1. Import the TroubleshootingPack<\/b> module<\/a>. This was discussed in Monday’s Hey, Scripting Guy! Blog post.<\/p>\n 2. Use the Get-TroubleshootingPack<\/b> cmdlet to retrieve the Networking Troubleshooting pack. This was discussed in Monday’s Hey, Scripting Guy! Blog post.<\/p>\n 3. Use the Invoke-TroubleshootingPack<\/b> cmdlet to walk through the Networking Troubleshooting pack to ensure it works properly. This was discussed in Tuesday’s Hey, Scripting Guy! Blog post.<\/p>\n 4. Use the AnswerFile <\/i>parameter with the Get-TroubleShootingPack<\/b> cmdlet to create an answer file to permit unattended running of the Networking Troubleshooting pack. This was discussed in Tuesday’s Hey, Scripting Guy! Blog post.<\/p>\n<\/blockquote>\n 5. Use the Get-TroubleShootingPack<\/b> cmdlet to retrieve the Networking Troubleshooting pack and pipe<\/a> it to the Invoke-TroubleShootingPack<\/b> cmdlet while using the AnswerFile<\/i> parameter to point to the answer file that was created in step 4. This was discussed in Wednesday’s Hey, Scripting Guy! Blog post.<\/p>\n 6. After the command runs properly with the answer file, create a folder to store the results of running the command. This will be discussed in today’s Hey, Scripting Guy! Blog post.<\/p>\n 7. Run the command from step 5, specify the Result <\/i>parameter, and point it to the folder created in step 6. This is discussed in today’s Hey, Scripting Guy! Blog post.<\/p>\n 8. When everything is running properly, add the Unattended <\/i>switched parameter to the command created in step 7. This is discussed in today’s Hey, Scripting Guy! Blog post.<\/p>\n 9. Create a scheduled task to run the command created in Step 8. This is discussed in today’s Hey, Scripting Guy! Blog post.<\/p>\n<\/blockquote>\n Okay, BR, I am going to start at step 6 in the above list. I want to create a directory to hold my result reports. To do this, I use the alias md<\/b> and provide a path. The alias md<\/b> is an alias for the mkdir<\/b> function that uses the New-Item<\/b> cmdlet to create a new directory. The use of this command is illustrated here:<\/p>\n PS C:\\> md c:\\diagoutput<\/p>\n Directory: C:\\<\/p>\n Mode LastWriteTime Length Name<\/p>\n —- ————- —— —-<\/p>\n d—- 2\/4\/2011 7:49 PM diagoutput<\/p>\n PS C:\\><\/p>\n<\/blockquote>\n Now I am ready for step 7. I need to retrieve the networking troubleshooting pack by using the Get-TroubleShootingPack<\/b> cmdlet and pipe the DiagPack<\/b> object to the Invoke-TroubleShootingPack<\/b> cmdlet. I will specify the path to the AnswerFile xml file that I created in step 4. In addition, I specify the diagoutput folder to the Result <\/i>parameter. One thing that is a bit strange about the Result<\/i> parameter is that it must point to a folder—it does not accept a file name for the results (the reason for this is because more than one file is generated for the results). The command I use appears here:<\/p>\n Get-TroubleshootingPack C:\\Windows\\diagnostics\\system\\Networking |<\/p>\n Invoke-TroubleshootingPack -AnswerFile C:\\fso\\netpack.xml -Result c:\\DiagOutPut<\/p>\n<\/blockquote>\n After the above command runs, I check my DiagOutPut folder to see if anything appears. As shown in the following image, several files are output as a result of the command.<\/p>\n The .cab, .xml, and .xsl files are overwritten each time the troubleshooting pack is invoked. The .etl file names are unique and therefore the files will accumulate in the folder until manually deleted. I like to use the Get-WinEvent<\/b> cmdlet to peruse the .etl log files. It is possible to open them using the Event Viewer utility (by using the Open Saved Log action), but the Get-WinEvent<\/b> cmdlet is a faster option. I like to look at the IDs and the messages.<\/p>\n The use of the Get-WinEvent cmdlet is discussed in two Hey Scripting Guy! articles. In the first I talk about using the Get-Winevent cmdlet to filter event logs<\/a>, and in the second article I talk about using the Get-WinEvent cmdlet to examine saved event log files.<\/a><\/p>\n To do this, I use the following command:<\/p>\n Get-WinEvent -Path C:\\DiagOutPut\\0DB36E58-62C2-45C6-B743-793CC8BA7CAA.Diagnose.1.etl -Oldest | Format-Table id, message -AutoSize -Wrap<\/p>\n<\/blockquote>\n The above command produces nice output, as shown in the following image.<\/p>\n Now that I know that the command works and produces output, I add the Unattended<\/i> switch to my command. The command is shown here:<\/p>\n Get-TroubleshootingPack C:\\Windows\\diagnostics\\system\\Networking |<\/p>\n Invoke-TroubleshootingPack -AnswerFile C:\\fso\\netpack.xml -Result c:\\DiagOutPut –Unattended<\/p>\n<\/blockquote>\n As seen in the following image, when the above command runs, no output appears in the Windows PowerShell console. This is the kind of behavior that is desired for a scheduled command.<\/p>\n It is now time to convert our Windows PowerShell commands into a form that I can use with the Task Scheduler.<\/p>\n For a good overview of using the Task Scheduler to run Windows PowerShell commands, see Use Scheduled Tasks to Run PowerShell Commands on Windows<\/a>.<\/p>\n When I am preparing my command, I will need to first import the TroubleShootingPack<\/b> module. I can do that and separate the remaining command with a semicolon. Keep in mind when creating the scheduled task that the path to the results and the path to the unattended XML file need to be accessible to the Task Scheduler. Here is the command I used. (This is a very, very long command. It is a single-line logical command that is broken into multiple lines for display on the blog. Refer to the previously mentioned Scripting Guy article about using scheduled tasks to run Windows PowerShell commands for the details of the wizard.)<\/p>\n PowerShell.exe -command &{Import-Module tr* ; Get-TroubleshootingPack C:\\Windows\\diagnostics\\system\\Networking | Invoke-TroubleshootingPack -AnswerFile C:\\fso\\netpack.xml -Result c:\\DiagOutPut -Unattended }<\/p>\n<\/blockquote>\n I open the Task Scheduler, create a basic task, and walk through the wizard. After I have created the basic task, I edit the trigger for the task, select the “Repeat task every:” box, and choose 1 hour<\/b> from the drop-down menu. This is shown in the following image.<\/p>\n Of course, the hard part about creating scheduled tasks is waiting for them to run. This one works great, as evidenced by the history tab in the following image.<\/p>\n The last thing I do is check my output folder to ensure that the scheduled task is writing the outputs to the folder. As shown in the following image, this is working as well.<\/p>\n <\/p>\n BR that is all there is to using scheduled tasks to run a Windows PowerShell troubleshooting pack. This also concludes Troubleshooting Week. Join me tomorrow when I will reveal the 2011 Scripting Games Study Guide. This is an awesome resource, and should be of immediate value even if you are not planning on participating in the Games (but I could not imagine anyone not wanting to compete in the 2011 Scripting Games—they will be awesome!)<\/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 them on the Official Scripting Guys Forum.<\/a>. See you tomorrow. Until then, peace.<\/p>\n <\/p>\n Ed Wilson, Microsoft Scripting Guy<\/b><\/p>\n","protected":false},"excerpt":{"rendered":" Summary: Microsoft Scripting Guy Ed Wilson shows how to use Windows PowerShell and scheduled tasks to automate troubleshooting your computer. Hey, Scripting Guy! We have a website that is currently hosted on a rather unreliable server. I am tired of constantly being harassed by management that the server is inaccessible. Unfortunately, we do not […]<\/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,32,3,4,134,45],"class_list":["post-15641","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-getting-started","tag-operating-system","tag-scheduled-tasks","tag-scripting-guy","tag-scripting-techniques","tag-troubleshooting","tag-windows-powershell"],"acf":[],"blog_post_summary":" Summary: Microsoft Scripting Guy Ed Wilson shows how to use Windows PowerShell and scheduled tasks to automate troubleshooting your computer. Hey, Scripting Guy! We have a website that is currently hosted on a rather unreliable server. I am tired of constantly being harassed by management that the server is inaccessible. Unfortunately, we do not […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/15641","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=15641"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/15641\/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=15641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=15641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=15641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n
\n
\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/8081.HSG-2-10-11-01_thumb_422C4549.jpg\" "\\"Image")
<\/a><\/p>\n\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/8507.HSG-2-10-11-02_thumb_70E1D81E.jpg\" "\\"Image")
<\/a><\/p>\n\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/5873.HSG-2-10-11-03_thumb_64440535.jpg\" "\\"Image")
<\/a><\/p>\n\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/8015.HSG-2-10-11-04_thumb_7899A4F3.jpg\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/7853.HSG-2-10-11-05_thumb_07A05E01.jpg\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/7444.HSG-2-10-11-06_thumb_40A71536.jpg\" "\\"Image")
<\/a><\/p>\n