Just confirming, you are referring to apps not packages for the Software Center issues, or does it apply to both?
Daniel Ratliff From: [email protected] [mailto:[email protected]] On Behalf Of Andrew Craig Sent: Friday, October 10, 2014 7:45 AM To: [email protected] Subject: RE: [mssms] Blanket Maintenance Window(s) for Servers +1 for dates in the past but I don’t really think it makes a difference. Unless in 29 years all your servers suddenly start running 29 years backlog of pending installations. That would be hilarious. Without hijacking too much just a couple of things to add about maintenance windows that might be interesting: If you use a date in the past for a mw as described in OP, then don’t use 01/01/1900 for the effective date as this confuses things and the date will then be set to the current date and time, without displaying notification or error. If you set such a mw and then a user logs on to the affected machine, any required software for the user will show as in error in software center. This is because the appdiscovery runs regardless of mw and the whole app process begins to start before the servicemanager kicks in and overrules. These components don’t talk properly to one another so software center is left with an unknown or dependency error. And of course if the user decides to click on the software in software center, then it will install regardless of mw. Even if it is an app deployed as required to the user rather than available, once it errors – as in previous point – it is available for retry and if the user initiates this retry then the mw is ignored. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Michael Roach Sent: 09 October 2014 09:42 To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] Blanket Maintenance Window(s) for Servers 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<mailto:[email protected]> Sent: Wednesday, October 8, 2014 12:23 PM To: [email protected]<mailto:[email protected]> Thank you Jason and Richard. :) Sent from my Windows Phone -----Original Message----- From: "Jason Sandys" <[email protected]<mailto:[email protected]>> Sent: 10/8/2014 12:18 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Poole, Richard <[email protected]<mailto:[email protected]>> Sent: Wednesday, October 8, 2014 12:11 PM To: [email protected]<mailto:[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]> [mailto:[email protected]] On Behalf Of Stephen Leuthold Sent: Monday, October 06, 2014 6:26 AM To: [email protected]<mailto:[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 The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
