How do I force updates to install and force a reboot

Discussion in 'Update Services' started by RollNpc, Oct 18, 2005.

  1. RollNpc

    RollNpc Guest

    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?
     
    RollNpc, Oct 18, 2005
    #1
    1. Advertisements

  2. RollNpc

    Juli Guest

    I will be watching for a reply to this because I too would like to know if
    this is possible.
     
    Juli, Oct 18, 2005
    #2
    1. Advertisements

  3. RollNpc

    M. Eteum Guest

    You can always separate those 20 or so machine in a sub-OU and apply
    force/mandatory reboot with deadline.
     
    M. Eteum, Oct 18, 2005
    #3
  4. RollNpc

    Asher_N Guest

    You don't need an OU. You can put them in a group and have a different
    policy for that group.
     
    Asher_N, Oct 18, 2005
    #4
  5. 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.
     
    Lawrence Garvin [MVP], Oct 19, 2005
    #5
  6. RollNpc

    RollNpc Guest

    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?

    :
     
    RollNpc, Oct 19, 2005
    #6
  7. 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 Garvin [MVP], Oct 19, 2005
    #7
  8. RollNpc

    Juli Guest

    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
     
    Juli, Oct 26, 2005
    #8
  9. | 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
     
    Lawrence Garvin [MVP], Oct 27, 2005
    #9
  10. RollNpc

    Simone Guest

    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.
     
    Simone, Feb 2, 2010
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.