Despite policy, EVERYONE getting restart notifications

Discussion in 'Update Services' started by Jeff Vandervoort, Nov 11, 2005.

  1. After the November patch Tuesday, I had 2 WS2003 SP1 computers with patches
    downloaded via WSUS and waiting for a restart after hours.

    One of those computers is a Terminal Server. Standard (non-admin) users log
    on to it. All were getting the "Automatic Updates" message box telling them
    to restart the computer. All are prohibited by GPO from doing so
    (fortunately!), so the "Restart Now" and "Restart Later" buttons were
    dimmed. Even the close box was dimmed. They could close it by pressing Esc,
    but 10 minutes later, it came back.

    I tried logging on locally to both WS2003 SP1 servers with installed updates
    pending a reboot using a non-admin account. Same problem (IOW, whatever it
    is, it has nothing to do with Terminal Services).

    This has NEVER happened before with WSUS or SUS. On servers, I routinely
    manually allow the download from WSUS and postpone the restart until after
    hours via Scheduled Task. No AU Group Policy changes have occurred since the
    previous Patch Tuesday.

    Ran a GPMC "Results" query against the Terminal Server. Here are the Windows
    Update settings from the report:

    Allow Automatic Updates immediate installation: Disabled.
    Allow non-administrators to receive update notifications: Disabled *
    Configure automatic updating: 3 - Auto download and notify for install
    Re-prompt for restart with scheduled installations: Disabled *
    Specify intranet Microsoft update service location: Enabled.

    * According to documentation, "Not configured" is the same as "Disabled" for
    these settings, and "Not Configured" is how they have been set until today.
    But today I explicitly "Disabled" them, followed by replicating the DCs and
    GPUPDATE /FORCE on the Terminal Server trying (without success) to solve the
    problem.

    This problem was NOT reported on any Win XP SP2 or Win 2000 SP2 SRP1
    computers, whose AU config is: 4 - Auto download and install.

    As a workaround, I stopped the AU service on the Terminal Server to stop the
    popups until the reboot, but need to know how to avoid having this happen
    again going forward.

    So...what's wrong?
     
    Jeff Vandervoort, Nov 11, 2005
    #1
    1. Advertisements

  2. Lawrence Garvin [MVP], Nov 11, 2005
    #2
    1. Advertisements

  3. Thanks for your reply.

    1. Nothing under my control that I'm aware of changed from prior Patch
    Tuesdays. In the past, non-admins didn't receive notifications. This week,
    they did. Why? And how can I prevent it from happening next time?

    2. You'll see from my AU settings. "Allow non-admins to receive update
    notifications" was "Not Configured", and is now "Disabled". Either way,
    non-admins should NOT be receiving notifications. But they are. Why? And how
    can I prevent it from happening next time?

    The rest of the article is on-topic only in the sense that if the server is
    patched after hours, non-admin users will not be logged on to see the
    notifications, but...

    1. It is not practical to install patches after hours. I'm not available 24
    hours per day to my clients. I either have to install the patch and restart
    the server later automatically, or just let it do the install and restart
    automatically at 3AM. I haven't felt comfortable letting a server patch
    itself without my knowing that it's happened; still don't, though that's,
    admittedly, a comfort-level thing more than a real requirement. And, of
    course, that's why Microsoft has provided that setting in Automatic Updates,
    and allows restarts to be deferred in manually-installed patches. But this
    does not compromise the machine. It means only that the patch won't be
    installed for a few more hours, because...

    2. If files are in use when the update runs, or the update is flagged as
    requiring a restart, Windows caches the update and does not install any part
    of it until the restart. It would be extremely dangerous for it to do
    otherwise, because depending on what's being patched, Windows might not
    remain running long enough for the patch to be installed, much less any
    other patches queued up for install. Talk about DLL hell!

    3. And the advice, if accurate, is not TS-specific. If a machine is
    "partially patched", it's unstable. Period. One simply should not have the
    option of postponing a restart if what the article says is true. Ever. On
    any machine. Even to install more patches before the reboot. If the article
    is correct, patches should be installed one at a time and the machine
    restarted between each one. But it's not correct. The machine is either
    unpatched or patched. Not in between.

    In the bad old days, Windows hotfixes typically posted a message box after
    they were installed that had but a single button: "Restart". There was a
    reason for that. But Microsoft enhanced the update technology many years ago
    to reduce TCO. And gave us QCHAIN to make it retroactive to most older
    patches. This article hints at the history, and also describes the update
    mechanism to some degree.

    http://support.microsoft.com/default.aspx?scid=kb;en-us;296861

    Presumably, Microsoft would not have changed this behavior--to allow
    multiple hotfixes to be installed, and defer restarts--if it risked
    disaster. So if Microsoft is safe in giving us the option, in both manual
    and automatic updating, to postpone the restart, then we are safe in using
    it.

    If it's not safe, Microsoft needs to (a) document that and (b) remove the
    option. And it should certainly rewrite the first section of this "Best
    Practices" article:

    http://www.microsoft.com/technet/pr...eTC/b4ff7f56-45b5-4f2b-82e7-283903d23c26.mspx

    --
    Jeff Vandervoort
    JRVsystems

     
    Jeff Vandervoort, Nov 11, 2005
    #3
  4. Jeff... /somebody/ or /something/ installed the updates while the TS had users
    logged on.

    Otherwise, the users would not have received dialog boxes to restart.
    Because /that/ settings has absolutely nothing to do with the user getting a
    dialog box to /reboot/ following the installation of updates. That setting
    allows a non-admin user to:
    (a) see the notification icon in the notification area
    (b) interact with the WUA User Interface in order to /install/ updates
    (c) and choose which updates, if any, are actually installed.

    As noted again -- the updates were already installed by /someone/ or
    /something/ on your Terminal Server, and that ought to be the focus of your
    attention! WHY were updates installed on a live Terminal Server????
    E X A C T L Y !!! -- which is a /critical/ issue for Terminal Servers, though
    the qualifier of "non-admin" is irrelevant. /NO/ users should be logged onto
    TS sessions while the underlying OS is being modified.

    but...
    It needs to become practice for Terminal Servers. Plain and simple. Doing
    otherwise is inviting a world of trouble.
    One of the reasons I generally /discourage/ the use of Terminal Servers in
    organizations that do not have full-time staff capable of managing,
    maintaining, and monitoring such systems. :)
    Both of which are /very/ risky propositions in the management of a Terminal
    Server. But, in the case of Terminal Servers, the /latter/ is much less risky
    than the former.
    While Microsoft "allows" restarts to be deferred.. you will find that they do
    not 'recommend' such actions, in fact, in general defering of restarts is
    /discouraged/ on regular systems, even more so on Terminal Servers.
    Yeah.. and if /HALF/ of the files in an update are cached.. and the other half
    are not.. you have just /created/ your own DLL Hell. :)

    The decision whether a file is cached is made on a file-by-file basis.. not an
    update-by-update basis.
    Absolutely!!! The advice, is not TS-specific, but it /IS/ much more critical
    for TS because multiple users are involved in various states of operation, and
    crashing a TS, in some companies, can be a career-changing event.
    I absolutely agree. The general consensus is that /nobody/ should defer
    restarts. Unfortunately, there are companies, organizations, and system
    administrators who insist on being stupid about this point, so the ability
    must be provided (most unfortunately). If only we could mandate intelligency
    by designing out "stupidity complaince" in software products. :)
    In fact.. if you read the reams of documentation that has been written on
    patch and update management over the years, you would discover that, in fact,
    the practice of installing update ONE-at-a-time, is the documented BEST
    PRACTICE. However, most sysadmins are loathe to invest the time doing so.

    Ironically, had that practice been employed, most of the issues being seen
    right now concerning the issues with the October and November updates, would
    have been severely minimized, and isolated much sooner then they actually
    were. The practice of "installing everything at once" actually creates /more/
    work when diagnostics must be employed to find out which one of a half dozen
    or more updates "screwed the pooch".
    The article /is/ correct. You are entitled to your own perspective and
    opinions, though. :)
    The fact that this was provided... in response to the demands of the masses --
    the masses, in general, being clueless as to the ramifications of such
    demands -- does not suggest that such practices are at all recommended, or in
    the best interests of such people making those requests.

    Nevertheless, as noted, one cannot legislate intelligence, or best practices.
    I would hardly characterize this "Operations Guide", which was actually
    authored during the beta testing process - as a "Best Practices" article. Nor,
    do I suspect, would the WSUS team characterize that document as representing
    "best practices".

    If you want to read "Best Practices" articles... then read the rest of the
    articles on /my/ website. :)
     
    Lawrence Garvin [MVP], Nov 11, 2005
    #4
    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.