How do I force updates to install and force a reboot

I have a domain of around 1500 computers using WSUS on a 2003 server. All
comptuers are controlled via GP. I have a handfull, 20 or so, users that are
not restarting their comptuers AND I have a handfull, 60 or so, local
administrators that are ignoring their notice to install updates and restart
their computers.

I want to force the updates to install and force the computers to restart. I
do not care if they loose work or even get notice. i just want to force the
install and an immediate reboot.

I do not want to change the group policy unless i have to becouse 95% of my
users are complying.

Is there a command line tool that i can run or any other option that is out
there to do this?

 

I will be watching for a reply to this because I too would like to know if
this is possible.

 

You can always separate those 20 or so machine in a sub-OU and apply
force/mandatory reboot with deadline.

 

You don't need an OU. You can put them in a group and have a different
policy for that group.

 

Slap 'em!

Fire them!.... or at least take away their local administrator access...
/obviously/ they are not qualified to have that level of access.

Not a problem... I have a fix for you and your problem children.

First -- Seriously.... remove local administrator privileges from anybody
who doesn't play nice - if you can.

Second -- DISABLE the policy "No auto-reboot for scheduled installations".
Disabling this policy will force all non-admins to restart their system
according to the delay interval configured in "Delay restart for scheduled
installations". By default this value is five minutes, but you can configure
it to be from 1 to 30 minutes. Personally, I like three minutes. It's enough
time to save work and close applications, but not enough time to continue
doing anything except finishing the immediate task.

Truth is.. if the majority of your users are complying, and you're using
scheduled installations -and- the scheduled installations are occuring
outside of working hours, then the "No auto-reboot..." policy can actually
do more harm than good. If a user forgets to log off at the end of the day,
"No auto-reboot" will prevent an overnight installation from restarting.

btw... are these systems configured to use /scheduled/ installations, or are
you relying entirely upon the local admin to do the installations
interactively? If the latter, I would strongly suggest you configure WSUS
with Option #4 so that all updates at the desktops are /scheduled/ for
installation.

However, considering the next item, changing this policy is optional, as the
next item will override this policy in any circumstance anyways.

Third -- you can configure a deadline for the update on a per target-group
basis. Put your problem children into a special target group. Configure the
deadline for 24-48 hours out from your actual approval time. Here's what
will happen:
(a) Normal scheduled installations with restarts will not be any
different than any other system's experience.
(b) Users will not be able to defer the restart, because the deadline
forces a restart upon installation.
(c) If the scheduled installation was missed (a powered down machine),
the update would, by default, be installed at the next powerup, with the
same conditions as (b).
(d) If the deadline occurs before the next scheduled installation, the
update will be installed at the deadline time.

Finally, for those users who are going to continue to be local
Administrators, you can Enable the group policy found in
User Configuration \ Administrative Templates \ Windows Components \
Windows Update
to restrict all access to Windows Update. This policy will have the added
effect of blocking /all/ access to the WUA User Interface for those defiant
local admins. The policy can be filtered by specific user, so that only
those problem children will be affected by the policy. At which point you're
confident that you've secured their cooperation, you can 'unfilter' them
from the policy.

Nope... it's going to require a combination of the two policy settings and
deadlines to fully achieve your desired effect.

But note that the "No auto-reboot.." policy can be filtered by computer and
the "No Windows Update" policy can be filtered by user. You might want to
actually create a whole new GPO and link it to the existing OUs. You can
filter the GPO by security group; create a security group for the computer
accounts, and a security group for the user accounts, then grant Read/Apply
permissions only to those two security groups. As the users/computers come
into compliance and learn to cooperate you can remove them from the security
group(s). If new problem children appear, all it takes is adding them to the
security group.

The deadline 'fix' is only necessary to restrict local admins from being
able to access the UI and mess with scheduled installations.

One last note: You can also schedule a deadline for way far in the future,
which will have the effect of denying access to the local admins to unselect
or defer installation, but it won't have the effect of forcing the
installation. But only do this in combination with Option #4, /scheduled/
installations. If you're still relying on local interaction to do the
installations, this will have the likely effect of not changing anything at
all; in fact, the admin won't even be able to initiate the instalation in
this case.

Hopefully that's given you some ideas and options on how you can 'enforce'
the installation of updates, without imposing on those users who are already
cooperative and compliant.

 

All good sugestions Lawrence, and thanks...

This really does not get to the root of my problem though. I have 1500+
machines with 1500+ users and some machines stay on for 24/7.
I can force reboot after install, but that is not the problem. When i
examine the logs the updates do not show rebooted neded (for the most part)
it jsut shows needed. This tells me the user is not isntalling the updates,
which means they must be local adimins (#4 is on) there needs to be an
option 6 that does not allow local admin interface, afterall this is a domain
and i am god, what i say goes, and my local admins should not be able to
override that, fix it Microsoft darnit!!! I cant blanketly control who my OU
Admins have given local admin rights too, not yet anyway.

ok...... The idea of turning on the "remove access to use all WU Features"
sounds good but my problem with that is my OU admins need to be able to
access WU for server updates, as at this time, we dont include servers in
WSUS...... I guess an option to resolve this might be to create the a GP with
the "remove access to use all..." apply it to all users, then filter out OU
Admins only. does that sound tlike a good option? Alos would enabling this
feature enforce the #4 option regardless of admin rights??? in other words
does it take the little yellow notification sheild go away, force the
installation of the updates, and prompt the user to restart?

:

 

24x7 machines are a common challenge.... it just boils down to marking out
at least an hour a month for /maintenance/ and coordinating that with the
operations people. It's one of those "has to be done" things, and everybody
in an organization just has to make accomodations. I'm sure most ops people
will understand the general idea that a machine cannot run 24x7
indefinitely, it requires some form of periodic maintenance. For desktop
computers, that 'periodic' maintenance needs to occur monthly.

That is a reasonable conclusion and I agree with your assessment.

Well.... there is an "option 6", you just have to configure it using other
policy settings. Second, while a Domain Administrator may be "god" on the
domain (read: network), it's always been a fundamental design principle of
windows that a local Administrator is "god" on the system (read: machine).
The /only/ way you can truly control what happens on a machine is to control
the issue of local administrators.

In any event, you have that capability with WSUS (if not for other
products), and that capability is implemented by disabling access to all
Windows Update functionality using the policy I mentioned in the previous
message.

Use /Security Filtering/ on the policy. Create a special GPO that does
nothing but disable this setting. Then apply the GPO using security
filtering to /only/ the users who are problem children. Create a special
security group... heck, I'd even call it "Problem Administrators", and put
those admins in that group, and then use that group to apply the policy to
/only/ those users.

You'll probably want to create a group to /apply/ the policy to, rather than
filter out only the OU admins. Remember, you said the majority of your users
are not contributing, so you probably do not want to remove functionality
from the 95% of cooperating users, only those 80 users that aren't playing
by the rules.

Enabling this feature (disabling the policy) would, de facto, enforce the
Option #4 /scheduled/ installation because those users would not have any
permissions to interact with the WUA User Interface, thus they could not
initiate installations, they could not defer installations, nor could they
decline installations. Furthermore, they won't even be able to interfere
with the restart, since that will also be imposed upon them as a consequence
of being denied access to WU.

It will completely hide notifications. Those admins won't even know updates
are pending (from the interface).

Of course, they /could/ read the WindowsUpdate.log or
SoftwareDistribution.log and determine the status of the system wrt updates,
but they won't be able to affect anything that will happen. If that's a
potential issue, you could restrict 'read' access to those files by adding
the new security group and explictly denying Read permissions on those files
to that security group.

 

Lawrence,
how do I "Configure the deadline for 24-48 hours out from your actual
approval time". Also you had posted a command line that would create a txt
report that showed the WU group policy settings and I cannot find it. Could
you do it again? Thanks so much!!!

Juli

 

| Lawrence,
| how do I "Configure the deadline for 24-48 hours out from your
actual
| approval time".


When you assign a deadline to the update, the right column of the
approval dialog box allows you to specify a date and time for the
deadline. So, if you're approving the updates on Wednesday morning
at 8am, set the deadline for Friday at 8am.

| Also you had posted a command line that would create a txt
| report that showed the WU group policy settings and I cannot find
it. Could
| you do it again? Thanks so much!!!

To extract the WSUS group policy settings from the local registry
use

REG EXPORT HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate
wsus.reg

(I think that's what you're asking for.)

Additional info can be obtained from "reg /?" or "reg export /?",
which will display:


REG EXPORT KeyName FileName

Keyname ROOTKEY\SubKey (local machine only)
ROOTKEY [ HKLM | HKCU | HKCR | HKU | HKCC ]
SubKey The full name of a registry key under the selected
ROOTKEY
FileName The name of the disk file to export

Examples:

REG EXPORT HKLM\Software\MyCo\MyApp AppBkUp.reg
Exports all subkeys and values of the key MyApp to the file
AppBkUp.reg

 

my 2c,

I have a very similar set-up. I set GP to download + notify users of updates
and not auto reboot reboot. This way all users get a notification that
updates are available but it doesn't affect their ability to work.

I have an outage notification published for the last Sunday of every month,
so all users know that if they haven't already installed the updates it will
happen at that time and they will have no choice but to accept the reboot.

to force the reboot, I use the deadline option, and I set it for about 3
weeks in advance. If users can't have their pc auto rebooted - they need to
install the updates before the deadline, if they dont care they can ignore
them and come in on monday morning with the latest updates.

It works really well here.