Printable View
At first I was assuming that running wuauclt.exe /detectnow corresponds to the Last Status Report column in the WSUSAdmin > Computers report.
But, I guess not - so it's merely telling WUA to check against WSUS but not "check in". So then, how do you force a "check in" so that an entry appears in WSUS?
Running wuauclt /detectnow will update the "Last Contacted" column.
Approx 10-20 minutes after the detection, the WUA will initiate a /reporting/ event, which will then update the "Last Status Report" column.
Is there more to it than that? At noon I ran my script to run wuauclt.exe /detectnow (through psexec) across all active domain computers.
But they definately didn't report back 10-20 minutes later, but in a much larger window of time - I'm guessing there's some algorithm that says to back off reporting if another WUA client is reporting to it?
I see batches of machines in twos and threes reporting on the same minute (which I wonder, is this when the report started or finished).
Not a big deal - I'm just trying to understand how this works clearer.
Technically.. no.
There's a way to trigger the /detection/ event, manually.
The reporting event happens /automatically/ as a function of a successful completion of the detection event.
Yeah.. well.. see... now.. you tried to do something in the span of a few minutes (across how many machines????), that's designed to happen across the span of 22 hours!!!
Why do you find it necessary to force a detection on ALL of your machines at one time, instead of using the system as designed -- which is to spread out those detections across the 22 hour timeframe???
I'd venture a guess that you've simply overloaded your WSUS server, and those clients are experiencing timeouts. Have you inspected the WindowsUpdate.log file(s) for signs of errors?
Since the reporting event duration is measured in the size of packets across milliseconds, I'd imagine it's both.. start and finish.
Fair enough.... I'd suggest starting by not trying to 'redesign' the default behavior. First understand the /default/ behavior of the system, then 'modify' the behavior so that you have a perspective on what the baseline behavior is to begin with.
Well if that's the case, then a better approach to patching Windows machines, is not to solely rely on WSUS, but in addition, make your own custom ad-hoc patching system that you want/need to deploy ASAP across many machines?
Actually, the /best/ approach to patching Windows machines is to design a /system/, an /environment/ and a /methodology/ appropriate for the number of sites, desktops, notebooks, and servers contained within a specific environment. You start by understanding the core design fundamentals of the product(s) chosen to be evaluated for your environment. /THEN/ you investigate ways to 'modify' or 'enhance' a given product to tweak it into doing everything you want to do.
btw, if you want to install updates on all of your systems at the same time, then you should be looking at a product like SMS, which uses push technology and is designed to do mass deployments simultaneously. WSUS is designed to /minimize/ the load on the network and the server, while ensuring a timely updating of patch content across the enterprise during a 24-48 hour period.
Right... I guess I should be more careful with how I word things. Better
worded would be:
WSUS is not the silver bullet to MS patch management, you may need to
create your own custom scripts to do ad-hoc patches OR use something
like SMS (or one of it's several main competitors).
After updates installation just run below command this will update the status immediately, less than a minute
wuauclt /r /reportnow
Note: the correct syntax is
wuauclt /reportnow
=or=
wuauclt /r
but not both parameters together.
And rarely less than a minute to update!
Actually I've never seen it make any difference that I could tell. As far as I can tell it's a no-op.
Certainly it doesn't speed up the processing of the report by the WSUS server, which is where a lot of the delay comes from.
If the command is issued after a successful detect, and before the regularly following call to ReportingEventWebService, then you can trace back to a log entry showing the execution of the command.
Run detection with wuauclt /detectnow
2009-11-26 23:42:55:004 1084 ee0 AU Triggering AU detection through DetectNow API
2009-11-26 23:42:55:005 1084 ee0 AU Triggering Online detection (non-interactive)
2009-11-26 23:43:21:963 1084 11bc Agent * Found 0 updates and 62 categories in search; evaluated appl. rules of 685 out of 987 deployed entities
2009-11-26 23:43:27:002 1084 11bc Report REPORT EVENT:
{8B97C2AF-5BB4-439E-A2CC-A171185A79A5} 2009-11-26 23:43:21:966-0600 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates.
2009-11-26 23:43:27:002 1084 11bc Report REPORT EVENT: {10576623-567B-4A36-A49E-3A42CAEB4FCC} 2009-11-26 23:43:21:968-0600 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.
Event terminates normal detection at 23:43:27 and is pending a reporting event.
Run wuauclt /reportnow, and cause an immediate call to the ReportingWebService to flush the pending reporting events.
2009-11-26 23:44:14:678 1084 11bc Report Uploading 2 events using cached cookie, reporting URL = http://sbs2003r2:8530/ReportingWebSe...ebService.asmx
2009-11-26 23:44:14:689 1084 11bc Report Reporter successfully uploaded 2 events.