Windows PowerShell: Troubleshooting Packs
The new Troubleshooting Packs in Windows 7 help walk you through some of the most common problems you’re likely to encounter.
Troubleshooting Windows 7 may be easier than you think. There are several new Troubleshooting Packs included in Windows 7, along with an infrastructure that supports these and future types of Troubleshooting Packs.
These packs present you with a GUI—a sort of wizard, really—that walks you through specific problems and makes suggestions to correct those problems. In many cases, packs can even automatically apply suggested fixes, helping you resolve problems more quickly and with less technical expertise.
Wait … GUI and wizards in a Windows PowerShell column? Don’t worry: I haven’t taken leave of my senses—any more than usual.
Like many other aspects of Windows Server 2008 R2 and Windows 7, these Troubleshooting Packs are built “on top of” Windows PowerShell, in a way. While you can access them through a GUI, you can also use the Windows PowerShell command line. Doing it this way opens up incredible new ways to automate troubleshooting and problem resolution for you, your users and even your servers.
Take note that this is only available on Windows 7 and Windows Server 2008 R2. It will presumably be available in later versions of Windows as well.
Start by importing the new TroubleshootingPack module into the shell:
To get a look at the commands added by this module, run:
Get-Command –module troubleshootingpack
A whopping two new cmdlets will appear: Get-TroubleshootingPack and Invoke-TroubleshootingPack.
Well, that shouldn’t be too complicated. Running Get-TroubleshootingPack, however, immediately prompts you for a path. It’s uncertain what it wants there. The best solution is to read the help—specifically, the examples.
Running Help Get-TroubleshootingPack –example will reveal that the command expects the path of a Troubleshooting Pack on disk. These packs are stored in C:\Windows\Diagnostics by default, under a hierarchy of subfolders. The \index subfolder contains a list of available packs. The \system folder contains all of the currently installed packs.
The packs available on a system may vary depending on the features and software installed. For example, some applications may install their own packs. They may even place those in a different subfolder. Let’s start by getting the Power Troubleshooting Pack:
Get-TroubleshootingPack c:\windows\diagnostics\system\power | fl *
That returns a list of the pack’s properties, including its version, publisher and so on. It doesn’t really do much, but it does let you know what versions of Windows it supports, including Server and Client, as well as x86 and Amd64 and IA64 architectures. To run the troubleshooter, you can pipe the pack itself to Invoke-TroubleshootingPack:
Get-TroubleshootingPack c:\windows\diagnostics\system\power | Invoke-TroubleshootingPack
Doing this invokes the pack in interactive mode. Rather than a GUI wizard, though, you’ll get a command-line-friendly text menu system that prompts you through the pack’s troubleshooting process.
If you want to run a Troubleshooting Pack through a particular set of checks without having to manually specify all the menu options, specify an XML answer file. Use the –answer paramater of Invoke-TroubleshootingPack. Then direct the pack to run in unattended mode using the –unattend parameter.
You can create a template answer file using Get-TroubleshootingPack with the –answer parameter and a filename:
Get-TroubleshootingPack c:\windows\diagnostics\system\power –answer power-answers.xml
The specified Troubleshooting Pack will run and prompt you for all the normal questions. Instead of taking an action, it will save the results to an XML answer file. You can then use this as input to Invoke-TroubleshootingPack.
This is a great way to create standardized troubleshooting routines for common problems. You could provide those answer files to your help desk, for example, so they can run through predefined processes more quickly, consistently and efficiently.
Want to reach out and troubleshoot someone? Windows PowerShell version 2 has great remoting capabilities. You can enable these on client computers just as easily as you do on servers. As long as a user’s network is operating, you’re in. Just run something like this:
Enter-PSSession –computername WIN7G4T53R Get-TroubleshootingPack c:\windows\diagnostics\system\aero | Invoke-TroubleshootingPack
You’ll be running the Troubleshooting Pack on the remote computer, from the comfort of your own workstation. Here are some tips for doing so:
- Make sure your fellow IT pros have a way to quickly look up the computer names of your users’ computers
- Use Group Policy to enable WinRM and Windows PowerShell remoting on all your client computers
- Store Troubleshooting Pack answer files on a file server. The –answer parameter of both Troubleshooting Pack cmdlets will accept a UNC, so you don’t need to map a drive. Use a DFSR UNC and store replicas of your answer packs in various locations throughout your organization, so answer files will be handy to all your client computers.
Automated, Remote Command-Line Troubleshooting
The new Troubleshooting Packs, along with their accessibility from within Windows PowerShell, add a lot of new capabilities. You can troubleshoot Aero, Audio, Devices, Internet Explorer, Networking, PCW, Performance, Power, Printers, Search, Windows Media and Windows Update—and that’s just some of what’s available today.
Rather than walking your users through the process over the phone (“Click next … click next again … no, not twice … no, now click back … no … no, now just reboot your computer!”), you can take direct control of the troubleshooting process right on their computers. You won’t need higher-overhead techniques like remote desktop, remote assistance and so on.
Don Jones* is a founder of Concentrated Technology, and answers questions about Windows PowerShell and other technologies at ConcentratedTech.com. He’s also an author for Nexus.Realtimepublishers.com, which makes many of his books available as free electronic editions through his web site.*