Can you modify the roll-up schedule for child servers into the parent?

Question

We have one parent server (which server some clients directly) and two child servers.  There appears to be a large delay (maybe 2 hours) between when a server reports into a child server and when that update reaches the parent server.  We would
like to be able to query the master server on patch night and get an up to date accounting of patch status without having to wait for the roll-up.  Is there any way to change the roll up interval or to force a roll-up on demand (say right before generating
a report of approved patches)?
Tom

Answer 1

Here is the scenario:  The clients are set for a 3 hour detection frequency, and on patch day the patches are approved at least 3 hours before the earliest patch time.  The first patch window starts at 8:00PM on patch night and the servers are
set to patch and reboot, so they start installing at 8:00 and after they finish and reboot they always report in to their reporting server within a few minutes after startup.
This scenario is almost certainly doomed on principle from the start. Consider the following sequence of events that must occur between the time you approve the updates on the USS and the client system wants to install the update (at 8:00pm).
The USS WSUS Server downloads the files for the approved updates from Microsoft. (This could run from minutes to an hour or more depending on the number of updates and available bandwidth, and I'm considering a liberal Internet connection for this activity.)
The DSS WSUS Server(s) synchronize with the USS. The first sync event following the completion of any given update download will trigger the download of that file to the DSS as well. (How often your DSS syncs will drive this delay.)
The DSS completes the download from the USS. (Like #1, this could run from minutes to hours, depending on the number of updates and available bandwidth.)
The client system executes a detection with the assigned DSS and discovers that an approved update has a file available for download. (How often your client executes a detection will drive this delay, and even with a 3-hour detection, the client only has
max TWO possible opportunities to find these updates between 10am and 8pm.)
The client system completes the download from the DSS. (And these downloads must be completed BEFORE 8pm in order for the WUA to actually schedule the updates to be installed.)
As such, the practicalities of getting from approval (even assuming mid-morning for that event) to fully downloaded by 8pm (so a total time span of ~10 hours end-to-end) is flirting with failure.
For best results to make your 8:00pm installation time, you really need to approve the updates at least 24 hours in advance, and to ensure they get to the replica servers, probably closer to 48 hours in advance, all depending on what the actual
DSS synchronization interval is, and the available connection bandwidth between the DSS and USS, and the USS and Microsoft.
We would like to be able to see if all servers have patched as soon as possible after 8:00PM so we can start troubleshooting them and get them patched.
The first hurdle here is when those systems are restarted after the updates are installed (assuming that the updates have actually gotten to the client system in time to be installed at all). The client system reports back to the assigned replica WSUS server
following the restart. That state information is then uploaded to your upstream WSUS server during the next DSS server synchronization event. In addition, the reporting events from both the client-to-DSS and DSS-to-USS are processed asynchronously inside the
database.
The only way you could get that data "as soon as possible" is to set the client detection frequency to 2 hours, the DSS synchronization to 12 times per day, and even then, there's a potential delay of up to four hours between client restart and the
availability of that status data at the upstream WSUS server. In order to get anything more "real time" than this, you'd have to implement a managed deployment tool such as
SolarWinds Patch Manager.
Furthermore, there are significant disadvantages to having 2-hour detections and 12x daily synchronizations, in terms of the amount of noise generated in the form of "events" reported at each of those activities a dozen or more times a day.
Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
SolarWinds Head Geek
Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.