general question about after approval

Discussion in 'Update Services' started by John Spencer, Jul 14, 2005.

  1. John Spencer

    John Spencer Guest

    Here is the scenario; Mostly 2k Servers, some NT4 Boxes and a few2K3 servers.
    We don't have AD, so all of the local settings have been put in by hand. I
    know the NT4 boxes are SOL. All of the 2K and 2K3 boxes that can access the
    WSUS server have checked in. I deployed some patches and was able to then log
    on locally and was presented with an install dialog box, so that went well. I
    have set the clients to download and install at 11:00pm nightly. The
    detection frequency is set to 8 hours. I have a script that will reboot all
    the systems during our companies 'outage window'at midnight. So here is my
    question, if there are a mix of mandatory and other updates, will all of the
    'approved' updates be installed, or just the mandatories? Would I have to
    wait till the next install time (11:00PM the next day) rolls around for the
    rest of the updates to install? Is there any command line procedures to force
    checkin, download and install now and NOT reboot? A second question not
    exactly related, but how can I force a client to update the WSUS server
    database quicker, the /detectnow does not seem to update the DB very quickly.
    I know an update has been installed and the server rebooted, but WSUS
    defiantly says it needs a reboot, untill like 20 minutes later.
    John Spencer, Jul 14, 2005
    1. Advertisements

  2. John Spencer

    JeffG Guest

    The answer to that really depends on the nature of the updates
    themselves. So far in my experience, they group install pretty well,
    regardless of update type. The majority of updates can go all at
    once. Ones that can't be installed until other pre-requisite patches
    are installed are the main cause of multiple patch cycles. There's
    not much of a way around those, but generally it only takes a few
    Generally speaking, yes you would. but...
    There is no way to NOT reboot and still get the next required updates,
    as the system will not report it's installation until after the
    reboot, if one is required. That's mainly because the patch hasn't
    really been installed until after the required restart and the system
    files are actually replaced :)

    If you have *not* restricted access to the MS website via policy, you
    can "install now" outside of the policy by logging on as local
    administrator and click the "install updates" notification.

    If you "allow non-administrators to receive notifications" any end
    user can click install after detection/download. I would not suggest
    that personally, as it gives end users complete control over the
    update and install process regardless of your policy settings.

    NOTE: If you have the online website access blocked by policy, this
    doesn't work for ANYONE, as all notifications except the "reboot now"
    get surpressed if that policy is enforced...
    Yeah, there is some lag time there, isn't there. That one I can't
    answer. I can only say that even in testing with minimum detection
    cycles, it still takes a while...

    BTW, if you're actually just looking for a way to get new machines
    patched and rolled out in a hurry, I use a completely different OU,
    policy, and approval methods for my "New Machines" category, which is
    set to download and notify as well as minimum detection cycles, etc -
    you can get a baseline machine patched up pretty quick like that...

    JeffG, Jul 15, 2005
    1. Advertisements

  3. John Spencer

    John Spencer Guest

    Thanks for the response. We don't have AD, so no OU's. I am not looking to
    get new systems patched. Our company allows us a small window every three
    months to update about 1000 servers, I am trying to not have to log on. When
    you say 'a few cycles' are you saying a few days? Also when I was asking
    about command line, it was not to get around not rebooting after a patch that
    needs to reboot. I can script the reboot, since multiple patches may need
    multiple 'cycles' I was hoping that I could write a script that would make
    the server checkin and install any patches it needs.

    Thanks again for the info.

    John Spencer, Jul 15, 2005
  4. Hi,

    You will need to use the Windows Update Agent API that is documented

    Several VBScript examples available at the MSDN web site:

    Using the Windows Update Agent API

    A couple of other examples:
    Torgeir Bakken \(MVP\), Jul 15, 2005
  5. John Spencer

    JeffG Guest

    I'm beginning to see...

    "A few cycles" timeline would vary depending on the AU settings you've
    provided your servers, checkin, install, etc. If they are fairly up
    to date already, there usually is no problem getting your updates to
    install all in one batch. I think the minimum you can set up for WSUS
    is one hour detection cycles, but you can only set ONE time of day for
    auto-installations - at least with a policy...

    You might be able to script a registry change for them that manually
    changes the next update install time (based on the current time + a
    few minutes or some such), then run a /detectnow in the same script.
    I would probably stop the AU service, make all of your changes, then
    restart the AU service so it starts operating within your new

    Truthfully, this is out of my realm of experience. I do know that
    when I change a WSUS policy and refresh it at the client, it changes
    the registry settings immediately and starts operating by the new
    settings, so I don't see why the same wouldn't hold true for a
    scripted registry change after the system reboots. There are probably
    more than a few keys to change, though, so it would take some

    Always more words than help :)
    JeffG, Jul 15, 2005
  6. John Spencer

    John Spencer Guest

    Thanks very much, I think this is going to be the best route for us.
    John Spencer, Jul 15, 2005
  7. John Spencer

    John Spencer Guest

    I like the script, if I can come up with a way to have it install without
    intervention. Can this script talk to WSUS, it says it can't talk to SUS 1.0.

    John Spencer, Jul 15, 2005
  8. Hi,

    You should be able to create a script that talks to a WSUS server.


    The Windows® Update Agent (WUA) API is a set of COM interfaces
    that enable system administrators and programmers to access
    Windows Update and Windows Server Update Services (WSUS). Scripts
    and programs can be written to examine which updates are currently
    available for a computer, and then you can install or uninstall
    Torgeir Bakken \(MVP\), Jul 15, 2005
  9. Any time the WUA detects mandatory updates to be installed, it will only
    download the mandatory updates. It will detect the regular updates, but it
    will not download them until the mandatory updates have been installed /and/
    the system has been restarted. So, the quick and simple answer to your
    question is that only the mandatory updates will be installed at your
    scheduled installation time of 11:00pm.

    Yes. Under normal circumstances.

    Also note that you've thrown another variable into the mix with your
    scheduled, scripted restart at midnight.

    When the installation starts at 11pm and installs any mandatory updates that
    might have been already downloaded, it will then do a restart after
    completion of that installation. That's likely to only take a few minutes,
    so normally by 11:15pm or so you'd see that system come back up to speed,
    execute another detection cycle (after restart from installation of
    mandatory updates the WUA does another detection cycle to get the rest of
    the detected, but not yet downloaded, updates), and then start downloading
    the updates.

    Depending on the volume of updates to be downloaded, the number of clients
    executing installation/restart/detection/download cycles all at 11pm, the
    performance characteristics of your WSUS server, and the bandwidth available
    on your network, it's not unlikely that some clients will still be
    downloading updates when you force another restart on them at midnight. The
    WUA should recover normally from this scenario, but be aware that it is an
    event that does carry some potential for disrupting the normal operation of
    the WUA.

    Furthemore, if any of those updates had deadlines configured, they could
    actually be in the middle of an installation even when you force the restart
    upon them. /THAT/ would carry significant potential for disrupting the
    normal operation of the entire system. Hundreds of observations of the BSOD
    have been recorded from systems restarting during an XP Service Pack 2
    installation that the user was unaware was executing, notebooks kicking into
    suspend/hibernate mode, or where the workstation was impacted by
    environmental conditions -- such as a power loss.

    I would suggest moving the scheduled installation window to /after/ your
    daily scheduled maintenance restart to ensure mitigation of these risks.

    No. There is a command to force a checkin/download, but installation only
    occurs through one of four scenarios:
    (1) The update is scheduled for installation at the scheduled
    installation time.
    (2) Updates have been downloaded, but the scheduled installation time
    was missed because the system was powered down. If the option "Reschedule
    Automatic Updates scheduled installations" is not disabled, the updates will
    then be installed when the system powers back up, regardless of the time of
    (3) The local administrator (or non-admin user if "Allow non-admins...."
    has been enabled) interactively initiates the installation.
    (4) The update has a deadline configured, and the deadline has expired.

    There is /no/ option to install and not restart, though there is an option
    available for local administrators to defer the restart. This is not a
    recommended practice, however, and should only be used in special
    circumstances where specific reasons are presented for delaying a restart.

    By default, the client contacts the WSUS server every 22 hours (minus a
    random offset of 1-20%). This parameter can be set by policy, and it can be
    set as low as 1 hour; however, under normal operations, and considering that
    updates only come out monthly, there is no real purpose in setting this
    value away from the default, except during initial installation when trying
    to get status updates for a collection of systems in less time than 48

    If you don't have complete status updates from every client in 48 hours,
    there's another issue at work, and changing the default detection cycle is
    not likely to provide any positive results.

    I've also read, but not confirmed, that there are random delays for the
    executing of the reporting cycles, that are not configurable by the
    administrator or users, and this may also impact the timeliness of
    information being updated to the WSUS server.

    Yes.... well..... first, the "Restart Required" status is sent to the WSUS
    server immediately upon completion of the installation of the update. Then,
    there is a delay before the restart is initiated. This delay is configurable
    by policy, but by default it is 5 minutes. Then, if a local administrator is
    logged onto the system, they may also have the option to defer the restart.
    Then it takes some time to shutdown and restart the system. Then, the WUA
    has a checklists of processing steps it must perform upon power up.
    Following all of that, and recording the restart activities in the logs,
    then the WUA is able to execute another detection cycle, which also includes
    a full status report to the WSUS server. Then, I've read again, but also not
    confirmed, that the uploaded 'report' sits in a processing queue on the WSUS
    server, and may require yet another time lapse before the data is actually
    posted to the database. Finally, you have the time variable of when you
    refresh the asmx page that displays the client status in relation to when
    the database was actually updated.

    Quite frankly, if it only takes 20 minutes for you to get a client to move
    from "Restart Required" to "Installed", I'd say you ought to be happy that
    your environment is working as smoothly as it is. Instantaneous status
    reporting is not a design parameter of the system.
    Lawrence Garvin, Jul 17, 2005
  10. I would say your company needs a serious reality check and a good long
    conversation with a qualified security specialist.

    Updating servers "every three months" is /EXACTLY/ the scnerio and attitude
    that allowed the SQL Slammer worm to be the worldwide disaster that it was.

    Having said that, I've published an article in this newsgroup (I believe),
    but definitely in the beta newsgroup (and I simply need to post it on my
    website, along with a couple of other articles), that outlines the policy
    configurations and procedures necessary to effect a full update of a server
    within a specified time frame, without having to resort to interactive
    installation of updates.

    I'll get those articles posted later today or tommorrow and post a new
    thread here with the links.
    Lawrence Garvin, Jul 17, 2005
  11. John Spencer

    Asher_N Guest

    Lawrence, I agree. Any server that is critical should be clustered.
    Otherwise, any server should be available to be down at least once a

    John, out of curiousity, what industry ae you in that requires that kind
    of uptime on 1000 servers, and why no AD?
    Asher_N, Jul 18, 2005
  12. John Spencer

    John Spencer Guest

    Thanks for the responses Lawrence,
    About the '3 month', that is what our company calls a 'rollup' It is to
    catchup on all patches, service packs, etc. We have monthly outages for
    mandatory patches also, and would patch immediately if a any needed patch was
    found to have exploits in the wild.
    My approach with this was to be able to approve, install and then when WSUS
    indicated a reboot was needed to reboot them, Midnight is when the servers
    can be rebooted, not when they will be rebooted. I set the detection cycle to
    8 hours, so if an emergency release of a patch is issued, I can get the ball
    rolling within just a few hours. With this last round of patches I approved
    them around 3pm on Wednesday and many servers picked up the updates fairly
    rapidly and were showing those pretty green 'installed' indications the next
    morning. Although the hope is to use WSUS for upwards to 1000 servers in the
    future, I have it on a select set of servers, 32 in number trying it out. My
    only real problem I have right now is clients not gelling with the WSUS
    server. I have 18 of them saying they need patches, but looking in add-remove
    the patches are there. They are also showing as installed by MBSA (1.2.1). It
    looks to me like the clients are not checking in with the WSUS server
    properly, as the 'last updated' dates are several days ago. I run /detectnow
    on the servers and they do not seem to check in. Any thoughts on this?

    Thanks again for the help.
    John Spencer, Jul 18, 2005
  13. Thank you for the clarification.
    Not a recommended practice for servers. Consider why the system needs
    restarted in the first place. This is because some files in the filesystem
    could not be overwritten with the new files because they're currently open
    and in use by the system. A restart is required so that the new files can be
    copied into the filesystem at startup, before the system initiates the
    services that use those system files.

    What this means from a practical standpoint is that when an update is
    installed, some files are updated, and some are not. This has the potential
    to create an unstable condition on a server (on a workstation as well, but
    its less critical on the desktop system). As a result, the recommended
    practice is to install the updates at a time conducive to allowing the
    restart immediately after the installation completes.

    Also, you assume a certain amount of risk by allowing the updates to install
    automatically (unattended), which also carries with it the nominal risk of
    Ahh.. my misunderstanding.
    And the question to ask.. (which can be determined by the logs)... is how
    long were the servers partially installed and waiting to be restarted so
    that the installation process could complete? :)
    If you've confirmed that the patches are installed, but they are not showing
    as "Installed" on the WSUS Admin console, this would point to a dysfunction
    in the reporting service between the WUA and the WSUS. To diagnose this,
    trace through the WindowsUpdate.log on a selected server, identify where the
    update was installed, then restarted, and shortly thereafter there should be
    a call to ReportingServices.asmx, which is where the WSUS server should have
    received the status update to "Installed".
    Let's look at the logs and see what we see.
    Lawrence Garvin, Jul 18, 2005
  14. Lawrence Garvin, Jul 20, 2005
    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.