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 < joseph.hea...@wildlife.ca.gov> 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: > > [image: SaveOurWater_Logo] <http://saveourwater.com/> > > SaveOurWater.com <http://saveourwater.com/> · Drought.CA.gov > <http://drought.ca.gov/> > > > -- Thank you, Sherry Kissinger My Parameters: Standardize. Simplify. Automate Blogs: http://www.mofmaster.com, http://mnscug.org/blogs/sherry-kissinger, http://www.smguru.org
