We use SCCM but even when we only used WSUS we controlled the timing and authorization of all patches. Before it was a horrible schedule of 3 marathon nightmare weekends. Now...
Tuesday - patch release, meeting. Wednesday - Dev environment patched. 6pm to midnight. Thursday - Testing environment patched. 6pm to midnight. Saturday - Production patched. 6pm to midnight. In between is. 1. Notify given environment patched. 2. Wait for whiny emails blaming patch for causing issue. 3. Ignore emails demanding they exclude it from specific production systems until it gets to the right directors who must then fill out a form subject to approval, completely. There are few permanent exceptions allowed (_cough_ crappy telco software) those require VP approval. Just 30 day time frames. They mus remember form again next month. We really want those systems patched. 4. Make them prove it's the patch, ask for their MS case number. 5. Remind them of the past several times that it turned out to be a configuration issue on their 'identical environments' 6. Grudgingly exclude special system from that patch. 7. Put the patch on next month because it was a configuration issue not the patch. 8. Gloat. So far this process patches over 1000 systems in 5 different environments each month. We have found a few (1-3) where a given patch breaks telco software on specific servers. We got nailed by the LS/OCS patch (since corrected by MS) which means I got woken up at 7am on Sunday which was my fault anyway for not paying proper attention to my OCS test environment. We also patch our VMware host environments during the same week. They are on a Tuesday/Wednesday/Friday schedule. We have some servers which are a auto patch with manual reboot for various application dependency issues. The server owners do the reboot. Generally we use 2 people each night. If it's not a critical security patch, it can wait. If it is, then the choices are partial out of band patching or the whole environment. We have done both. There is nothing more fun then going to work at 7am and discovering everyone is staying late to help ensure that all environments are patched and tested by midnight. Usually the patch itself narrows the target to external facing systems but not always. Steven On Mon, Nov 30, 2009 at 10:02 PM, Carl Houseman <[email protected]> wrote: > The secondary ones (4th Tuesday) are USUALLY not security related but there > have been security patches show up there, every now and then. > > > > Carl > > > > From: Andrew S. Baker [mailto:[email protected]] > Sent: Tuesday, December 01, 2009 12:28 AM > To: NT System Admin Issues > Subject: Re: Trying to save myself a bit of work > > > > Yeah, but since the secondary ones are not security related, there is less > urgency associated with them for most people. > > ASB (My XeeSM Profile) > Providing Competitive Advantage through Effective IT Leadership > > > > On Mon, Nov 30, 2009 at 9:42 PM, Angus Scott-Fleming <[email protected]> > wrote: > > On 30 Nov 2009 at 13:22, [email protected] wrote: > >> I would expect it to be 28 days min > > Actually I would think it would be 14 days as I just saw strong suggestions > that Patch Tuesdays will now be the 2nd and 4th Tuesdays. > > See "The Other Patch Tuesday is the Fourth - Security Watch" > http://blogs.pcmag.com/securitywatch/2009/11/the_other_patch_tuesday_is_the.php > > and http://www.google.com/search?q=4th+tuesday+patch+microsoft for > confirmation > of this. > > -- > Angus Scott-Fleming > GeoApps, Tucson, Arizona > 1-520-290-5038 > +-----------------------------------+ > > > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
