It takes maybe ten minutes to approve patches each month if you have a good search query built and a well documented procedure. In that way you know that the group is created, a person in charge of patching has looked at each patch and evaluated the urgency of the patches, old patches have been decommissioned.... The patching system, I think is one of those spots that automating the process is a bad idea- but to each his own I guess. I've never found setting up a software update group each month to be that onerous on my team. Once the software update group has been manually created and the patches are added via a saved search we have a Powershell script to create phased mandatory times for the new group to test, 10%, 50%, 100% standing collections. So, setting up the deployments we've semi-automated a someone still has to run a PS script. To me it seems like looking for trouble to automate such a critical and fragile system when it takes so little time to begin with.
> On Apr 17, 2016, at 10:16 PM, Jason Sandys <[email protected]> wrote: > > The second Thursday can also occur before the second Tuesday so that's not > perfect either. You need to either push to using the 3rd occurrence of > Tue-Sat of a month, run the manually, or script them to run. > > J > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Corkill, Daniel > Sent: Sunday, April 17, 2016 8:32 PM > To: [email protected] > Subject: RE: [mssms] Monthly ADRs for patching > > Hey I'll vote for that! I'd like to be able to just configure the scheduling > for an ADR to run "xx days after Patch Tuesday" and it just figures it out. > Meanwhile, being in Australia, Patch Tuesday is actually Patch Wednesday > here. Although, some months Microsoft Update doesn't have all the updates yet > and our SUP sync doesn't get everything so I have our ADR run on the second > Thu now and we never miss anything. I've just setup a recurring Outlook task > for the 1st of every month and I verify the second Thu of that month in > relation to Patch Tuesday and adjust the ADR accordingly. > > Daniel. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Schwan, Phil > Sent: Saturday, 16 April 2016 5:34 AM > To: [email protected] > Subject: RE: [mssms] Monthly ADRs for patching > > https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/8819518-software-update-patch-tuesday-scheduling > > Agree that it would be better to have more flexible scheduling options. > > -Phil > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Jason Sandys > Sent: Friday, April 15, 2016 2:54 PM > To: [email protected] > Subject: RE: [mssms] Monthly ADRs for patching > > Well, remember, the ADR only can grab what's in your ConfigMgr DB based upon > your Update Sync Cycle. Thus your update sync cycle also needs to run and be > complete before the ADRs run but after the catalog is update by Microsoft. > Thus, I normally schedule the update catalog sync around 6PM-ish CST every > Tuesday and then the ADRs after that or alternatively every Wednesday morning > and kick off the ADRs manually on the day after Patch Tuesday. > > Not perfect I know. I do have a long, long standing DCR (from the 2012 beta > days 5+ years ago) for improving the scheduling to be relative to something > other than the first of the month (like patch Tuesday) but it keeps getting > pushed off :-( > > Another option here is to script it all. Steve Rachui has an excellent blog > and set of scripts on this. > > J > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Stephen Leuthold > Sent: Friday, April 15, 2016 1:07 PM > To: [email protected] > Subject: Re: [mssms] Monthly ADRs for patching > > To add to he conversation: > > I ran an ADR on patch Tuesday at 8:00 PM CST and it did not grab the latest > Windows 10 / Office 2016 updates . I ran it again Wednesday morning and it > grabbed them. I've since rescheduled to 11 PM. I was hoping to run the ADR at > 8 since I would be able to setup the deployment in "days" to meet schedule > needs, instead of "hours". > > -Stephen > >> On Apr 15, 2016, at 1:00 PM, Jason Sandys <[email protected]> wrote: >> >> ADRs work just fine. The problem is that you've scheduled them to run based >> upon the false assumption that the 2nd Wed or Thu or a month always occurs >> after the 2nd Tuesday. The best thing to do to overcome this is to either >> schedule the ADRs to run on the 3rd occurrence of a day of the month or on >> the 2nd Tuesday itself (sometime in the evening) although this later >> approach is impossible in Eastern parts of the globe (nearer to the >> international date line) where they've already crossed into Wed before >> Microsoft has even update the WSUS catalog. >> >> None of this really has anything to do with the question though. The best >> answer here is to upgrade to 1602 where you can create multiple deployments >> on a single ADR. >> >> J >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Marcum, John >> Sent: Friday, April 15, 2016 6:34 AM >> To: [email protected] >> Subject: Re: [mssms] Monthly ADRs for patching >> >> I shouldn't have said they will always fail a couple times a year. If you >> patch on patch Tuesday they are fine. Otherwise they won't always work. >> >> Typos compliments of Siri >> Sent from my iOS device >> >>> On Apr 15, 2016, at 6:27 AM, Kevin Johnston <[email protected]> >>> wrote: >>> >>> We have an ADR that was created by a consultant a few years back and for a >>> long time I just dealt with it, and now I want to clean it up. >>> >>> It is as follows: >>> >>> Date Released or Revised Last 1 week (7 days) Product (this includes >>> server OS, Office, Windows OS, runtimes, SQL Server, defender, >>> Silverlight, etc...) Title -Embedded OR -Itanium Update >>> Classification >>> - Critical Updates OR Security Updates OR Updates >>> >>> Evaluation Cycle Occurs every 1 week on Tuesday effective 6/21/2013 >>> 3:00PM >>> >>> The issue I have with this is every "Patch Month" I have about 3 ADRs that >>> are created... So I have to deploy these 3 ADRs to the same Patching >>> collections every month. >>> >>> Is there any way to only have only 1 ADR get created per month, or maybe >>> combine them if they happen to be the same month? Or maybe I should >>> manually add them all together? >>> >>> I realize that patches are not always released on Patch Tuesday, but it >>> just seems like a lot of extra work to have to deploy 3 ADRs for 1 month to >>> 7 collections 3 times. >>> >>> We always deploy our patches to production 1 month behind, unless there is >>> a critical must have patch. And current month patches get deployed to a few >>> staging servers and workstations to ensure everything works. >>> >>> KEVIN JOHNSTON >>> >>> >>> >>> >>> >>> >>> ________________________________ >>> >>> Confidentiality Notice: This e-mail is from a law firm and may be protected >>> by the attorney-client or work product privileges. If you have received >>> this message in error, please notify the sender by replying to this e-mail >>> and then delete it from your computer. > > > > > > > > > > > > > ********************************************************************* > This email, including any attachment, is confidential to the intended > recipient. It may also be privileged and may be subject to copyright. If > you have received this email in error, please notify the sender immediately > and delete all copies of the email. Any confidentiality or privilege is not > waived. Neither the Council nor the sender warrant that this email does not > contain any viruses or other unsolicited items. > > This email is an informal Council communication. The Council only accepts > responsibility for information sent under official letterhead and duly signed > by, or on behalf of, the Chief Executive Officer. > > Privacy Collection Notice > Logan City Council may collect your personal information, e.g. name, > residential address, phone number etc, in order to conduct its business > and/or meet its statutory obligations. The information will only be accessed > by employees and/or Councillors of Logan City Council for Council business > related activities only. If your personal information will be passed onto a > third party, Council will advise you of this disclosure, the purpose of the > disclosure and reason why. Your information will not be given to any other > person or agency unless you have given us permission or we are required by > law. > > > > > > > > ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________
