Group Policy anomalies with Delay Restart, Re-Prompt for Restart and Non-Administrators receive noti

Discussion in 'Update Services' started by Paul Schwartz, Aug 15, 2005.

  1. All computers in my org have updates assigned via a GPO, one per WSUS
    server/related geographic OU. These clients all receive updates and behave
    as you would expect - prompting incessantly for a restart when a user is
    logged on through the update (at 3am), or automatically restarting the
    machine if they are not logged in..

    My servers have the same basic policy except that their are set to 'download
    and notify for install' (Thankfully I have only 20 servers to deal with). I
    update these on a weekly basis after the updates have tested safely on
    client machines (imperfect, but hey) and do so a day or so before a
    scheduled reboot. Before WSUS there was no issue with this method (read:
    before the new AU client, I suspect).
    NOW when I apply these updates all Administrator users sees the notice to
    reboot and can click LATER. Non-Admin users on my 4 Application Terminal
    Servers can NOT click LATER and see this message in the foreground, greyed
    out, even though the "Allow Non-Administrators to receive update
    notifications" is DISABLED.

    A few servers are tweaked to permit "Power Users" to Terminal Serve in, and
    they also get the message BUT they get the 5 minute countdown timer.

    My current workaround is to do updates, then net stop wuauserv on the box
    until the scheduled restart time comes up.

    Does anyone have anything that might shed some light on this? I'm clear
    that the machines need to restart (duh) and should do so soon, but this
    method worked fine for 3 years with SUS.
     
    Paul Schwartz, Aug 15, 2005
    #1
    1. Advertisements

  2. Paul, I'm not aware that any of the basic functionality concerning the
    scheduling and installation of updates has changed from SUS to WSUS. The
    "Configure Automatic Updates" policy was introduced with SUS, and in SUS it
    also supported Options 2,3,4,5 with the same functionality.

    The "No Auto-restart with scheduled installations" option is what determines
    whether your systems reboot with a user logged in or not. If you have
    /disabled/ the "Reschedule Automatic Updates scheduled installations" option
    so that updates can /only/ be installed at your scheduled time, then you can
    safely /disable/ the "No Auto-restart..." option, which will allow all of
    your clients to restart after installation, regardless of whether the user
    remembered to log off at the end of the day, or not.

    However, if you've left the "Reschedule Automatic Updates" at it's default,
    or even Enabled it, then you'll need protections for users sitting at their
    machines following the powerup.. and it's the "No Auto-restart" option that
    protects users from having the system initiate a restart without
    notification.

    All Administrators see the Reboot Now/Restart Later options because "No
    Auto-restart" is enabled, and because they are local administrators. The
    only way around that is to make them not be administrators. On Terminal
    Servers, however, users will never have the option to "Restart Later",
    because that option is reserved for /administrator/ level logons.. and one
    presumes one cannot run a TS session in admin mode. The countdown timer is
    an effect of the combination of "No Auto-restart" and a non-admin users. In
    essence it forces the restart, but gives the user warning that it will
    occur. The user has no choice in the matter.

    Your current workaround is necessary because of the local Admin status of
    your users... which also means they can 'undo' your workaround, if they
    figure out how.

    The best suggest is to first define the /desired/ behavior of your systems,
    and then configure to produce that behavior. Note, however, that WSUS was,
    primarily, designed to be a covert update technology operating outside of
    working hours, so making things happen /during/ working hours without
    impacting users has a minimal set of functional options.
     
    Lawrence Garvin, Aug 15, 2005
    #2
    1. Advertisements

  3. Lawrence,

    Thanks for the the information. Between posting this message and reading
    your reply I determined that the countdown timer being reported on a server
    was not the case, but that it was true on a workstation of the same
    reporting user (I was experimenting with the "deadline" feature).

    Now I'm left with NON-Admin users on a Terminal Server seeing the pop-up
    message to restart even though the "Allow Non-Administrators to receive
    update notifications" is DISABLED. I'm 100% ok with administrators seeing
    it... since these specific servers reboot once every 24 hours anyway to
    ensure a clean working environment for the application they host - but it
    sure would be nice if it would not show non-admin users that message.

    Paul
     
    Paul Schwartz, Aug 16, 2005
    #3
  4. Paul... your non-admin TS users should /not/ be seeing the pop-up message to
    restart with "Allow non-admins" disabled... however, those settings would be
    based on the policy applied to the /Terminal Server/, not the individual
    users' desktop computers.

    When a user is functioning inside a TS session, the policies they obtain are
    the same policies applied to the /computer/ that is the Terminal Server.

    Now, as for the Terminal Server, you absolutely do not want the TS
    installing updates while you have active TS sessions, as that can create a
    world of instability, and the last place you want an unstable server is on a
    TS. I strongly recomment that Terminal Servers be configured with Option #3,
    and that updates only be installed interactively, from the console, and with
    the Application Mode services shutdown so that no client TS sessions can be
    initiated during the update process until the restart is complete.
     
    Lawrence Garvin, Aug 16, 2005
    #4
  5. Hi,

    Another person solved this issue by removing all access to the files
    wuauclt.exe and wuauclt1.exe for all non-admin users.
     
    Torgeir Bakken \(MVP\), Aug 16, 2005
    #5
  6. That's a creative fix!!! :)

     
    Lawrence Garvin, Aug 16, 2005
    #6

  7. Command line that can be used to remove access for ordinary users
    (note: needs to be on one single line, will wrap over two lines in
    this post):

    %SystemRoot%\System32\cacls.exe
    %SystemRoot%\System32\wuauclt*.exe /e /r "builtin\users"


    If you want to do the same for power users as well, do the same for
    "builtin\power users" as well.
     
    Torgeir Bakken \(MVP\), Aug 16, 2005
    #7
  8. An alternative methodology would be to use group-policy-based software
    restrictions.
     
    Lawrence Garvin, Aug 17, 2005
    #8
  9. Hi,

    It looks like Software Restriction Policies are computer policy only,
    but Microsoft gives you a couple of options that may work in this case:
    There is a "Skip Administrators" option in this policy, or you can deny
    the Apply Group Policy permission on the GPO to the Administrators
    group (that is what Microsoft recommends, see snippet from the docs
    below). Anyway, only testing will show if this work properly for
    wuauclt.exe/wuauclt1.exe (unless you are running Windows 2000, where
    Software Restriction Policies are not supported).


    From the docs at
    http://www.microsoft.com/technet/security/prodtech/windowsxp/secwinxp/xpsgch06.mspx

    <quote>
    Skip Administrators

    An administrator may want to disallow programs from running for most
    users, but allow administrators to run all of them. For example, an
    administrator may have a shared computer that multiple users connect
    to using Terminal Server. The administrator may want users to run
    only specific applications on the computer, but members in the local
    Administrators group to be able to run anything. Use the
    SkipAdministrators enforcement option to do this.

    If the software restriction policy is created in a GPO linked to an
    object in Active Directory, instead of using the SkipAdministrators
    option, Microsoft recommends denying the Apply Group Policy
    permission on the GPO to the Administrators group. This consumes
    less network traffic because GPO settings that do not apply to
    administrators are not downloaded.
    <quote>
     
    Torgeir Bakken \(MVP\), Aug 17, 2005
    #9
    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.