If your maintenance window is only an hour the larger updates may not install if Microsoft has their estimated time of install set to an hour or more. You may need to adjust the estimated install times as well if you have that short of a MW. Here is what I do because there are laptops in our environment that may not be on during MW.
Desktops and laptops: Deadlines are set to midnight Saturday with ignore maintenance windows. If machines are on at that time they will install. If they are off they will install the next time they are online. Users get asked to reboot but the machine will reboot on its own at the next maintenance window. Servers: Deadline set to midnight and are set to respect maintenance windows so they don't update in the middle of the day. Nick Gailfus Computer Technician p. 602.953.2933 f. 602.953.0831 [email protected] <[email protected]>| www.leonagroup.com On Thu, Jan 8, 2015 at 9:15 AM, Jason Sandys <[email protected]> wrote: > Your requirement isn’t that they start at 5, it’s that they occur > between 5 and 6 and that’s exactly what the MW does. So, based on that, > your MW needs to be from 5-6 AM. I’m missing why that’s not acceptable > though. > > > > With this MW in place, updates will start on online systems at 5 AM and no > update will be installed that is expected to finish after the MW finishes. > Note that the MW calculation also accounts for a final reboot (which I > think it counts as 5, 10, or 15 minutes -- don’t remember which), thus it > really won’t start any updates expected to finish after 5:45, 5;50, or 5:55 > (depending upon the time it expects for the reboot). All updates by default > are expected to take 5 minutes in ConfigMgr 2012 although this can be > adjusted on an update by update basis. If there are lots of updates, it’s > possible they all don’t fit into the window though. > > > > J > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *James Avery > *Sent:* Thursday, January 8, 2015 9:05 AM > > *To:* [email protected] > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > > > Has to be from 5-6am no time after due to other applications happening. > > > > 1. All systems request patches from the WSUS server > > 2. All systems have a local GPO (workgroup computers) to tell the > system to install patches at 5am. > > 3. Some locations are 24hrs and must have a definite time when they > are scheduled for maintenance with various applications. > > 4. After patches are applied, all the systems reboot. With this > information, there isn’t a staggers communication with the MP since all > reboot within 10min of each other. > > James > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Jason Sandys > *Sent:* Thursday, January 08, 2015 8:33 AM > *To:* [email protected] > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > The deployment start time within a MW will be as soon as the MW opens. You > have to set the MW to be larger to ensure that all of the updates queued up > fit within the MW because it will not attempt to install an update if the > MW is too short. Thus, the size of the MW has nothing to do with start time > of the deployment. Now, if a system happens to be off at 5AM but comes > online within the MW, it will try to start the deployment of updates so if > that’s the scenario you are trying to prevent, I don’t think there is a > good way to handle that. > > > > What’s the scenario here where that requirement is valid though? Patching > takes time, that’s why there are MWs. It could finish in 10 minutes or > three hours later – there’s really no way to know ahead of time. > > > > J > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *James Avery > *Sent:* Wednesday, January 7, 2015 6:26 PM > *To:* [email protected] > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > I have a question with Software Updates in SCCM 2012 R2 > > > > Is there a way to have all 5k + systems download the software updates and > have them all start the updates at 5am only. They can’t start later. They > must start at 5am only. > > > > I remember back in 2007, I would have set maintenance windows and allow a > 4-5 hour window. > > > > Is this the same with 2012 R2? > > > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Lutz, Ken > *Sent:* Wednesday, December 10, 2014 12:05 PM > *To:* [email protected] > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > The way I deal with this is: > > Each month I create a new deployment for that month’s security updates. I > have this deployment set to only install and reboot during the maintenance > window. I deploy with a set deadline (usually the next day). I tell the > deployment that it can only install and reboot during the maintenance > window. > > > > When I get a new deployment (usually for the next month) I go back to the > previous month and tell the deployment that it can install outside the > maintenance window, but leave the reboot only in the MW checked. Then I go > back two months and uncheck the reboot outside MW check box. > > > > This way I figure the updates get installed at least one month behind > schedule, and rebooted at least two months back. Not the fastest, but it > covers the folks that don’t want to install any other way. I also figure > if they haven’t installed the updates in two months they deserve to have > their systems rebooted as needed. > > > > So far this seems to be working good for us. > > > > *Thanks,* > > *Ken …* > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Orlebeck, Geoffrey > *Sent:* Wednesday, December 10, 2014 9:09 AM > *To:* '[email protected]' > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > This is where the issue lies, users never want to be interrupted, so they > will delay indefinitely (had this issue with WSUS where users would delay > for weeks before we forced reboots). Now with SCCM it will be much cleaner > overall, but I was just hoping the behavior would be a bit different—if I’m > deploying something and am making it available immediately, but the > deadline is 7 days out, still try to install it as soon as possible but > force it if cannot be accomplished within 7 days. > > > > I get it now, and I understand the process, I just think their logic is > different than mine. Thank you for the insight and discussion points, I’ve > enjoyed the dialogue. > > > > Thanks, > > Geoff > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Miller, Todd > *Sent:* Wednesday, December 10, 2014 7:46 AM > *To:* [email protected] > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > > ‘It requires a small amount of user participation” – Ah, there’s the rub. > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Jason Sandys > *Sent:* Wednesday, December 10, 2014 8:22 AM > *To:* [email protected] > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > What you’ve described below is the intent of business hours. It requires a > small amount of user participation; however, as long as they have checked > the box in software center to perform required updates outside of their > business hours, it will in fact work that way since user initiated > deployment – which is what this would be – don’t consider maintenance > windows. > > > > J > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Miller, Todd > *Sent:* Tuesday, December 9, 2014 5:18 PM > *To:* [email protected] > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > Maintenance windows are a little tricky with software updates. You have > to choose among two options that both have pitfalls. > > > > Either you set a deadline and ignore maintenance windows, in which case > the update installs at the deadline or the next time the computer is on > after the deadline. So basically maintenance windows are useless/ignored. > > > > Or you set the deployment to respect maintenance windows, in which case > any computer that is not on during its maintenance window – think laptops – > *never > ever patches *Unless the user chooses to (ha ha ha! ). In this case > maintenance windows help you avoid patching during business hours, but you > could end up with *lots* of unpatched systems to remediate. > > > > It is difficult to choose among these two options. > > > > > > It *would* work much better if it worked how you initially thought it > worked ---- If there is a pending software update, install it at the next > maintenance window. If the deadline is past, install regardless of > maintenance window. This way you could have machines try to install during > a maintenance window for a week (or a few days), and if it still didn’t > find time to install during the *preferred* maintenance window, it would > just install at the deadline (which is the only time WOL packets are sent > too, btw) > > > > > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Jason Sandys > *Sent:* Tuesday, December 09, 2014 4:03 PM > *To:* [email protected] > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > As an additional note here, deadlines are not “lines in the sand”, they > are absolute lines in concrete. A ConfigMgr client agent will not enforce a > deployment until that deployment has reached its deadline (or the user > initiates the deployment). > > > > J > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Orlebeck, Geoffrey > *Sent:* Tuesday, December 9, 2014 11:39 AM > *To:* '[email protected]' > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > Great, thank you for getting back to me! > > > > -Geoff > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Gerry Hampson > *Sent:* Tuesday, December 09, 2014 9:33 AM > *To:* [email protected] > *Subject:* [mssms] RE: Software Updates & Maintenance Windows: > > > > Geoff, the updates will install during the first maintenance windows AFTER > the deadline is reached. > > > > Regards, > > Gerry > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Orlebeck, Geoffrey > *Sent:* 09 December 2014 17:24 > *To:* '[email protected]' > *Subject:* [mssms] Software Updates & Maintenance Windows: > > > > Hello group. I’ve been working a bit more with SCCM (2012 R2, single > primary site) and I have a question surrounding how maintenance windows and > deadlines work. I just want to confirmation as I haven’t seen this > addressed specifically anywhere that I’ve looked, including TechNet. > > > > If I create a Software Update Group today (12/9) and deploy it with a > deadline for 12/13 @ 2AM to a collection with a Software Updates > maintenance window daily from 11PM-5AM, the updates still won’t actually > install until the deadline is hit, correct? That is the behavior I am > currently seeing in my environment. Even though the devices may download > the updates today, and there are maintenance windows that occur nightly > from now until 12/13, the updates don’t actually install until the deadline > is reached. Is that correct? My assumption (I know…assumptions) was the > deadline was a line in the sand, but if a maintenance window passes before > the deadline and there are pending deployments, those would process. > > > > Since this is my first go with ConfigMgr, I just want to confirm the above > behavior is by design and that I haven’t misconfigured something. > > > > Happy to provide any additional details if needed. Thanks! > > > > -Geoff > > > > Confidentiality Notice: This is a transmission from Community Hospital of > the Monterey Peninsula. This message and any attached documents may be > confidential and contain information protected by state and federal medical > privacy statutes. They are intended only for the use of the addressee. If > you are not the intended recipient, any disclosure, copying, or > distribution of this information is strictly prohibited. If you received > this transmission in error, please accept our apologies and notify the > sender. Thank you. > > > > > > Confidentiality Notice: This is a transmission from Community Hospital of > the Monterey Peninsula. This message and any attached documents may be > confidential and contain information protected by state and federal medical > privacy statutes. They are intended only for the use of the addressee. If > you are not the intended recipient, any disclosure, copying, or > distribution of this information is strictly prohibited. If you received > this transmission in error, please accept our apologies and notify the > sender. Thank you. > > > > > > > ------------------------------ > > 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. > ------------------------------ > > > > > > > ------------------------------ > > 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. > ------------------------------ > > > > Confidentiality Notice: This is a transmission from Community Hospital of > the Monterey Peninsula. This message and any attached documents may be > confidential and contain information protected by state and federal medical > privacy statutes. They are intended only for the use of the addressee. If > you are not the intended recipient, any disclosure, copying, or > distribution of this information is strictly prohibited. If you received > this transmission in error, please accept our apologies and notify the > sender. Thank you. > > > > > > > > > > > >
