| Home | Register | Members | Search | Windows Vista Tips | File Database | Links |
 |
| Thread Tools | Display Modes |
|
Guest
Posts: n/a
|
|
|
|
||
|
|
| |
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
"Lawrence Garvin [MVP]" wrote: > "LeaUK" <> wrote in message > news:FB2AA8EA-E799-4F30-84FA-... > > > 1. Force console to detect client: > > The CONSOLE does not detect anything. The CLIENT initiates all > communications and it is the CLIENT which registers with the WSUS server. > Completely agree, my poor wording I'm afraid, thanks for clarifying. I should of said; force client to register with console… > > reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Win dowsUpdate /v > > AccountDomainSid /f > > reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Win dowsUpdate /v > > PingID /f > > These values were deprecated with the introduction of WSUS v3 and the > WUAgent v7.0. (i.e. they only exist in WSUS v2 environment with legacy v5.8 > WUAgents installed) Thanks, I wondered why they were never there to delete, but left it for completeness. > > > @echo Triggering detection after resetting WSUS client identity > > net 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… > > > > 2. Force Client to report > > > > This can be triggered by wuauclt /detectnow but it's linked to a timer > > (probable reg key) and once run will not for another predetermined time > > (don't know what this is). > > The WUAgent always executes a call to the ReportingEventWebService, approx > 10-20 minutes after the completion of a detection, download, or installation > event. > > > > How can one reset this timeout such to force connection and report > > immediately. > > 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? So: wuauclt /detectnow wuauclt /reportnow And I should see an almost immediate TCP connection to the SUS server... Or are there still delays? I'll test ;-) > > > 3. 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? I've read this can take upto an hour however I'm hoping to speed this up to almost immediately. > > > > Any thoughts more than welcome as usual ;-) > > Lea... it's really not necessary to "test" these scenarios to find out what > is happening. The behavior of the environment has not functionally changed > in the five years since WSUS v2 was originally released, and the behaviors > are well known, some of them documented by Microsoft, many of them discussed > and "documented" in this newsgroup, the WSUS forum on Technet, TechEd, and > several webcasts produced by many sources. > Hi Lawrence Again, maybe my poor explanation. I'm not wishing to prove WSUS itself, but that our corporate process is well understood and documented and proved to operate as expected. I 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  Thanks for all your assistance, it's much appreciated. Lea > > -- > 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/pro...awrence.Garvin > Lea |
|
|
|
|
|||
|
Guest
Posts: n/a
|
"LeaUK" <> wrote in message
news:5435CA4E-1373-4182-B4E6-... >> > net 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. >> 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. > So: > > wuauclt /detectnow > wuauclt /reportnow Correct. > And 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. >> > 3. 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. > I'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. > I 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. To expedite a testing scenario: 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/pro...awrence.Garvin |
|
|
|
|
|||
|
Guest
Posts: n/a
|
Unfortunately this grasshopper has real deadlines and a Director 'keen' for
implementation and full documented testing... Thankfully there are very wise ones here and for those I am extremely grateful. Lea "State of MN" wrote: > In article <5435CA4E-1373-4182-B4E6->, > says... > > > >I 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 > > > >Thanks for all your assistance, it's much appreciated. > > > >Lea > > patience grasshopper. > > Old WSUS proverb: > WSUS events are measured in days and weeks not hours and minutes. Enjoy > the time well spent on other endeavors. > > -- > antwesor > . > |
|
|
|
|
|||
|
Guest
Posts: n/a
|
Hi Lawrence - just to say upfront, thank you for all your assistance.
"Lawrence Garvin [MVP]" wrote: > "LeaUK" <> wrote in message > news:5435CA4E-1373-4182-B4E6-... > > >> > net 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. Ah ha! > > >> 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. > > > > So: > > > > wuauclt /detectnow > > wuauclt /reportnow > > Correct. > > > > And 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. Afraid not. There is no immediate TCP connection. There's a delay of 15 minutes if the machine has recently run /detectnow. And Harry is most certainly right too, there's an async delay between the TCP connection and the Console reporting the update. Seems to be in the order of 5 minutes. > > >> > 3. 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? When /detectnow is forced, approx 15 mintues later the download will begin via BITS > > 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. > > > > I'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. > I fully appreciate file size/BW etc affect download times, my questions was how long does one have to wait before BITS is scheduled. As above, seems like 15 minutes. > > > I 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. Totally agree, but I need to PROVE our updates are being distributed and downloaded as dictated by the clients' GPO - for ISO auditors. > > To expedite a testing scenario: > 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! :-) Many thanks for your thoughts and suggestions. Like you say, working 'smart' is key. I have 15 target machines to prove deployment on - think I'll do this little lot simultaneously rather than try and 'force' things to happen. > > > -- > 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/pro...awrence.Garvin > Lea |
|
|
|
|
|||
|
Guest
Posts: n/a
|
For completeness I notice that when using WU client 7.4.7600.226 (WAU 6) /detect triggers immediate TCP connection to WSUS and doesn't seem to wait the 15 minute / random delay I witnessed with previous versions. Clients will also report download any approved update within a 15 minute time period too. In fact, when: /detectnow /reportnow Machines will show in the console within 30 seconds  and reportimmediately, although the async console update takes <15minutes to show the 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 windowsupdate.log gives this away too ;-) Things are now making sense. Oh and SSL on a custom port for internals and externals using ISA and split DNS is all finally working well now - thanks to Dave, Wolfgang and especially Lawrence. All that's left is to set Master/slave and roll the reports "Lawrence Garvin [MVP]" wrote: > "LeaUK" <> wrote in message > news:5435CA4E-1373-4182-B4E6-... > > >> > net 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. > > >> 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. > > > > So: > > > > wuauclt /detectnow > > wuauclt /reportnow > > Correct. > > > > And 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. > > > >> > 3. 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. > > > > I'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. > > > > I 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. > > To expedite a testing scenario: > 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/pro...awrence.Garvin > |
|
|
|
|
|||
|
|
| |
|
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Can't change group membership of computers | Mike in Nebraska | Update Services | 5 | 02-24-2010 02:20 PM |
| WSUS basics | GC Email Manager | Windows Update | 2 | 02-20-2010 04:17 AM |
| WSUS 3.0 SP2 - Not yet Reported | Olufis Ademidun | Update Services | 1 | 02-02-2010 03:53 AM |
| WSUS 3.0 SP2 - Not yet Update | Olufis Ademidun | Update Services | 1 | 02-01-2010 01:39 PM |
| WSUS 3 upgrade failing | Bill | Update Services | 7 | 01-29-2010 04:59 PM |
Linear Mode
