Top 10 Windows 7 Features #8: Automated third-party troubleshooting

Among the stronger and more flourishing cottage industries that have sprouted forth as a result of Microsoft Windows has been documenting all of its problems. One of the most successful of these efforts has been Annoyances.org, which sprouted forth from "Windows Annoyances" -- much of what Internet publishers have learned today about search engine optimization comes from revelations directly gleaned from the trailblazing work of Annoyances.org. Imagine, if you will, if the instructions that Annoyances.org painstakingly gives its readers for how to eradicate those little changes that Microsoft makes without your permission, were encoded not in English but instead in a language that Windows could actually execute on the user's behalf.

Windows 7 is actually making such an environment -- a system where, if you trust someone else other than Microsoft to make corrections to your system, you can accept that someone into your circle of trust and put him to work in Troubleshooting. Can't make that Wi-Fi connection? How do you test for the presence of other interfering signals? Streaming media suddenly get slow, or running in fits and starts? Maybe there's an excess of browser-related processes clogging up memory and resources. Did something you just install cause Flash not to work in your browser? Maybe you don't have time to check the 36 or so places in the Registry where that something altered your file associations.

Last year, Microsoft began making available to some Windows 7 testers what it calls the Troubleshooting Platform, and it's now being distributed as part of the Windows 7 SDK Release Candidate, downloadable today from Fileforum. It contains the development environment for a special type of PowerShell 2.0 script that has the ability to probe clients' systems in an effort to diagnose troubles -- these scripts are the Troubleshooting Packs. Third-party developers will be able to craft Packs that (if they follow the instructions carefully) will be named after the solution they provide rather than the trouble they diagnose.

Then, using a system we still haven't seen even after the Win7 RC's release (there needs to be some Packs in the field first), Microsoft will be these Packs' ultimate distributor, using something called the Windows Online Troubleshooting Service (inevitably to be called "WOTS," we believe). Now, we imagine something akin to an "apps store" for troubleshooting, though there probably won't be a commercial incentive, at least not through WOTS. New Packs may be searchable by category (assuming the user's Win7 works well enough that he can peruse his system), and newly available packs can be set for automatic download -- a setting which assumes a rather Spartan selection in the future, at least from Microsoft itself.

However, a white paper released by Microsoft in late February (Word document available here) leaves open the possibility that WOTS isn't the only place where Windows 7 and Windows Server 2008 R2 users may collect Packs. Addressing Windows network admins, the white paper says, "You can deploy troubleshooting packages, using Group Policy Preferences...to copy them to the local hard drive, or simply store then on a central file server." That implies that anyone can distribute a Troubleshooting Pack -- and if they do so themselves, perhaps they may charge for a collection of, say, 101 or 1,001.

If a little red siren has gone off in your head, that's the usual security warning that accompanies anything Microsoft enables to be done to your system that's automated. It's good to be very, very skeptical. Although it's impossible to imagine such a system not being gamed or exploited at some point in Windows 7's lifecycle, the one very effective security mechanism built into PowerShell is script authentication. This enables script execution to be disabled unless the script writer's signature is trusted. This is important because, although a PowerShell user can disable that particular safeguard for the PowerShell environment, in the context of a Troubleshooting Pack, digital signing is required for Pack authors, and manual acceptance of that signature is required from the user before a Pack can be executed.

What this could mean for the cottage industry built around post-catastrophic support and recovery, is a clarion call for metamorphosis. Rather than write and publish exhaustive 33-step instructions for sometimes mindless "wizards" (such as this little gem), someone with the know-how to ascertain the real problem using tools such as Windows Management Instrumentation (always available through PowerShell) can actually publish real, working solutions in the non-metaphorical sense.