"Doing it this way, will the normal deployment states reports show me where I am, and servers that have failed due to running out of time?" um, maybe? I don't know anymore, because we've made so many custom reports for monitoring update group membership, deployments, status of those deployments, 'what did we miss', etc., etc.,... I don't think I've run a normal SU out of the box report in over a year. If you wanted to try it and see what happens... on a pilot box you can mess with, make a collection with a service window of 5 minutes, daily (there might be a minimum maybe 15 min? I don't know--because we require anyone here who wants to use a service window that they have to have at least 4 hour service windows). add that 1 pilot box to that collection. Find an update that pilot box deserves... or uninstall some older patch from it, so it deserves it again (but it's not in any current SU Groups currently being deployed). For that ONE patch... go to properties on that patch and set the 'time to install' from the default to something ridiculously long, like 120 minutes (i.e., lots more than the service window). Add that one patch to a test SU Group, deploy that SU Group to that one box... and see what the reports you normally look at say after the deadline of the SUG. Did the box patch anyway? or does it just say 'waiting for service window' (It might only say that...not "waiting for service window because 15 minutes isn't enough when I need 120 minutes")
I suspect it might only say "Waiting for Service Window". So you'd have to just 'know' that your boxes should have installed those patches on Monday... and with a nightly service window, now that it's Thursday (or whatever) they should have installed patches--so you know to go look deeper. On Tue, Apr 18, 2017 at 12:17 PM, Heaton, Joseph@Wildlife < [email protected]> wrote: > Thanks, Sherry. I have been thinking of Service Windows, but your > explanation of how to set them makes a lot of sense. The vast majority > (99%+) of my servers are up to date, so I don’t think I’ll run into the 35 > updates issue, but it’s definitely food for thought. Doing it this way, > will the normal deployment states reports show me where I am, and servers > that have failed due to running out of time? > > > > *From:* [email protected] [mailto:listsadmin@lists. > myitforum.com] *On Behalf Of *Sherry Kissinger > *Sent:* Thursday, April 13, 2017 8:23 AM > *To:* [email protected] > *Subject:* Re: [mssms] Patching advice - Cross Post from Patching list > > > > You asked "how are you doing this"... and I don't have those types of > timing demands on the servers I support for patching. But here's my > likely-not-well-thought-out vague ideas on how I'd think about doing it. > (and pilot, and test, and test and test...) > > > > Create multiple collections. Those collections have one role and one role > only. Their only job is to let you define the Service Windows for when > software updates can occur. Add all the SQL boxes into the Collection > called "SUM Service Window 7pm to 11pm" Add all the Web server boxes to > "SUM Service Window 11pm to 3am". Add all the you go last boxes to "SUM > Service Window 3am to 7am". Now, set Service windows on those collection, > for Software Updates only, with daily, those times. You NEVER deploy > anything to those collections, and you don't use them for anything else, > ever. Remember, their 1 and only job is to define Service Windows. > > > > Deploy patches as (almost) normal; but do remember to have the deployment > honor service windows, and you DO want to allow servers to reboot, > post-patching. > > > > What should happen is the boxes in the 7-11pm service window might get the > patch deployment policy at 3pm... but it'll wait until 7pm to start > installing (it'll download prior, but won't actually patch til 7pm-ish); > and reboot when done. the boxes in the 11pm-3am service window will wait > until 11pm for their turn to install, and reboot. and 3am-7am will wait > til 3am. But ... by the morning everyone should be done. Unless, of > course (and this could happen, but unlikely)... let's say there is a box > which deserves 35 patches. and estimated time to install EACH one is 30 > minutes. the CM client itself does the math, and says to itself... huh. > 35 * 30 minutes ... I'll never patch in the 4hr window. "skipping until I > can" (and of course, it'll never have a service window big enough). So > you'd just have to keep that in mind if you encounter failures like that. > In those cases, if it's just 1 or 2 boxes the easy cheat is just > interactively login, and trigger the install from Software Center of the > updates. A human triggering an install overrides a service window. You > could also of course on the deployment check the box for "override service > window"--but then that defeats your whole plan of timed deployments. but > it is an option. Not a GREAT option because of your stated goals... but it > is an option. > > > > > > > > On Wed, Apr 12, 2017 at 4:21 PM, Heaton, Joseph@Wildlife < > [email protected]> wrote: > > I’m using SCCM for patching. Currently, I push server updates in two > phases. First, all my Dev/Test machines. The next week, everything else. > I have 215 Production servers that get patched. There are SQL boxes, Web > boxes, Application boxes, File servers, DCs, etc. My process now: > > > > 1) Deploy updates at 3:00PM. > > 2) Go home, and at 7:00PM, run a Pending restart report. > > 3) Open up vCenter, and start opening up consoles, 14 at a time, and > kicking off reboots. > > 4) Rinse, repeat until I’m through. > > > > Some of the considerations I have: > > > > 1) Reboot order is important. SQL has to reboot before web or apps, > web has to reboot before apps, that kind of thing. > > > > My ask of you guys: > > > > I’m tired of doing everything manually. I’d love to hear how other folks > are doing this patching thing, and how I can improve my life. Please, > don’t pull punches, either. > > > > > > Joe Heaton > > Information Technology Operations Branch > > Data and Technology Division > > CA Department of Fish and Wildlife > > 1700 9th Street, 3rd Floor > > Sacramento, CA 95811 > > Desk: (916) 323-1284 > > > > Every Californian should conserve water. Find out how at: > > <http://saveourwater.com/> > > *SaveOurWater.com* · *Drought.CA.gov* <http://saveourwater.com/> > > <http://saveourwater.com/> > > > > > -- <http://saveourwater.com/> > > Thank you, > > Sherry Kissinger <http://saveourwater.com/> > > > My Parameters: Standardize. Simplify. Automate > Blogs: *http://www.mofmaster.com*, > *http://mnscug.org/blogs/sherry-kissinger*, *http://www.smguru.org* > <http://saveourwater.com/> > > <http://saveourwater.com/> > > -- Thank you, Sherry Kissinger My Parameters: Standardize. Simplify. Automate Blogs: http://www.mofmaster.com, http://mnscug.org/blogs/sherry-kissinger, http://www.smguru.org
