Group Policy option to allow "restart later"

Hello.

I operate Wsus across 6 of my servers in seperate locations, thus far i
havent had any huge issues.

Now however for some reason WSUS has begun restarting machines at the time
the scheduled install is supposed to be happening. Not a problem so far right?

Wrong, i have the "No auto restart for logged on users" option enabled and
also have the "allow non admins to receive au notifications" enabled also.

Yet my machines are still making users restart without the option of
clicking restart now.

One of my servers is doing exactly as it should, waiting for the user to
click restart now and always allowing restart later to be clicked.

I have checked the policies and made sure they are identical to the server
which is doing what it should be yet the other 5 just dont do exactly what
that server does...

im going crosseyed here so please help!

"Stephen Padgett" <Stephen > wrote in
message news:74960BCC-0EC3-40C6-873D-...

> i have the "No auto restart for logged on users" option enabled and
> also have the "allow non admins to receive au notifications" enabled also.
>
> Yet my machines are still making users restart without the option of
> clicking restart now.
>
> One of my servers is doing exactly as it should, waiting for the user to
> click restart now and always allowing restart later to be clicked.
>
> I have checked the policies and made sure they are identical to the server
> which is doing what it should be yet the other 5 just dont do exactly what
> that server does...

Let's start by reviewing the WindowsUpdate.log of one of these client
systems that did not behave as expected. Post the entries for the
installation event that did not offer the Restart Later option.

Also, for the sake of thoroughness, could you also export and post the
contents of the registry key (and subkeys)
HKLM\Software\Policies\Microsoft\Windows\WindowsUp date
from that same machine?

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

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

On Thu, 12 Nov 2009 06:01:03 -0800, Stephen Padgett <Stephen
> wrote:

>Hello.
>
>I operate Wsus across 6 of my servers in seperate locations, thus far i
>havent had any huge issues.
>
>Now however for some reason WSUS has begun restarting machines at the time
>the scheduled install is supposed to be happening. Not a problem so far right?
>
>Wrong, i have the "No auto restart for logged on users" option enabled and
>also have the "allow non admins to receive au notifications" enabled also.
>
>Yet my machines are still making users restart without the option of
>clicking restart now.
>
>One of my servers is doing exactly as it should, waiting for the user to
>click restart now and always allowing restart later to be clicked.
>
I am surprised that Lawrence did not point this out but normal practice would be
to configure servers with option 3 - download and notify for install. That way
no server will install updates and restart until the operator clicks on the
updates icon in the notification area and initiates an installation. After
installing updates the server should be rebooted (if necessary) ASAP. Installing
the updates and delaying the installation in decidedly not recommended.


>I have checked the policies and made sure they are identical to the server
>which is doing what it should be yet the other 5 just dont do exactly what
>that server does...
>
>im going crosseyed here so please help!
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.

"Dave Mills" <> wrote in message
news:...

> On Thu, 12 Nov 2009 06:01:03 -0800, Stephen Padgett <Stephen
> > wrote:

>>I operate Wsus across 6 of my servers in seperate locations, thus far i
>>havent had any huge issues.


> I am surprised that Lawrence did not point this out but normal practice
> would be
> to configure servers with option 3 - download and notify for install.


My take on the message was that Stephen has six WSUS servers, geographically
distributed, but that this particular issue applies to workstations, not
servers.

Otherwise, yes, I would have stood quite tall on the soapbox about not doing
servers with "scheduled installations"


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

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Hi Lawrence, Dave.

Thanks for your posts, at the moment im not at work but i will be on monday
so will post then.

I have 6 primary schools each of which with 1x windows 2003 server and have
localised the domain controller by blocking inheritence and assigning the
server its own scheduled update time (3am).

The machines are set to install at 12 noon.

The issue with allowing users to install is i only get a half day per week
to visit each school to give them support and i cant expect a 4 year old to
understand windows updates and that they nshould click restart now instead of
later, same with the tachers, they have enough on their plate.

I will post back on monday with the requested information.

Thanks again

"Lawrence Garvin [MVP]" wrote:

> "Dave Mills" <> wrote in message
> news:...
>
> > On Thu, 12 Nov 2009 06:01:03 -0800, Stephen Padgett <Stephen
> > > wrote:
>
> >>I operate Wsus across 6 of my servers in seperate locations, thus far i
> >>havent had any huge issues.
>
>
> > I am surprised that Lawrence did not point this out but normal practice
> > would be
> > to configure servers with option 3 - download and notify for install.
>
>
> My take on the message was that Stephen has six WSUS servers, geographically
> distributed, but that this particular issue applies to workstations, not
> servers.
>
> Otherwise, yes, I would have stood quite tall on the soapbox about not doing
> servers with "scheduled installations"
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>
> .
>

"Stephen Padgett" <> wrote in
message news:6A76EBFD-1863-4C0F-A6B2-...

> and have
> localised the domain controller by blocking inheritence

Huh???

> and assigning the server its own scheduled update time (3am).

I suppose in this scenario, scheduled installations on a server are
acceptable; but you need to be cognizant of what happens at 8am the next
morning if something goes wrong with the 3am scheduled installation.
Personally, I'd be inclined to set aside one evening per month, or one
weekend afternoon, and apply all patches to each server using a Remote
Desktop connection.

> The machines are set to install at 12 noon.
>
> The issue with allowing users to install is i only get a half day per week
> to visit each school to give them support and i cant expect a 4 year old
> to
> understand windows updates and that they nshould click restart now instead
> of
> later, same with the tachers, they have enough on their plate.

And this is exactly why the entire environment is designed to run
UNATTENDED?

Why would you reconfigure a system that's designed to work in an unattended
mode,
and configure it to make it more complicated than it needs to be, e.g.:
- schedule daytime installs in a school setting
- enable administrative controls at the desktop (Allow non-admins...)
- enable the no auto-restart policy

I understand that the machines are likely powered off overnight, so
overnight installs are not feasible.

Allow me to suggest this alternative:

1. Find out from the schools which computers/rooms are idle/vacant at which
time of the day. LUNCHTIME is a great time for this.
2. Create OUs or Security Groups based on those times, and apply GPOs based
on this classification.
3. Schedule the installation to occur when the computer is expected to be
idle on a particular day of the week (e.g. Friday)
4. Inform the schools/teachers that installations/restarts may occur during
this time frame on Fridays, particularly around the middle of the month.
5. Ideally you'll even control your approvals so that you control the time
frame of the installations to one week per month.

Yet another alternative --- Don't forget that the default behavior is to
install at power-on if the scheduled installation is missed. In an
environment where computers are known to be powered off overnight, this is a
great tool to use to cause installations to intentionally occur at power-on.
Schedule the installation for overnight or weekend hours -- knowing that it
won't occur. When the machine is powered on the next day, installation will
occur immediately. Do not allow this reboot to be controlled -- let it
happen immediately. Combine this with education to the teachers that they
may want to turn on the computer a few minutes early on Monday morning to
allow updates to be installed.


> I will post back on monday with the requested information.

Truly, at this point, I think it's less significant to try to troubleshoot
why the client did or did not present a "Restart Later" button, and simply
eliminate that configuration option entirely, but I'll be happy to look at
them, regardless.

My suggestion:

Make these installations 100% unattended and schedule them to occur at a
time the machine is expected to be idle.

Disable the "No auto-restart with logged on users" (These computers *are*
going to be logged on when you initiate the installations. You simply need
to schedule the installations when the machines are scheduled to be unused.)

Disable the "Allow non-admins to receive update notifications". (The only
users who should ever be elevated with this option are users who are fully
cognizant and capable of engaging in the update process, and need the
ability to initiate the installation.)

Disable the two install update and shutdown policies, so that "Install
Updates and Shutdown" *IS* an option that's presented, and encourage the
teachers to make use of this feature prior to the scheduled weekly install
time so as to completely avoid the inconvenience of that midday installation
and restart.



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

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

All of Lawrence's suggestion are good especially "install updates and Shutdown"
which I take advantage of in my school.

One other that could help if the bios supports it would be a scheduled switch on
time. Most allow this either one date a month or every day but a few allow you
to set the day of the week. If you have this then set 7am Monday as the startup
and have the scheduled install set for sometime over the weekend so if it is
missed the installation will happen early Monday.

This would also allow software installed via GPO to be set to get installed at
the same time by releasing the GPO over the weekend.


On Sat, 14 Nov 2009 01:57:01 -0800, Stephen Padgett
<> wrote:

>Hi Lawrence, Dave.
>
>Thanks for your posts, at the moment im not at work but i will be on monday
>so will post then.
>
>I have 6 primary schools each of which with 1x windows 2003 server and have
>localised the domain controller by blocking inheritence and assigning the
>server its own scheduled update time (3am).
>
>The machines are set to install at 12 noon.
>
>The issue with allowing users to install is i only get a half day per week
>to visit each school to give them support and i cant expect a 4 year old to
>understand windows updates and that they nshould click restart now instead of
>later, same with the tachers, they have enough on their plate.
>
>I will post back on monday with the requested information.
>
>Thanks again
>
>"Lawrence Garvin [MVP]" wrote:
>
>> "Dave Mills" <> wrote in message
>> news:...
>>
>> > On Thu, 12 Nov 2009 06:01:03 -0800, Stephen Padgett <Stephen
>> > > wrote:
>>
>> >>I operate Wsus across 6 of my servers in seperate locations, thus far i
>> >>havent had any huge issues.
>>
>>
>> > I am surprised that Lawrence did not point this out but normal practice
>> > would be
>> > to configure servers with option 3 - download and notify for install.
>>
>>
>> My take on the message was that Stephen has six WSUS servers, geographically
>> distributed, but that this particular issue applies to workstations, not
>> servers.
>>
>> Otherwise, yes, I would have stood quite tall on the soapbox about not doing
>> servers with "scheduled installations"
>>
>>
>> --
>> Lawrence Garvin, M.S., MCITP:EA, MCDBA
>> Principal/CTO, Onsite Technology Solutions, Houston, Texas
>> Microsoft MVP - Software Distribution (2005-2009)
>>
>> My Blog: http://onsitechsolutions.spaces.live.com
>> Microsoft WSUS Website: http://www.microsoft.com/wsus
>> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>>
>> .
>>
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.

Lawrence Garvin [MVP] wrote:
> "Stephen Padgett" <> wrote in
> message news:6A76EBFD-1863-4C0F-A6B2-...
>
>> and have
>> localised the domain controller by blocking inheritence
>
> Huh???
>
>> and assigning the server its own scheduled update time (3am).
>
> I suppose in this scenario, scheduled installations on a server are
> acceptable; but you need to be cognizant of what happens at 8am the next
> morning if something goes wrong with the 3am scheduled installation.
> Personally, I'd be inclined to set aside one evening per month, or one
> weekend afternoon, and apply all patches to each server using a Remote
> Desktop connection.
>
>> The machines are set to install at 12 noon.
>>
>> The issue with allowing users to install is i only get a half day per
>> week
>> to visit each school to give them support and i cant expect a 4 year
>> old to
>> understand windows updates and that they nshould click restart now
>> instead of
>> later, same with the tachers, they have enough on their plate.
>
> And this is exactly why the entire environment is designed to run
> UNATTENDED?
>
> Why would you reconfigure a system that's designed to work in an
> unattended mode,
> and configure it to make it more complicated than it needs to be, e.g.:
> - schedule daytime installs in a school setting
> - enable administrative controls at the desktop (Allow non-admins...)
> - enable the no auto-restart policy
>
> I understand that the machines are likely powered off overnight, so
> overnight installs are not feasible.
>
> Allow me to suggest this alternative:
>
> 1. Find out from the schools which computers/rooms are idle/vacant at
> which time of the day. LUNCHTIME is a great time for this.
> 2. Create OUs or Security Groups based on those times, and apply GPOs
> based on this classification.
> 3. Schedule the installation to occur when the computer is expected to
> be idle on a particular day of the week (e.g. Friday)
> 4. Inform the schools/teachers that installations/restarts may occur
> during this time frame on Fridays, particularly around the middle of the
> month.
> 5. Ideally you'll even control your approvals so that you control the
> time frame of the installations to one week per month.
>
> Yet another alternative --- Don't forget that the default behavior is to
> install at power-on if the scheduled installation is missed. In an
> environment where computers are known to be powered off overnight, this
> is a great tool to use to cause installations to intentionally occur at
> power-on. Schedule the installation for overnight or weekend hours --
> knowing that it won't occur. When the machine is powered on the next
> day, installation will occur immediately. Do not allow this reboot to be
> controlled -- let it happen immediately. Combine this with education to
> the teachers that they may want to turn on the computer a few minutes
> early on Monday morning to allow updates to be installed.
>
>
>> I will post back on monday with the requested information.
>
> Truly, at this point, I think it's less significant to try to
> troubleshoot why the client did or did not present a "Restart Later"
> button, and simply eliminate that configuration option entirely, but
> I'll be happy to look at them, regardless.
>
> My suggestion:
>
> Make these installations 100% unattended and schedule them to occur at a
> time the machine is expected to be idle.
>
> Disable the "No auto-restart with logged on users" (These computers
> *are* going to be logged on when you initiate the installations. You
> simply need to schedule the installations when the machines are
> scheduled to be unused.)
>
> Disable the "Allow non-admins to receive update notifications". (The
> only users who should ever be elevated with this option are users who
> are fully cognizant and capable of engaging in the update process, and
> need the ability to initiate the installation.)
>
> Disable the two install update and shutdown policies, so that "Install
> Updates and Shutdown" *IS* an option that's presented, and encourage the
> teachers to make use of this feature prior to the scheduled weekly
> install time so as to completely avoid the inconvenience of that midday
> installation and restart.
>
>
>

I gotta agree with Lawrence. I run a network at a Hospice in upstate NY.
All servers are set for "Download & Notify". All workstations are set
for "Download & Install". All computers are set to the default period
between checking for updates (23 hours +/-). All workstations are set to
reboot 5 minutes after update is completed. No exceptions.

Once I approve the updates on the primary WSUS server, I send out an
e-mail to every user that their workstations will be installing updates.
They are warned that when the reboot warning starts the clock, they
cannot stop it. If they don't save their work, it ill be lost when the
computer reboots.

After a couple of folks trying to "beat the clock" and losing their
data, folks learned very quickly to heed the warning.

In the OP's environment, I would also educate the teachers & staff on
how the process will work. Also, post written notices at each computer
(or site) notifying folks when the updates and reboots will occur and
what they should do.

--

Regards,
Hank Arnold
Microsoft MVP
Windows Server - Directory Services
http://mypcassistant.blogspot.com/

Good Morning Lawrence, Hank, Dave.

Thanks all for your input, its opened my options a little bit.

I think i am going to try and get the schools to allow machines to be left
on overnight and schedule the install the same as the servers, for around
3am, i understand that if something breaks then itll be a problem the next
morning however all the schools understand "sh!t happens" and i have a
certain amount of flexibility to resolve issues if it is critical.

For now im going to postpone all updates and speak with the heads of each
school to see if i can one night per week.

However that doesnt solve the issue with teaching staff who take laptops
home, i have configured the local policy to get updates from the server as
staff are just as lazy as children sometimes and wouldnt bother installing
any updates, however if i think about it, the idea of making them shutdown
and install updates could resolve this. To do this would i simply set to
download and notify and then when the end of the day comes they would click
shutdown and install the updates?

Again thanks all for your input, i think i shall become an avid reader here!

"Lawrence Garvin [MVP]" wrote:

> "Stephen Padgett" <> wrote in
> message news:6A76EBFD-1863-4C0F-A6B2-...
>
> > and have
> > localised the domain controller by blocking inheritence
>
> Huh???
>
> > and assigning the server its own scheduled update time (3am).
>
> I suppose in this scenario, scheduled installations on a server are
> acceptable; but you need to be cognizant of what happens at 8am the next
> morning if something goes wrong with the 3am scheduled installation.
> Personally, I'd be inclined to set aside one evening per month, or one
> weekend afternoon, and apply all patches to each server using a Remote
> Desktop connection.
>
> > The machines are set to install at 12 noon.
> >
> > The issue with allowing users to install is i only get a half day per week
> > to visit each school to give them support and i cant expect a 4 year old
> > to
> > understand windows updates and that they nshould click restart now instead
> > of
> > later, same with the tachers, they have enough on their plate.
>
> And this is exactly why the entire environment is designed to run
> UNATTENDED?
>
> Why would you reconfigure a system that's designed to work in an unattended
> mode,
> and configure it to make it more complicated than it needs to be, e.g.:
> - schedule daytime installs in a school setting
> - enable administrative controls at the desktop (Allow non-admins...)
> - enable the no auto-restart policy
>
> I understand that the machines are likely powered off overnight, so
> overnight installs are not feasible.
>
> Allow me to suggest this alternative:
>
> 1. Find out from the schools which computers/rooms are idle/vacant at which
> time of the day. LUNCHTIME is a great time for this.
> 2. Create OUs or Security Groups based on those times, and apply GPOs based
> on this classification.
> 3. Schedule the installation to occur when the computer is expected to be
> idle on a particular day of the week (e.g. Friday)
> 4. Inform the schools/teachers that installations/restarts may occur during
> this time frame on Fridays, particularly around the middle of the month.
> 5. Ideally you'll even control your approvals so that you control the time
> frame of the installations to one week per month.
>
> Yet another alternative --- Don't forget that the default behavior is to
> install at power-on if the scheduled installation is missed. In an
> environment where computers are known to be powered off overnight, this is a
> great tool to use to cause installations to intentionally occur at power-on.
> Schedule the installation for overnight or weekend hours -- knowing that it
> won't occur. When the machine is powered on the next day, installation will
> occur immediately. Do not allow this reboot to be controlled -- let it
> happen immediately. Combine this with education to the teachers that they
> may want to turn on the computer a few minutes early on Monday morning to
> allow updates to be installed.
>
>
> > I will post back on monday with the requested information.
>
> Truly, at this point, I think it's less significant to try to troubleshoot
> why the client did or did not present a "Restart Later" button, and simply
> eliminate that configuration option entirely, but I'll be happy to look at
> them, regardless.
>
> My suggestion:
>
> Make these installations 100% unattended and schedule them to occur at a
> time the machine is expected to be idle.
>
> Disable the "No auto-restart with logged on users" (These computers *are*
> going to be logged on when you initiate the installations. You simply need
> to schedule the installations when the machines are scheduled to be unused.)
>
> Disable the "Allow non-admins to receive update notifications". (The only
> users who should ever be elevated with this option are users who are fully
> cognizant and capable of engaging in the update process, and need the
> ability to initiate the installation.)
>
> Disable the two install update and shutdown policies, so that "Install
> Updates and Shutdown" *IS* an option that's presented, and encourage the
> teachers to make use of this feature prior to the scheduled weekly install
> time so as to completely avoid the inconvenience of that midday installation
> and restart.
>
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>
> .
>

Laptops are always a problem. I'm not aware of any way to set it up so
that if the WSUS server isn't available, then check in with the MU site
(unless Lawrence can come up with one).

The hole in your idea is that it depends on the staff taking the time to
install the updates. My experience is that you can't count on them to do it.

I would set them for the same as the other computers. "Download &
Install" with a countdown (you can set this to other then 5 minutes).
Again, this is a matter of education....................


--

Regards,
Hank Arnold
Microsoft MVP
Windows Server - Directory Services
http://mypcassistant.blogspot.com/

Stephen Padgett wrote:
> Good Morning Lawrence, Hank, Dave.
>
> Thanks all for your input, its opened my options a little bit.
>
> I think i am going to try and get the schools to allow machines to be left
> on overnight and schedule the install the same as the servers, for around
> 3am, i understand that if something breaks then itll be a problem the next
> morning however all the schools understand "sh!t happens" and i have a
> certain amount of flexibility to resolve issues if it is critical.
>
> For now im going to postpone all updates and speak with the heads of each
> school to see if i can one night per week.
>
> However that doesnt solve the issue with teaching staff who take laptops
> home, i have configured the local policy to get updates from the server as
> staff are just as lazy as children sometimes and wouldnt bother installing
> any updates, however if i think about it, the idea of making them shutdown
> and install updates could resolve this. To do this would i simply set to
> download and notify and then when the end of the day comes they would click
> shutdown and install the updates?
>
> Again thanks all for your input, i think i shall become an avid reader here!
>
> "Lawrence Garvin [MVP]" wrote:
>
>> "Stephen Padgett" <> wrote in
>> message news:6A76EBFD-1863-4C0F-A6B2-...
>>
>>> and have
>>> localised the domain controller by blocking inheritence
>> Huh???
>>
>>> and assigning the server its own scheduled update time (3am).
>> I suppose in this scenario, scheduled installations on a server are
>> acceptable; but you need to be cognizant of what happens at 8am the next
>> morning if something goes wrong with the 3am scheduled installation.
>> Personally, I'd be inclined to set aside one evening per month, or one
>> weekend afternoon, and apply all patches to each server using a Remote
>> Desktop connection.
>>
>>> The machines are set to install at 12 noon.
>>>
>>> The issue with allowing users to install is i only get a half day per week
>>> to visit each school to give them support and i cant expect a 4 year old
>>> to
>>> understand windows updates and that they nshould click restart now instead
>>> of
>>> later, same with the tachers, they have enough on their plate.
>> And this is exactly why the entire environment is designed to run
>> UNATTENDED?
>>
>> Why would you reconfigure a system that's designed to work in an unattended
>> mode,
>> and configure it to make it more complicated than it needs to be, e.g.:
>> - schedule daytime installs in a school setting
>> - enable administrative controls at the desktop (Allow non-admins...)
>> - enable the no auto-restart policy
>>
>> I understand that the machines are likely powered off overnight, so
>> overnight installs are not feasible.
>>
>> Allow me to suggest this alternative:
>>
>> 1. Find out from the schools which computers/rooms are idle/vacant at which
>> time of the day. LUNCHTIME is a great time for this.
>> 2. Create OUs or Security Groups based on those times, and apply GPOs based
>> on this classification.
>> 3. Schedule the installation to occur when the computer is expected to be
>> idle on a particular day of the week (e.g. Friday)
>> 4. Inform the schools/teachers that installations/restarts may occur during
>> this time frame on Fridays, particularly around the middle of the month.
>> 5. Ideally you'll even control your approvals so that you control the time
>> frame of the installations to one week per month.
>>
>> Yet another alternative --- Don't forget that the default behavior is to
>> install at power-on if the scheduled installation is missed. In an
>> environment where computers are known to be powered off overnight, this is a
>> great tool to use to cause installations to intentionally occur at power-on.
>> Schedule the installation for overnight or weekend hours -- knowing that it
>> won't occur. When the machine is powered on the next day, installation will
>> occur immediately. Do not allow this reboot to be controlled -- let it
>> happen immediately. Combine this with education to the teachers that they
>> may want to turn on the computer a few minutes early on Monday morning to
>> allow updates to be installed.
>>
>>
>>> I will post back on monday with the requested information.
>> Truly, at this point, I think it's less significant to try to troubleshoot
>> why the client did or did not present a "Restart Later" button, and simply
>> eliminate that configuration option entirely, but I'll be happy to look at
>> them, regardless.
>>
>> My suggestion:
>>
>> Make these installations 100% unattended and schedule them to occur at a
>> time the machine is expected to be idle.
>>
>> Disable the "No auto-restart with logged on users" (These computers *are*
>> going to be logged on when you initiate the installations. You simply need
>> to schedule the installations when the machines are scheduled to be unused.)
>>
>> Disable the "Allow non-admins to receive update notifications". (The only
>> users who should ever be elevated with this option are users who are fully
>> cognizant and capable of engaging in the update process, and need the
>> ability to initiate the installation.)
>>
>> Disable the two install update and shutdown policies, so that "Install
>> Updates and Shutdown" *IS* an option that's presented, and encourage the
>> teachers to make use of this feature prior to the scheduled weekly install
>> time so as to completely avoid the inconvenience of that midday installation
>> and restart.
>>
>>
>>
>> --
>> Lawrence Garvin, M.S., MCITP:EA, MCDBA
>> Principal/CTO, Onsite Technology Solutions, Houston, Texas
>> Microsoft MVP - Software Distribution (2005-2009)
>>
>> My Blog: http://onsitechsolutions.spaces.live.com
>> Microsoft WSUS Website: http://www.microsoft.com/wsus
>> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>>
>> .
>>