"Berndl666" <Berndl666@discussions.microsoft.com> wrote in message
news:AD2BCBB2-224A-4401-827C-3607B7F0F209@microsoft.com...
> Lawrence:
>
> True, Patch Tuesday is a special event. but unlike in the U.S. here in
> Europe we can never be sure when these updates will be available. due to the
> time shift (remember, earth is not a plain with America in the middle) it
> might be tuesday noon, evening or even late wednesday morning until the
> Windows Update service bites and launches the update installation.

Okay.. let me provide you with some /known/ information that will help you
"plan" accordingly.

First.... I'm told that MS generally releases this Patch Tuesday content in
the afternoon Pacific Time. That would make it approximately midnight
Wednesday GMT. I've been able to confirm this for the most part, as I moved my
WSUS server synchronization to 8pm CT (0200 GMT) and the content has always
been there for me at that time.

Second.... the design of the Windows Update Agent (and the AU client which
preceeded this rev) is to execute a detection for new updates every 22 hours
(minus a random offset of 1-20%). This means that the WUA actually contacts
the Microsoft Update (or SUS/WSUS servers) every 17.6-22 hours.

The net effect of that is that a client can /detect/ and /download/ the
updates at anytime during the 22 hours from the time Microsoft releases the
content (approx midnite GMT).

The /installation/ of the content, however, is entirely under the control of
the end-user and has ALWAYS been under the exclusive control of the end-user.
The end-user can:
(a) Schedule the updates to be installed at at given local time. By
default, this is 3am local time, so the actual installation will depend on
when the detection occurs and the download completes. For Europe, the greatest
percentage of clients will install at 3am local time on Thursday morning
(since it's not likely the detection and downloads will be completed by 3am
local time on Wednesday).
(b) Require the WUA to notify the user when updates are ready to be
installed, and install them interactively - thus also giving the user full
control over /when/ the system is rebooted -- if for no other reason than by
just givint them control over when the updates are /installed/.

By default, (a) is 3:00am local time, but can be set in one hour increments to
any time of day. The nature of the Windows Operating System architecture is
that updates will, quite likely, require a restart, and the WUA will restart
the computer five minutes after the completion of the installation of the
updates.

In fact, the idea of "installation" of the updates is a misnomer, because, in
reality, it is the /restart/ of the system that causes the actual
installation. The pre-reboot process merely stages the files in a temp folder,
so that script can copy them into place in the system32 folder /before/ those
files are loaded in the boot up process.

For a normal user, the restart after installation is enforced restart. For a
user with Administrative privileges, they'll also be presented with an option
to defer the restart.

In addition, the WUA has several options that can be configured via Group
Policy or Local Policy, even if the WUA is being used exclusively in an
Automatic Updates scenario (no SUS/WSUS server). These options include:
- extending the delay from completion of installation to initiation of
restart (up to 30 minutes).
- allowing a 'restart later' sceneario, with a recurring popup to reboot
(configurable up to 24 hours)
- scheduling of installations at a time convenient for the user
- scheduling of downloading of content at a time convenient for the user
(most typically useful for notebook users who are intermittently connected)
- the use of BITS for auto-restart of downloads in progress, as well as
the ability to throttle when and how much bandwidth is used to transfer
content
- the ability to execute "Install Updates and Shutdown" on Windows XP SP2
and Windows Server 2003 SP1 systems
- allowing or disallowing the installation of updates at powerup if the
'scheduled' installation cycle was missed

> and please
> allow me one more dumb question: why can only admins postpone the restart?

Because postponing the restart should /not/ be done in normal scenarios, and
regular users should not have that ability ot interfere with /necessary/
functionality of update management. The assumption (although quite dangerous)
is that Administrators have the requisite understanding of the implications of
delaying the restart of the system when updates are being installed. Let me
expressly enumerate these implications:
(1) Until the system is restarted, the updates is NOT installed, and the
system is NOT protected by the update.
(2) While the system is not restarted, the system COULD also be in an
unstable state if part of that update WAS installed and part of that update
was NOT installed.

Of course a BSOD will 'fix' the problem in (2) by forcing a reboot, thus
repairing the cause of the instability.

> in the companies I and my team are working its mostly plain users that work
> on
> their machines.
> everything would be just fine if the average user would get the admin
> messagebox for the restart and have a CHOICE.

Everything would be fine, also, if the product were used as originally
designed, which is to install update during non-working hours, and to not even
involve USERS in the process AT ALL!

However.. if you want the "average user" to have full permissions.... simply
enable the policy:
"Allow non-admins to receive update notifications".

Presto! Done!

And... it's /all/ documented.... just gotta read the docs. :-)