Is there a specific reason that folks are using a maintenance window in the future rather than setting one with a date in the past that is already expired?
In our environment I’ve always used an expired MW for this purpose. From: Stephen Leuthold Sent: Wednesday, October 8, 2014 12:23 PM To: [email protected] Thank you Jason and Richard. :) Sent from my Windows Phone -----Original Message----- From: "Jason Sandys" <[email protected]> Sent: 10/8/2014 12:18 PM To: "[email protected]" <[email protected]> Subject: Re: [mssms] Blanket Maintenance Window(s) for Servers Be careful with 30 years. There is a specific "bug" in ConfigMgr 2012 when processing dates beyond 2030. This may only affect deployments, but to be on the safe side, I wouldn't use anything beyond 2029. J From: [email protected] <[email protected]> on behalf of Poole, Richard <[email protected]> Sent: Wednesday, October 8, 2014 12:11 PM To: [email protected] Subject: RE: [mssms] Blanket Maintenance Window(s) for Servers It’s one of the first things we did for our collection where all servers first drop into, create a MW thirty years out. Yes, it makes for more overhead with the admins each inserting their own windows for their assigned set of servers, but it also makes for accountability when something does unexpectedly bounce. Thank you, Richard Poole From: [email protected] [mailto:[email protected]] On Behalf Of Stephen Leuthold Sent: Monday, October 06, 2014 6:26 AM To: [email protected] Subject: [mssms] Blanket Maintenance Window(s) for Servers I'm considering putting in a maintenance window for servers way into the feature to mitigate risk of unplanned reboots. Then put in maintenance windows per deployment schedules. I can see it adding additional overhead when managing deployments. What are everyone's thoughts and experience on this? Do you have something similar implemented at your organization? Thank you, Stephen
