August 15th, 2007

Tech Shakedown #5: Microsoft justifies Vista's forcing of unwanted reboots

Posted by David Berlind @ 9:22 am

Categories: General, IT Management, Personal Technology, Security, Software Infrastructure, Technology Shakedown, Video, Vista

Tags: System, Microsoft Windows Vista, Microsoft Windows, Reboot, Microsoft Corp., User, David Berlind

Two weeks ago, I posted a ZDNet Technology Shakedown video showing how, after downloading and installing some updates, Windows Vista initiated a forced reboot of itself without allowing me the option to postpone that reboot. The options were there. But they were inaccessible. I was critical of the experience because the odds are pretty good that a user of Windows Vista could be in the middle of doing something important with their PC that can’t be delayed because of a forced reboot. For example, they could be participating in a realtime online conference of some sort (eg: with something like WebEx). Or what if the user was under the gun to get something done by a certain deadline? I can’t possibly count with two hands how many times I’ve had something that takes 30 minutes to do, but only 15 minutes to do it. In situations like that, I’d most certainly blow a gasket if my operating system forced a reboot of itself.

Anyway, that video caused quite a stir and judging by the responses both in the comments area and in my e-mail, a lot of people asked for the gory details, many in hopes of proving that it was my fault rather than a design flaw in Windows Vista. At the very least, since many ZDNet readers weren’t seeing the same behavior in their Vista-based systems, it merited further testing and investigation with Microsoft. As you can see in the video attached to this blog, I reproduced the testing conditions and was able to determine the single gating factor that controlled whether or not the option to delay a forced reboot is available to an end-user of Vista. Furthermore, I was able to confirm the behavior with Microsoft who sees this not as a bug, but as a feature of Vista. In other words, Vista behaves this way by design: a decision I find troubling given the sort of interruption it can lead to.

So what in my configuration of Windows Vista was the culprit? It’s the fact that I was logged into Vista as a standard user instead of an administrative user. According to Microsoft, if the administrator of a system (even a stand alone system that’s not joined to some organizational domain) has set Windows Update to automatically download and install updates (as I have) and a reboot is required for those installations to complete themselves (not always the case), that reboot will be a forced one with no opportunity to postpone if you’re logged into Windows Vista as a standard user.

A lot has been written about the differences between administrative and standard users in Windows Vista. As can be seen from the partial screenshot below, Vista’s user interface strongly recommends that users of Vista be standard, and not administrative users (continued below).

When logged into Windows Vista as a standard user, the likelihood that the user or any malware that inherits the rights of that user can do serious damage to the operating system is greatly reduced, if not completely eliminated. When logged-in as a standard user, doing anything that requires system-level access also requires the entry of administrative credentials. Even if you’re logged in as an administrative user, Vista will prompt you to bless any operation (ie: modifying a user account, installing/uninstalling software, etc.) that could potentially affect sensitive areas of the system.

In trying to keep my systems as secure as possible, I try to heed Microsoft’s advice. I’ve set my systems (XP and Vista) to automatically update themselves and, in the case of Vista, I’ve been running my systems as a standard user (and have recommended the same to ZDNet’s readers). But, as Microsoft explained to me, in so doing, I’ve subject myself to the forced reboot phenomenon.

In a dialog involving several back-n-forth e-mails, a Microsoft spokesperson responded to my original inquiry as follows:

What happened [in my case] was that [Vista's] Automatic Update (AU) had downloaded updates and was ready to install them at the scheduled 3am time [the time I have Windows Update scheduled to run]. [You] shutdown the system without installing the updates. Upon turning the machine on, AU realized that the scheduled install was missed and so the install was initiated (immediately starting the install vs. waiting for the next schedule time is controllable by policy). Starting the installation as soon as possible is the safest and most secure default. The install of the update required a reboot in order to complete the installation and secure the machine. Because an administrative user had configured the machine to automatically stay up to date, the reboot is not postpone-able by a non-admin. Allowing a non-admin to override an admin’s wish is not the right default for security sake. This behavior is also controllable by policy to allow a non-admin user to interact with Windows Update.

So yes, what [you] experienced is by design and justifiable as it does not allow a non-admin to go against the wishes of the administrative user. And again if running as a non-admin is his normal mode of operation, then there are policies which can be set to tweak behaviors more to his liking.

I was a bit confused by this response, mostly because my machine wasn’t joined to an organizational domain through which central policies regarding standard user access to administrative functions are normally implemented. The note is written as though Vista provides some policy-setting feature that can grant standard users whatever administrative access they need to change the settings of Windows Update. I couldn’t find an easy way to do this. Via a subsequent round of e-mails, that spokesperson explained:

Local policy can also be configured for non-domain joined machines. This is done through gpedit.msc. this will only exist on [Vista's] business [versions] and Ultimate. setting the regkeys directly is described in the WSUS deployment guide.

I could opine for several more pages regarding the restriction of this facility to the Business and Ultimate versions of Vista or the fact that making these policy adjustments is far easier said than done (editing the registry is not for the faint at heart). But, in these case, it’s better to see the forest from the trees. I can see where, if an IT manager at some organization says “thou shalt update your systems according to our rules and not yours,” the affected systems and their users may, for corporate security reasons, be subject to forced reboots. I’m not sure if such a policy would make a lot of friends in userland. But business IT departments can and do set such company wide policies.

But in the case of individual users on their systems that are not joined to some domain or subject to some organizational update edict, a forced reboot without the option to postpone seems rather harsh. When configuring Windows Update, either when Vista is “burned-in” for the first time during the out of box experience or later (through the Tools menu in Internet Explorer), the user interface does not adequately communicate that automatic updates means “forced reboot” as well for standard users. Since many users of Vista will have earned their Windows chops on Windows XP, their expectation (since most ran XP as administrators…. running XP in standard user mode was pretty much impossible) will be that they’ll have the opportunity to delay such reboots and that offering that option to postpone updates is simply part of the rubrick of updating Windows (as it appeared to be in XP).

At the very least, as stated in the video above, the option to postpone an update installation should be available to standard users who are prepared to supply administrative credentials as a part of the same escalation process that takes place when standard users attempt other tasks that require administrative access.