Server Updates
How you do you prefer to handle server OS updates? We are debating not using WSUS due to internal policy and reboot issues but could adjust the server policy to not allow the reboot. Does anyone allow the server to get updates directly? The issue I have with that is the administrative rights needed to apply the patches and or/access them.
RE: Server Updates
Just remember that malware doesn't have to ask your boss for permission and doesn't give a hoot about your internal policies or whether it should have administrative rights or not. Too much bureaucracy aids the malware purveyors. Cheers, Phil -- Phil Randal | Networks Engineer Herefordshire Council | Deputy Chief Executive's Office | I.C.T. Services Division Thorn Office Centre, Rotherwas, Hereford, HR2 6JT Tel: 01432 260160 email: pran...@herefordshire.gov.uk Any opinion expressed in this e-mail or any attached files are those of the individual and not necessarily those of Herefordshire Council. This e-mail and any attached files are confidential and intended solely for the use of the addressee. This communication may contain material protected by law from being passed on. If you are not the intended recipient and have received this e-mail in error, you are advised that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. If you have received this e-mail in error please contact the sender immediately and destroy all copies of it. -Original Message- From: mqcarp [mailto:mqcarpen...@gmail.com] Sent: 01 July 2009 16:08 To: MS-Exchange Admin Issues Subject: Server Updates How you do you prefer to handle server OS updates? We are debating not using WSUS due to internal policy and reboot issues but could adjust the server policy to not allow the reboot. Does anyone allow the server to get updates directly? The issue I have with that is the administrative rights needed to apply the patches and or/access them.
RE: Server Updates
Not sure how WSUS is the issue here. Set it to download only, then manually install and manually reboot. Or download, auto install and disable automatic reboot and just do the reboot manually. Unless I am reading your question wrong that gets you where you want to be? > -Original Message- > From: mqcarp [mailto:mqcarpen...@gmail.com] > Sent: Wednesday, July 01, 2009 11:08 AM > To: MS-Exchange Admin Issues > Subject: Server Updates > > How you do you prefer to handle server OS updates? > > We are debating not using WSUS due to internal policy and reboot > issues but could adjust the server policy to not allow the reboot. > Does anyone allow the server to get updates directly? The issue I have > with that is the administrative rights needed to apply the patches and > or/access them.
RE: Server Updates
> How you do you prefer to handle server OS updates? > [snip]Lovely Bureaucracy[/snip] We use WSUS...it's just the best free way. You could use Config mgr or shavlik but $ Here's how we do it: There's a scheduled maintenance window after hours (a maintenance window is a must, keep pushing until you get one); on top of that we manually call and notify affected personnel so we can wait for the operations to be done and affect people as little as possible. Our group policy is set so nothing in theory[1] auto-reboots as a result of wuauclt. The policy is also set to pop-up the "reboot needed" every 5 minutes to the logged on user. We don't have a great number of always mobile users and so get away with just one policy. Other places would have to define different policies to different containers so that laptops, etc... will reboot themselves. So, in WSUS we have set up various groups representing not just clients and servers, but also "test" versions of those and some other groups for more critical servers. Patches are rolled out first to test groups and trickle down to the others by a schedule. Using groups makes it easy to control what machines will download a patch so updates can be tested before they bring down a production application (that's *very* rare these days) yet minimize the vulnerability window across the greatest number of machines as is possible. We use Mr. Dunn's updatehf.vbs script via psexec and .cmd files to more finely control when machines download and patch themselves. Then psshutdown... Using this process allow all machines to be updated in about 4 admin-hours per month with basically no effect on our LOB. A pain point is with multi-tier app dependencies where services on one machine depend on services on another machine; thankfully not too many of those here. :) The biggest time waster we see is with the actual clients where an update fails to install and also some lack of full error handling problems in updatehf which generally requires resetting the whole windows update stack on that client. If zero downtime is a requirement, then some type of clustering would be required if you have to stay on the windows platform. ~JasonG [1] In theory, theory is the same as practice; in practice... Keep WELL in mind: There's a bug in at least XP/2003 where if the logged in console user logs off via start->log off... the machine will reboot instead of logging off in some instances when wuauclt is reporting a needed reboot. Work around is to never log off in that scenario; can't wait for that to be fixed!
