Guest JCLEOT Posted July 5, 2007 Posted July 5, 2007 Hello all, We currently have WSUS 2.0 and are getting ready to go up to 3.0. One key feature we need is the ability to install updates on servers (sever 2003 mostly) without administrator intervention. Now, I totally understand why you can do this from the automatic updates client on XP and NOT on servers (as it currently stands).... because you would not want servers re-booting unexpectedly to install updates. Indeed we have many clustered servers and complicated heirarchial boot-order specific server startup and shutdown situations that would curl your hair. But, those are the exceptions, we have many servers where it would be fine on a schedule. Suppose you had more than 100 servers, an organized testing system, and scheduled re-boots for installing updates in an organize fashion. So, very controlled conditions where altough you might automatically do this, it would only be after you knew very well that the pathes were OK. Can anyone think of a way to do this? Can the new automatic updates client that comes with WSUS 3.0 do this? Reading the release notes I see some hints to possible changes that would allow this, but nothing explicit. If this can be done, we could use WSUS 3.0 for all updates everywhere, and not have to purchase a 3rd party tool that can do "push" installs. I know WSUS is not push technology, it's pull. But, if I could update servers in a "similar" fashion that clients get their updates, then we would be set. Thanks in advance for any help you experts can offer -) Regards jcleot
Guest Cecils\(MSFT\) Posted July 5, 2007 Posted July 5, 2007 You can get the same affect with the current client (either 2.0 or 3.0) that is on the servers. The same AU client that is in XP is also on your Servers, there is no difference in functionality, only in how you use the functionality. So no change is needed from the client perspective. One possible solution may be to look at putting the reboot capable servers into a separate GPO that will allow you to schedule the install of the updates. -- Cecil [MSFT] Deployment, WSUS Microsoft This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm "JCLEOT" <JCLEOT@discussions.microsoft.com> wrote in message news:C6445791-E8C8-4E53-B2AB-9C95D1A6B9EC@microsoft.com... > Hello all, > > We currently have WSUS 2.0 and are getting ready to go up to 3.0. One key > feature we need is the ability to install updates on servers (sever 2003 > mostly) without administrator intervention. > > Now, I totally understand why you can do this from the automatic updates > client on XP and NOT on servers (as it currently stands).... because you > would not want servers re-booting unexpectedly to install updates. Indeed > we > have many clustered servers and complicated heirarchial boot-order > specific > server startup and shutdown situations that would curl your hair. But, > those > are the exceptions, we have many servers where it would be fine on a > schedule. > > Suppose you had more than 100 servers, an organized testing system, and > scheduled re-boots for installing updates in an organize fashion. So, > very > controlled conditions where altough you might automatically do this, it > would > only be after you knew very well that the pathes were OK. > > Can anyone think of a way to do this? Can the new automatic updates > client > that comes with WSUS 3.0 do this? Reading the release notes I see some > hints > to possible changes that would allow this, but nothing explicit. > > If this can be done, we could use WSUS 3.0 for all updates everywhere, and > not have to purchase a 3rd party tool that can do "push" installs. I know > WSUS is not push technology, it's pull. But, if I could update servers in > a > "similar" fashion that clients get their updates, then we would be set. > > Thanks in advance for any help you experts can offer -) > > Regards > jcleot
Guest Gus Posted July 6, 2007 Posted July 6, 2007 On Jul 5, 12:31 pm, "Cecils\(MSFT\)" <cec...@online.microsoft.com> wrote: > You can get the same affect with the current client (either 2.0 or 3.0) that > is on the servers. The same AU client that is in XP is also on your > Servers, there is no difference in functionality, only in how you use the > functionality. So no change is needed from the client perspective. One > possible solution may be to look at putting the reboot capable servers into > a separate GPO that will allow you to schedule the install of the updates. > > -- > Cecil [MSFT] > Deployment, WSUS > Microsoft > > This posting is provided "As Is" with no warranties, and confers no rights. > Use of included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm > > "JCLEOT" <JCL...@discussions.microsoft.com> wrote in message > > news:C6445791-E8C8-4E53-B2AB-9C95D1A6B9EC@microsoft.com... > > > > > Hello all, > > > We currently have WSUS 2.0 and are getting ready to go up to 3.0. One key > > feature we need is the ability to install updates on servers (sever 2003 > > mostly) without administrator intervention. > > > Now, I totally understand why you can do this from the automatic updates > > client on XP and NOT on servers (as it currently stands).... because you > > would not want servers re-booting unexpectedly to install updates. Indeed > > we > > have many clustered servers and complicated heirarchial boot-order > > specific > > server startup and shutdown situations that would curl your hair. But, > > those > > are the exceptions, we have many servers where it would be fine on a > > schedule. > > > Suppose you had more than 100 servers, an organized testing system, and > > scheduled re-boots for installing updates in an organize fashion. So, > > very > > controlled conditions where altough you might automatically do this, it > > would > > only be after you knew very well that the pathes were OK. > > > Can anyone think of a way to do this? Can the new automatic updates > > client > > that comes with WSUS 3.0 do this? Reading the release notes I see some > > hints > > to possible changes that would allow this, but nothing explicit. > > > If this can be done, we could use WSUS 3.0 for all updates everywhere, and > > not have to purchase a 3rd party tool that can do "push" installs. I know > > WSUS is not push technology, it's pull. But, if I could update servers in > > a > > "similar" fashion that clients get their updates, then we would be set. > > > Thanks in advance for any help you experts can offer -) > > > Regards > > jcleot- Hide quoted text - > > - Show quoted text - We are faced with the same challange. In our environment there are around 100 Citrix servers that are on a stagered Sunday morning reboot schecule that lasts about fifteen minutes each across four timezones. The servers are automagically restarted between 6:00 and 6:15 AM in there respective time zones. The catch is that there is never a user logged into the console so it does not seem possible to use Option 4 even with the standard maintainence window we have. Now, if could I use option 4 to install at 5:00 with a auto reboot timeout of say 300 minutes with NO logged on user that would be great. Am is missing something on this?
Guest Harry Johnston Posted July 6, 2007 Posted July 6, 2007 Gus wrote: > We are faced with the same challange. In our environment there are > around 100 Citrix servers that are on a stagered Sunday morning reboot > schecule that lasts about fifteen minutes each across four timezones. > The servers are automagically restarted between 6:00 and 6:15 AM in > there respective time zones. The catch is that there is never a user > logged into the console so it does not seem possible to use Option 4 > even with the standard maintainence window we have. It isn't. However, if you use option 3 - download but don't install - you could then run a script ahead of your reboot cycle. Earlier this morning I posted the script I use ("Re: Updates appear to install at incorrect time") although in your scenario you should probably spend some programmer time making something smarter, so it can, e.g.: * start earlier if there are more updates than usual * stop as the reboot time approaches, even if there are more updates to do * prioritise updates so the most important are installed first * install updates that don't need reboots ahead of time This still doesn't provide a very satisfactory solution, because there is an inherent conflict between needing to make sure the system isn't still updating when the reboot happens and needing the reboot to happen as soon as possible after the updates occur. (If I recall correctly, when updates are being installed it isn't possible to reboot the system, so I think if the update runs past your reboot window the reboot either won't take place or will be delayed if I'm wrong the system might reboot in the middle of an update and potentially become unstable. You probably don't want this to happen either way.) You should consider whether the reboots really, really *need* to happen at an exact time. It would be safer if you could have a longer window during which the reboots can occur, so that when patches are needed the reboot can be delayed until patching is finished. Harry.
Guest Gus Posted July 6, 2007 Posted July 6, 2007 On Jul 5, 9:39 pm, Harry Johnston <h...@scms.waikato.ac.nz> wrote: > Gus wrote: > > We are faced with the same challange. In our environment there are > > around 100 Citrix servers that are on a stagered Sunday morning reboot > > schecule that lasts about fifteen minutes each across four timezones. > > The servers are automagically restarted between 6:00 and 6:15 AM in > > there respective time zones. The catch is that there is never a user > > logged into the console so it does not seem possible to use Option 4 > > even with the standard maintainence window we have. > > It isn't. However, if you use option 3 - download but don't install - you could > then run a script ahead of your reboot cycle. Earlier this morning I posted the > script I use ("Re: Updates appear to install at incorrect time") although in > your scenario you should probably spend some programmer time making something > smarter, so it can, e.g.: > > * start earlier if there are more updates than usual > * stop as the reboot time approaches, even if there are more updates to do > * prioritise updates so the most important are installed first > * install updates that don't need reboots ahead of time > > This still doesn't provide a very satisfactory solution, because there is an > inherent conflict between needing to make sure the system isn't still updating > when the reboot happens and needing the reboot to happen as soon as possible > after the updates occur. (If I recall correctly, when updates are being > installed it isn't possible to reboot the system, so I think if the update runs > past your reboot window the reboot either won't take place or will be delayed > if I'm wrong the system might reboot in the middle of an update and potentially > become unstable. You probably don't want this to happen either way.) > > You should consider whether the reboots really, really *need* to happen at an > exact time. It would be safer if you could have a longer window during which > the reboots can occur, so that when patches are needed the reboot can be delayed > until patching is finished. > > Harry. Thanks Harry, I did see the script you posted today. I have also looked at Rob Dunn's scripts, I'm just not the scripting guru here. The maintence window for each TZ is one hour. The window in which the servers reboot is the first fifteen minutes of the hour. If I could only make the behavior of the WUA for non logged in users something longer than what is is now that would be great. Can you refresh my memory here If there is NO logged on user, how long can a reboot be extended (if at all) by using the GPO values as published for WSUS v3 and the latest ADM if available. Thanks for the follow up.
Guest Harry Johnston Posted July 6, 2007 Posted July 6, 2007 Gus wrote: > The maintence window for each TZ is one hour. The window in which the > servers reboot is the first fifteen minutes of the hour. Is some other process controlling this? Can the patching be integrated into that process, so that the servers won't reboot until the patching is done? Can the fifteen minute window be extended - it's a bit tight. What happens during the other 45 minutes, after the reboot? > Can you refresh my memory here If there is NO logged on user, how > long can a reboot be extended (if at all) by using the GPO values as > published for WSUS v3 and the latest ADM if available. As far as I know, if there is no logged on user, the reboot will always happen as soon as the updates have been installed. I'm not aware of any way to change this behaviour. Harry.
Guest Gus Posted July 6, 2007 Posted July 6, 2007 Replies inline. On Jul 6, 12:22 am, Harry Johnston <h...@scms.waikato.ac.nz> wrote: > Gus wrote: > > The maintence window for each TZ is one hour. The window in which the > > servers reboot is the first fifteen minutes of the hour. > > Is some other process controlling this? Yes, third party software that does the shutdown on the TS boxes at a predescribed time. > Can the patching be integrated into > that process, so that the servers won't reboot until the patching is done? I am working on that with the vendor of the shutdown software now. > Can the fifteen minute window be extended - it's a bit tight. What happens during > the other 45 minutes, after the reboot? I have an hour so I may be able to set the WUA to install at say 5:00 AM, but I don't want the WUA to force the reboot. I want my software to do the reboot because it does many other things that are beneficial in a TS environment. > > Can you refresh my memory here If there is NO logged on user, how > > long can a reboot be extended (if at all) by using the GPO values as > > published for WSUS v3 and the latest ADM if available. > > As far as I know, if there is no logged on user, the reboot will always happen > as soon as the updates have been installed. I'm not aware of any way to change > this behaviour. I can think of one real quick. PE and a good Hex editor. This would of course leave me totally unsupported from the MS perspective. > Harry. Thanks-
Recommended Posts