For completeness I notice that when using WU client 7.4.7600.226 (WAU 6)
the 15 minute / random delay I witnessed with previous versions. Clients
too.
report. How do we know the client reports immediately, well because approved
downloads appear at the client BEFORE the console displays the report status.
For this to have occurred the client MUST have reported. Oh and the
Things are now making sense.
Lawrence.
Post by Lawrence Garvin [MVP]Post by LeaUKPost by Lawrence Garvin [MVP]Post by LeaUKnet stop wuauserv
net start wuauserv
wuauclt /resetauthorization /detectnow
Restarting the service is unnecessary when deleting the SusClientID.
The correct procedures for this scenario are documented in KB903262.
Which mentions to stop/start the service? And also the keys above…
The article was originally written in the WSUS v2 timeframe, so now covers
both environments, thus the inclusion of the rule.
I'm intrigued with the service restart being documented, but it isn't
necessary. Normally when editing the registry a service restart *is*
required, because that's when the WUAgent reads the configuration
information from the registry, but this isn't a configuration value read at
service start, it's an operational status value cached in a cookie and
read/created as necessary. The /resetauthorization flag on the wuauclt.exe
command causes that targeting cookie to be expired, and the WUAgent then
either obtains the SusClientID from the registry, or causes it to be
recreated if it's non-existent.
Post by LeaUKPost by Lawrence Garvin [MVP]A client with a pending call to the ReportingEventWebService can be forced
to flush that reporting buffer by executing: wuauclt /reportnow.
Is this represented by a reg key?
No.
Post by LeaUKwuauclt /detectnow
wuauclt /reportnow
Correct.
Post by LeaUKAnd I should see an almost immediate TCP connection to the SUS server... Or
are there still delays?
You'll see an immediate TCP connection to the WSUS Server, but as Harry
pointed out, there's also another potential delay on the server side, as the
actual posting of the reporting data is handled asynchronously by the
database engine.
Post by LeaUKPost by Lawrence Garvin [MVP]Post by LeaUK3. Force client to download.
Once WSUS authorises a patch, how to force the client to connect and detect
this immediately?
This is also done with wuauclt /detectnow. If the WUAgent detects content
available for download it will immediately queue a request with BITS to
download that information.
Queue a request? But for how long?
The queue maintained by BITS is retained across restarts, if that's your
question. The queue is FIFO, and an item either fails to download, or is
downloaded successfully when hit by the queue. If the download fails, the
item will be re-queued by the WUAgent at the next detection event, assuming
the file is still needed by the agent.
Post by LeaUKI've read this can take upto an hour
however I'm hoping to speed this up to almost immediately.
Downloading from the server to the client takes as long as it takes,
dependent on the size of the file(s) to be downloaded, the available LAN
bandwidth, and other activities on the client and the server. However, my
observation is that client downloads happen fairly efficiently. Unless the
client and WSUS server are separated by a WAN link, I'd be surprised at any
download that took more than a few minutes.
Post by LeaUKI need to test the complete detection/reporting/deployment and install
scenario on a multitude of target machine images and all within the next few
days, hence waiting for deployment scheduled installs and random WSUS timings
is slowing this down to a crawl :(
Yes.. this is my point. It's a question between "working hard" and "working
smart". All of the things you seem to be wanting to prove empirically in
your lab, are already well known to the community, and generally documented,
albeit sometimes documented in the forums and newsgroups, rather than the
product documentation itself. Finding and referencing the experience and
knowledge of others can be immeasurably more efficient than actual testing.
1. After configuring the client, run wuauclt /detectnow.
2. Downloads will take as long as they take, but you can minimize this time
investment by selectively approving small updates.
3. While you can expedite the reporting event calls, unless you're staring
at the client waiting for downloads to complete, it will be hard to hit that
10-20 minute window. In a lab environment, starting step #1 at the end of
the day and letting download/reporting occur overnight can help the
efficiency of worktime invested.
4. To expedite the actual installation of updates, you can use expired
deadlines, and there's a wealth of real-world experiences with deadlines in
this newsgroup's archive (See Google), as well as the TechNet WSUS forum.
Generally speaking, though, with correct coordination of approval events,
detection frequencies, and scheduled installations, it's quite possible to
issue approvals at the end of the workday (3p-5p), have the client detect
and download needed content (use 6 hour detection frequency), and install it
(3am), and have all work completed when returning to work the next morning.
In a contrived lab setting, using 2 hour detection frequencies, and an
appropriately set scheduled installation event, the entire testing process
can be performed without artificial interference at the client in a matter
of a few hours (or even less). I've approved, detected, and installed
updates in as little as 30 minutes without even touching the client -- and
without using deadlines! :-)
--
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2010)
My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin