eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The recent revelation that Microsoft covertly installed software on users PCs via the Automatic Updates application has reduced savvy users confidence in the controls they actually have over their computers, while muddying the users role and responsibility in maintaining the operating system.
While it is a patently bad practice for a software company to install code on a machine against a users express permission, this instance was made all the more galling because such actions were unnecessary.
Many users may not care about this finding, having already outsourced their maintenance to the AU agent lock, stock and barrel. However, for users who prefer to assess and improve modifications before they are instituted, the illusion of control over their computer has been ripped away.
Last spring, Microsoft released the latest version of its free, centralized Windows patching solution, WSUS (Windows Server Update Services) 3.0. Version 3.0 included an updated version of the client-side AU engine for Windows XP and Vista, Version 7.0.6000.374. (Ill call it Version .374 from here on out.)
According to a document entitled “WSUS3 Improvements for Distributed Networks” (available at technet.microsoft.com/en-us/wsus/default.aspx), the new AU client provides a few new capabilities, including the ability to install non-Microsoft updates and—for Windows Vista clients only—peer caching for sharing patches among clients in the same domain. The new client also helps alleviate the CPU spiking that some people experienced with the old client.
Microsoft also recently released a new update for corporations using the older WSUS 2.0, a patch that updates the AU client engine to .374. Administrators would run this patch on the WSUS server itself, updating the servers AU install tree. For users of both WSUS 3.0 and the patched 2.0, AU would automatically install the new version on clients the first time they checked in with the patch repository.
Back in June, Microsoft started standardizing the AU engine for consumers as well, pushing out .374 when users scanned their computers with the Windows Update or Microsoft Update Web services. In July, Microsoft started silently pushing .374 to computers checking in for an update via AU—whether the computers were set to install patches automatically, download automatically but not install, or just to notify the user that new patches were available.
There was no public acknowledgment for this move, nor has there been any specific discussion of the features or benefits of the update with the consumer audience. In August, Microsoft also pushed out a new version to AU users, bringing the consumer version of the client engine up to 7.0.6000.381. It was about this time that many users experienced problems with the Windows Genuine Advantage product validation tool, causing many to notice that the AU update had occurred surreptitiously, and, in some cases, without the users consent.
There were few telltale signs of the action: nine updated files and a pair of nondescriptive and unhelpful entries in the Event Viewer System log (see screens, Page 42).
As the news began to circulate widely in mid-September that Microsoft was installing code on users PCs without their explicit permission, Microsoft clarified its position via a blog posted on the Technet site. Written by Nate Clinton, Windows Update program manager, the post acknowledged that the AU client will upgrade itself whenever new code is available when the client checks in with Microsofts servers, no matter what download and install settings the user has chosen.
Clintons post also elaborated that the new code was necessary to allow AU to download additional patches and code later on.
Microsofts response adequately addressed only one of the core issues. Clinton acknowledges that Microsoft can learn from the feedback provided by customers and that the company is looking at ways to provide more clarity to users in the future. Indeed, simply adding a Knowledge Base number to one of the Event Viewer entries, with a pointer to a brief online description of what the patch did, would have satisfied many of the people alarmed by the sudden appearance of new installed code.
On the other hand, Clinton is misleading when he argues that silently pushing the AU update was necessary and acceptable, no matter how users configured AUs behavior, because AU users are expecting patches.
Cautious users—and this includes most enterprise IT managers—configure AU not to automatically install for a reason: They want to research the patches Microsoft is releasing, understand them, vet them and have final approval for installation in their environment. The reasons could vary from change control to paranoia, but Microsoft has given the illusion of this control while silently subverting it in the name of what Microsoft thinks is right.
This aura of technical infallibility pervades both Microsofts initial actions as well as its response. The fact that Microsoft had to deliver a second version of the AU engine just a few weeks after pushing out the first certainly implies there was a flaw in the first version.
Thankfully, in this case, the smoking gun was not loaded. While its delivery system was decidedly suspect, the actual new code seems benign and may actually provide some features that users will greatly appreciate, presuming Microsoft decides to talk about it with customers.
Check out eWEEK.coms for Microsoft and Windows news, views and analysis.