Multiple reboots the same night

One of the problems I am facing with WSUS is that I need to be able
to approve and install updates the night before I visit a client. I want all
approved updates to be installed that night, even if it takes five restarts
that night to get the job done. I don't want the process stretching over two
or three or more nights because multiple reboots were required. I actually
think this is a problem with the Automatic Updates settings rather than WSUS
itself, but it would be nice to be able to set a Group Policy that allows
for multiple installations the same day, say at 1 AM, 2 AM, 3 AM, and 4 AM.

"Andrew M. Saucci, Jr." <spam-> wrote in message
news:%...

> I don't want the process stretching over two
> or three or more nights because multiple reboots were required. I actually
> think this is a problem with the Automatic Updates settings rather than
> WSUS
> itself


This is not a "problem", per se, it's part of the design of the system.
Using scheduled installation events is restricted to one restart event per
installation event, under normal conditions -- ergo one restart per day.
This is not configurable.

The need for multiple restarts is wholly dependent upon the nature of
updates released and approved each cycle. Some updates may be classified as
mandatory, or exclusive. Mandatory updates must be installed before any
other updates, and they almost always require a system restart. Such updates
are typically WSUS-required updates, Windows Installer, Package Installer,
or such updates.

Exclusive updates are updates that must be installed exclusive of any other
update. They, also, almost always require a restart. Such update are
typically service packs, or major application installations, such as IE7,
WMP11, etc.

Once all mandatory and exclusive updates are installed, the rest of the
updates are then installed, and may require yet another system restart.

Whether an installation cycle requires zero, one, two, or even three system
restarts is directly a function of the updates that have been approved. You
can control that behavior by being aware of what it is you're approving for
install -- and, so, part of the point here is that the patch administrator
has to take responsibility for being aware of what's been approved, what the
requirements are to effect the update installations in the manner desired,
and to be aware of what the machine behaviors are going to be in response to
the approved updates.

The one-restart-per-day situation can, however, be overridden by the
strategic use of deadlines, which effectively create additional installation
events. Consider a scenario with three updates: a mandatory (Package
Installer) update, an exclusive update (IE7), and a standard security
update. Under normal operation these updates will take three installation
cycles, three days, to get all installed.

However, by being aware of the order in which they would normally be
installed, you can force the subsequent installation of the exclusive and
standard security update on the same day by assigning a deadline to those
updates. If the scheduled installation event is for 3am, the mandatory
update will be detected after approval, and installed at 3am (assuming, of
course, it's successfully downloaded after approval and detection).

By assigning a deadline of 3am (the installation start time) to the other
two updates, you can force their installation to occur A.S.A.P. after the
scheduled installation start time and the successful installation of the
mandatory update. In effect, the mandatory update will install at 3am and
cause a restart. After the restart, and because the deadline for the
exclusive update has expired, the exclusive update will then be immediately
installed and cause another restart. Finally, after that restart, and
because the deadline for the standard security update has expired, the
security update will then be immediately installed and cause one more
restart. All of this would likely occur within the space of about 15-20
minutes, depending on the actual installation time required by each update.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Thanks for a very insightful answer. Are the update classifications
obvious in the WSUS console (don't have one in front of me right now) or
would I have to read through the description of each update to determine
which ones are mandatory or exclusive? It's an interesting workaround to
what I consider to be a serious defect in the WSUS/Automatic Updates design.

Sometimes the problem is that the console is showing just too many
updates. The network I updated this week has Windows 2008 x86 servers,
Windows 2003 x86 servers, a Windows 2008 x64 server, and XP Professional
workstations plus Office XP, Office 2003, and Office 2007. Each platform
generates its own updates, perhaps with different classifications. I hadn't
let it go too long, but I had 155 updates to review. If I can't figure it
out in a few seconds, that's a big problem in addition to my many other
responsibilities. As it is, I probably spent half an hour to an hour just
approving any update that was not superseded by another update.

I think the other problem is that many people just use WSUS as a
mega-Automatic Updates set to approve everything automatically, which I
believe is foolish. The network I just described is a property management
firm. Network disruption can't occur on Microsoft's schedule; it has to
occur on the firm's schedule. I've already been told only to do this sort of
thing towards the middle of the month. The beginning of the month they're
posting rent payments, and the end of the month they're sending rent bills.
If, as I suspect, most people just approve everything automatically, the
concept I described is probably totally foreign to Microsoft's developers--
yet it is rather sound network management.


"Lawrence Garvin [MVP]" <> wrote in message
news:%...
> "Andrew M. Saucci, Jr." <spam-> wrote in message
> news:%...
>
> > I don't want the process stretching over two
> > or three or more nights because multiple reboots were required. I
actually
> > think this is a problem with the Automatic Updates settings rather than
> > WSUS
> > itself
>
>
> This is not a "problem", per se, it's part of the design of the system.
> Using scheduled installation events is restricted to one restart event per
> installation event, under normal conditions -- ergo one restart per day.
> This is not configurable.
>
> The need for multiple restarts is wholly dependent upon the nature of
> updates released and approved each cycle. Some updates may be classified
as
> mandatory, or exclusive. Mandatory updates must be installed before any
> other updates, and they almost always require a system restart. Such
updates
> are typically WSUS-required updates, Windows Installer, Package Installer,
> or such updates.
>
> Exclusive updates are updates that must be installed exclusive of any
other
> update. They, also, almost always require a restart. Such update are
> typically service packs, or major application installations, such as IE7,
> WMP11, etc.
>
> Once all mandatory and exclusive updates are installed, the rest of the
> updates are then installed, and may require yet another system restart.
>
> Whether an installation cycle requires zero, one, two, or even three
system
> restarts is directly a function of the updates that have been approved.
You
> can control that behavior by being aware of what it is you're approving
for
> install -- and, so, part of the point here is that the patch administrator
> has to take responsibility for being aware of what's been approved, what
the
> requirements are to effect the update installations in the manner desired,
> and to be aware of what the machine behaviors are going to be in response
to
> the approved updates.
>
> The one-restart-per-day situation can, however, be overridden by the
> strategic use of deadlines, which effectively create additional
installation
> events. Consider a scenario with three updates: a mandatory (Package
> Installer) update, an exclusive update (IE7), and a standard security
> update. Under normal operation these updates will take three installation
> cycles, three days, to get all installed.
>
> However, by being aware of the order in which they would normally be
> installed, you can force the subsequent installation of the exclusive and
> standard security update on the same day by assigning a deadline to those
> updates. If the scheduled installation event is for 3am, the mandatory
> update will be detected after approval, and installed at 3am (assuming, of
> course, it's successfully downloaded after approval and detection).
>
> By assigning a deadline of 3am (the installation start time) to the other
> two updates, you can force their installation to occur A.S.A.P. after the
> scheduled installation start time and the successful installation of the
> mandatory update. In effect, the mandatory update will install at 3am and
> cause a restart. After the restart, and because the deadline for the
> exclusive update has expired, the exclusive update will then be
immediately
> installed and cause another restart. Finally, after that restart, and
> because the deadline for the standard security update has expired, the
> security update will then be immediately installed and cause one more
> restart. All of this would likely occur within the space of about 15-20
> minutes, depending on the actual installation time required by each
update.
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> MS WSUS Website: http://www.microsoft.com/wsus
> My Websites: http://www.onsitechsolutions.com;
> http://wsusinfo.onsitechsolutions.com
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"Andrew M. Saucci, Jr." <spam-> wrote in message
news:OY%...
> Thanks for a very insightful answer. Are the update classifications
> obvious in the WSUS console (don't have one in front of me right now) or
> would I have to read through the description of each update to determine
> which ones are mandatory or exclusive?

The update metadata contains a flag value that can be viewed in the update
details for exclusive updates: "Must be installed exclusively". There is no
direct metadata flag for mandatory updates, but generally those are coded as
"WSUS Updates" and can be viewed by selecting the "WSUS Updates" view.

And, of course, one would presumably be aware of their actual behavior after
performing a TEST installation on a TEST machine.


> It's an interesting workaround to
> what I consider to be a serious defect in the WSUS/Automatic Updates
> design.

While I appreciate your frustration with the situation -- how would you
expect the environment to deal with the conditions where:
[a] Update 'x' MUST be installed before any other update can be reliably
installed, or
[b] Update 'y' MUST be installed by itself because it has such a far
reaching impact on the system that trying to install it with anything else
could create such havoc as possibly rendering the system unstable, if not
unrunnable.


> Sometimes the problem is that the console is showing just too many
> updates.

The key here is to learn to use the UI. Filtering on approval status and
update status, as well as creating custom Update Views will help
significantly.


> The network I updated this week has Windows 2008 x86 servers,
> Windows 2003 x86 servers, a Windows 2008 x64 server, and XP Professional
> workstations plus Office XP, Office 2003, and Office 2007. Each platform
> generates its own updates, perhaps with different classifications. I
> hadn't
> let it go too long, but I had 155 updates to review. If I can't figure it
> out in a few seconds, that's a big problem in addition to my many other
> responsibilities. As it is, I probably spent half an hour to an hour just
> approving any update that was not superseded by another update.

It's unfortunate that you invested so much inefficient time. The WSUS
Operations Guide is an excellent resource for some of the how-tos, and to be
honest, the UI design is quite mature -- over four years old now -- and one
way or another, I imagine we've discussed every possible use and workaround
possible in this forum.

For example, a quick way to handle supercession issues is:
[a] Enable the superseded flag column.
[b] Sort on the superseded flag.
[c] Filter for updates that are Not Approved and Needed.
[d] Approve the displayed updates that:
[1] Have no flag at all (indicating they have no superseded
updates)
[2] Have a blue box at the top of the tree (indicating they're
the newest).

Then, after all Needed updates are Approved and Installed, you can use the
same sort to select all of the superseded updates and Decline them.


> I think the other problem is that many people just use WSUS as a
> mega-Automatic Updates set to approve everything automatically,

While I'm not interested in arguing a point I have no empirical data for, I
think this is highly unlikely. If the thousands of conversations in this
forum over the past four years are any indication, only the very smallest of
organizations have configured their WSUS Server to be a glorified mega-AU
server. In fact, doing so controverts the very reason for investing in the
deployment of WSUS in the first place.

> which I believe is foolish.

I agree... which is why I disagree with your (likely unsubstantiated)
opinion.


> The network I just described is a property management
> firm. Network disruption can't occur on Microsoft's schedule; it has to
> occur on the firm's schedule.

And *THAT* is exactly the reason why WSUS exists!

> I've already been told only to do this sort of
> thing towards the middle of the month.

That makes perfectly good sense. Updates are generally released on the 2nd
Tuesday of the month, mathematically making that occur between the 8th and
the 14th of every month. Allowing for some nominal testing (or delay to see
if anybody else has issues), the 15th to the 25th is about the time frame
most every organization deploys updates.

> If, as I suspect, most people just approve everything automatically, the
> concept I described is probably totally foreign to Microsoft's
> developers--
> yet it is rather sound network management.

Luckily, I don't believe either of these points to be the case, and the
capabilities of the product heavily contradict the idea that "most people
just approve everything", or that the "concept... is foreign to [the]
developers" --- all, of which, I have personally met on numerous occassions.
I can assure you, the WSUS and WUA developers are intimately familiar with
the needs of organizations concerning update management.

Now, with all due respect Andrew, I'll do my best to be as helpful to you as
I can, and help you become better educated and familiar with the product,
including some of the 'tips and tricks'. But you've also come into this
forum, with an obvious deficiency in understanding the whys and hows of a
mature product -- and generally one of the better liked products in the
entire Microsoft catalog. I'd suggest, if at all possible, that you tone
down the negative and uninformed rhetoric a bit, and use this opportunity to
ASK first, and save the criticisms for a later time.

--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

And there is a reason the updates are scheduled at 0300. UNless you are
running your desktops 24/7, updating at 0300 should produce no
disruption. Then needing 3 nights to properly update the systems is no
problem.

"Lawrence Garvin [MVP]" <> wrote in
news::

> "Andrew M. Saucci, Jr." <spam-> wrote in message
> news:OY%...
>> Thanks for a very insightful answer. Are the update
>> classifications
>> obvious in the WSUS console (don't have one in front of me right now)
>> or would I have to read through the description of each update to
>> determine which ones are mandatory or exclusive?
>
> The update metadata contains a flag value that can be viewed in the
> update details for exclusive updates: "Must be installed exclusively".
> There is no direct metadata flag for mandatory updates, but generally
> those are coded as "WSUS Updates" and can be viewed by selecting the
> "WSUS Updates" view.
>
> And, of course, one would presumably be aware of their actual behavior
> after performing a TEST installation on a TEST machine.
>
>
>> It's an interesting workaround to
>> what I consider to be a serious defect in the WSUS/Automatic Updates
>> design.
>
> While I appreciate your frustration with the situation -- how would
> you expect the environment to deal with the conditions where:
> [a] Update 'x' MUST be installed before any other update can be
> reliably
> installed, or
> [b] Update 'y' MUST be installed by itself because it has such a
> far
> reaching impact on the system that trying to install it with anything
> else could create such havoc as possibly rendering the system
> unstable, if not unrunnable.
>
>
>> Sometimes the problem is that the console is showing just too many
>> updates.
>
> The key here is to learn to use the UI. Filtering on approval status
> and update status, as well as creating custom Update Views will help
> significantly.
>
>
>> The network I updated this week has Windows 2008 x86 servers,
>> Windows 2003 x86 servers, a Windows 2008 x64 server, and XP
>> Professional workstations plus Office XP, Office 2003, and Office
>> 2007. Each platform generates its own updates, perhaps with different
>> classifications. I hadn't
>> let it go too long, but I had 155 updates to review. If I can't
>> figure it out in a few seconds, that's a big problem in addition to
>> my many other responsibilities. As it is, I probably spent half an
>> hour to an hour just approving any update that was not superseded by
>> another update.
>
> It's unfortunate that you invested so much inefficient time. The WSUS
> Operations Guide is an excellent resource for some of the how-tos, and
> to be honest, the UI design is quite mature -- over four years old now
> -- and one way or another, I imagine we've discussed every possible
> use and workaround possible in this forum.
>
> For example, a quick way to handle supercession issues is:
> [a] Enable the superseded flag column.
> [b] Sort on the superseded flag.
> [c] Filter for updates that are Not Approved and Needed.
> [d] Approve the displayed updates that:
> [1] Have no flag at all (indicating they have no
> superseded
> updates)
> [2] Have a blue box at the top of the tree (indicating
> they're
> the newest).
>
> Then, after all Needed updates are Approved and Installed, you can use
> the same sort to select all of the superseded updates and Decline
> them.
>
>
>> I think the other problem is that many people just use WSUS as
>> a
>> mega-Automatic Updates set to approve everything automatically,
>
> While I'm not interested in arguing a point I have no empirical data
> for, I think this is highly unlikely. If the thousands of
> conversations in this forum over the past four years are any
> indication, only the very smallest of organizations have configured
> their WSUS Server to be a glorified mega-AU server. In fact, doing so
> controverts the very reason for investing in the deployment of WSUS in
> the first place.
>
>> which I believe is foolish.
>
> I agree... which is why I disagree with your (likely unsubstantiated)
> opinion.
>
>
>> The network I just described is a property management
>> firm. Network disruption can't occur on Microsoft's schedule; it has
>> to occur on the firm's schedule.
>
> And *THAT* is exactly the reason why WSUS exists!
>
>> I've already been told only to do this sort of
>> thing towards the middle of the month.
>
> That makes perfectly good sense. Updates are generally released on the
> 2nd Tuesday of the month, mathematically making that occur between the
> 8th and the 14th of every month. Allowing for some nominal testing (or
> delay to see if anybody else has issues), the 15th to the 25th is
> about the time frame most every organization deploys updates.
>
>> If, as I suspect, most people just approve everything automatically,
>> the concept I described is probably totally foreign to Microsoft's
>> developers--
>> yet it is rather sound network management.
>
> Luckily, I don't believe either of these points to be the case, and
> the capabilities of the product heavily contradict the idea that "most
> people just approve everything", or that the "concept... is foreign to
> [the] developers" --- all, of which, I have personally met on numerous
> occassions. I can assure you, the WSUS and WUA developers are
> intimately familiar with the needs of organizations concerning update
> management.
>
> Now, with all due respect Andrew, I'll do my best to be as helpful to
> you as I can, and help you become better educated and familiar with
> the product, including some of the 'tips and tricks'. But you've also
> come into this forum, with an obvious deficiency in understanding the
> whys and hows of a mature product -- and generally one of the better
> liked products in the entire Microsoft catalog. I'd suggest, if at all
> possible, that you tone down the negative and uninformed rhetoric a
> bit, and use this opportunity to ASK first, and save the criticisms
> for a later time.
>

Asher_N wrote:

> And there is a reason the updates are scheduled at 0300. UNless you are
> running your desktops 24/7, updating at 0300 should produce no
> disruption. Then needing 3 nights to properly update the systems is no
> problem.

I disagree. The problem is that the machine is (very likely) vulnerable to
various attacks during the three days.

Harry.

>
> "Lawrence Garvin [MVP]" <> wrote in
> news::
>
>> "Andrew M. Saucci, Jr." <spam-> wrote in message
>> news:OY%...
>>> Thanks for a very insightful answer. Are the update
>>> classifications
>>> obvious in the WSUS console (don't have one in front of me right now)
>>> or would I have to read through the description of each update to
>>> determine which ones are mandatory or exclusive?
>> The update metadata contains a flag value that can be viewed in the
>> update details for exclusive updates: "Must be installed exclusively".
>> There is no direct metadata flag for mandatory updates, but generally
>> those are coded as "WSUS Updates" and can be viewed by selecting the
>> "WSUS Updates" view.
>>
>> And, of course, one would presumably be aware of their actual behavior
>> after performing a TEST installation on a TEST machine.
>>
>>
>>> It's an interesting workaround to
>>> what I consider to be a serious defect in the WSUS/Automatic Updates
>>> design.
>> While I appreciate your frustration with the situation -- how would
>> you expect the environment to deal with the conditions where:
>> [a] Update 'x' MUST be installed before any other update can be
>> reliably
>> installed, or
>> [b] Update 'y' MUST be installed by itself because it has such a
>> far
>> reaching impact on the system that trying to install it with anything
>> else could create such havoc as possibly rendering the system
>> unstable, if not unrunnable.
>>
>>
>>> Sometimes the problem is that the console is showing just too many
>>> updates.
>> The key here is to learn to use the UI. Filtering on approval status
>> and update status, as well as creating custom Update Views will help
>> significantly.
>>
>>
>>> The network I updated this week has Windows 2008 x86 servers,
>>> Windows 2003 x86 servers, a Windows 2008 x64 server, and XP
>>> Professional workstations plus Office XP, Office 2003, and Office
>>> 2007. Each platform generates its own updates, perhaps with different
>>> classifications. I hadn't
>>> let it go too long, but I had 155 updates to review. If I can't
>>> figure it out in a few seconds, that's a big problem in addition to
>>> my many other responsibilities. As it is, I probably spent half an
>>> hour to an hour just approving any update that was not superseded by
>>> another update.
>> It's unfortunate that you invested so much inefficient time. The WSUS
>> Operations Guide is an excellent resource for some of the how-tos, and
>> to be honest, the UI design is quite mature -- over four years old now
>> -- and one way or another, I imagine we've discussed every possible
>> use and workaround possible in this forum.
>>
>> For example, a quick way to handle supercession issues is:
>> [a] Enable the superseded flag column.
>> [b] Sort on the superseded flag.
>> [c] Filter for updates that are Not Approved and Needed.
>> [d] Approve the displayed updates that:
>> [1] Have no flag at all (indicating they have no
>> superseded
>> updates)
>> [2] Have a blue box at the top of the tree (indicating
>> they're
>> the newest).
>>
>> Then, after all Needed updates are Approved and Installed, you can use
>> the same sort to select all of the superseded updates and Decline
>> them.
>>
>>
>>> I think the other problem is that many people just use WSUS as
>>> a
>>> mega-Automatic Updates set to approve everything automatically,
>> While I'm not interested in arguing a point I have no empirical data
>> for, I think this is highly unlikely. If the thousands of
>> conversations in this forum over the past four years are any
>> indication, only the very smallest of organizations have configured
>> their WSUS Server to be a glorified mega-AU server. In fact, doing so
>> controverts the very reason for investing in the deployment of WSUS in
>> the first place.
>>
>>> which I believe is foolish.
>> I agree... which is why I disagree with your (likely unsubstantiated)
>> opinion.
>>
>>
>>> The network I just described is a property management
>>> firm. Network disruption can't occur on Microsoft's schedule; it has
>>> to occur on the firm's schedule.
>> And *THAT* is exactly the reason why WSUS exists!
>>
>>> I've already been told only to do this sort of
>>> thing towards the middle of the month.
>> That makes perfectly good sense. Updates are generally released on the
>> 2nd Tuesday of the month, mathematically making that occur between the
>> 8th and the 14th of every month. Allowing for some nominal testing (or
>> delay to see if anybody else has issues), the 15th to the 25th is
>> about the time frame most every organization deploys updates.
>>
>>> If, as I suspect, most people just approve everything automatically,
>>> the concept I described is probably totally foreign to Microsoft's
>>> developers--
>>> yet it is rather sound network management.
>> Luckily, I don't believe either of these points to be the case, and
>> the capabilities of the product heavily contradict the idea that "most
>> people just approve everything", or that the "concept... is foreign to
>> [the] developers" --- all, of which, I have personally met on numerous
>> occassions. I can assure you, the WSUS and WUA developers are
>> intimately familiar with the needs of organizations concerning update
>> management.
>>
>> Now, with all due respect Andrew, I'll do my best to be as helpful to
>> you as I can, and help you become better educated and familiar with
>> the product, including some of the 'tips and tricks'. But you've also
>> come into this forum, with an obvious deficiency in understanding the
>> whys and hows of a mature product -- and generally one of the better
>> liked products in the entire Microsoft catalog. I'd suggest, if at all
>> possible, that you tone down the negative and uninformed rhetoric a
>> bit, and use this opportunity to ASK first, and save the criticisms
>> for a later time.
>>
>

"Harry Johnston [MVP]" <> wrote in message
news:%...

> Asher_N wrote:
>
>> And there is a reason the updates are scheduled at 0300. UNless you are
>> running your desktops 24/7, updating at 0300 should produce no
>> disruption. Then needing 3 nights to properly update the systems is no
>> problem.

> I disagree. The problem is that the machine is (very likely) vulnerable
> to various attacks during the three days.

It also should be noted that three days to deploy this collection of updates
is a *highly unusual* scenario.

Furthermore, just a nominal bit of awareness on the part of an administrator
can be immediately realized by not approving the exclusive update(s) in the
same time frame that security updates are being deployed. In this example
that exclusive update was IE7, but it could have been any one of the several
exclusive updates released over the past few years. Exclusive updates, in
general, should be dealt with out-of-cycle, so as to specifically avoid this
potential impact on regular security updates.

Doing so immediately brings us down to two days (worst case scenario), and
that can be easily managed by being aware of the existence of mandatory
updates in the catalog. Since the total number of these updates over the
past five years can still be counted on one hand -- even this two day
scenario has a less than 1/450 likelihood of actually happening.

The last such time was the release of KB938759 a year ago (6/24/2008), and
KB898461 for Windows XP the month previous (5/27/2008); and before that, the
release of the Windows Installer v3.1 in May, 2005.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Lawrence Garvin [MVP] wrote:

>>> And there is a reason the updates are scheduled at 0300. UNless you
>>> are running your desktops 24/7, updating at 0300 should produce no
>>> disruption. Then needing 3 nights to properly update the systems is
>>> no problem.
>
>> I disagree. The problem is that the machine is (very likely)
>> vulnerable to various attacks during the three days.
>
> It also should be noted that three days to deploy this collection of
> updates is a *highly unusual* scenario.

Oops, my mistake. I was vaguely thinking of patching newly installed machines,
which is the wrong context for this thread. If the updates in question are
relatively new, the incremental risk is minimal anyway.

Harry.

In message <> "Lawrence Garvin
[MVP]" <> was claimed to have wrote:

>"Harry Johnston [MVP]" <> wrote in message
>news:%...
>
>> Asher_N wrote:
>>
>>> And there is a reason the updates are scheduled at 0300. UNless you are
>>> running your desktops 24/7, updating at 0300 should produce no
>>> disruption. Then needing 3 nights to properly update the systems is no
>>> problem.
>
>> I disagree. The problem is that the machine is (very likely) vulnerable
>> to various attacks during the three days.
>
>It also should be noted that three days to deploy this collection of updates
>is a *highly unusual* scenario.
>
>Furthermore, just a nominal bit of awareness on the part of an administrator
>can be immediately realized by not approving the exclusive update(s) in the
>same time frame that security updates are being deployed. In this example
>that exclusive update was IE7, but it could have been any one of the several
>exclusive updates released over the past few years. Exclusive updates, in
>general, should be dealt with out-of-cycle, so as to specifically avoid this
>potential impact on regular security updates.
>
>Doing so immediately brings us down to two days (worst case scenario), and
>that can be easily managed by being aware of the existence of mandatory
>updates in the catalog. Since the total number of these updates over the
>past five years can still be counted on one hand -- even this two day
>scenario has a less than 1/450 likelihood of actually happening.
>
>The last such time was the release of KB938759 a year ago (6/24/2008), and
>KB898461 for Windows XP the month previous (5/27/2008); and before that, the
>release of the Windows Installer v3.1 in May, 2005.

This is one of those issues that, to me, seems like a glaring omission
in the WSUS design, but it comes up infrequently enough in practice to
be worth screaming about.

Personally, I just deadline the mandatory and/or exclusive updates to
make sure they get installed in enough time for machines to come back up
and still make their ~3am update check.

Another one I'd really like to see changed is that if a machine is
scheduled to check for updates more frequently then every 24 hours, if
no one is logged in and the machine has been up for at least 30 minutes,
install the updates immediately rather then waiting until 3am.