Honestly, hard to say. We have it implemented, but the team that owns it hasn’t started using it. We know the capability is there for full automation, the only prereq we had to do was set the EnablePME reg key to allow WoL on the NIC.
Daniel Ratliff From: [email protected] [mailto:[email protected]] On Behalf Of Adam Juelich Sent: Thursday, March 30, 2017 8:44 AM To: [email protected] Subject: Re: [mssms] Maintenance Windows & Restart Behavior Thanks, guys. Daniel, how has 1E Nightwatchman been? Our WoL isn't perfect. It has gotten better since I configured compliance settings for NIC Power Management. Since we are smaller they won't do a PoC with us but until I can see proof that this gives us a better success-rate, I can't justify the cost to management. On Wed, Mar 29, 2017 at 8:58 PM, Marable, Mike <[email protected]<mailto:[email protected]>> wrote: Well, we have the agreements as to when we can deploy software, essentially after hours. We don’t use Maintenance Windows for them, we just set up a deployment to run as a specific time (maybe 11:00 pm for example) and fire it off. We will divide up the deployment into multiple days. Typically we’ll do a 3 day with maybe 10% of the intended machines on day 1, 25% on day 2 and the remainder on day 3. Mike From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Adam Juelich Sent: Wednesday, March 29, 2017 4:07 PM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] Maintenance Windows & Restart Behavior Thanks, Mike. So you guys strictly use Windows Embedded? If you have traditional clients, how do you manage them differently? On Wed, Mar 29, 2017 at 2:27 PM, Marable, Mike <[email protected]<mailto:[email protected]>> wrote: Hi Adam, 1. Maintenance Windows a. We use these only on our embedded devices and not on traditional clients. We have a window set once a week (like 2 am on Sunday mornings) so that SCCM turns off the write filter on the device, runs our deployments and then re-enables the write filter. 2. Restart Behavior / Communications a. We actually have written our own utility to handle reboots. It allows us to display a message to the end user, countdown timer, users can delay the reboot, we can have it check for running executables before attempting to reboot, etc. b. We have agreements in place with critical areas, such as emergency rooms, and other 24hour clinics to limit reboots to specific days and times. Otherwise the understanding with the users is that we will do our deployments and maintenance outside of business hours. Combine that with our reboot tool and the users are pretty happy. We do use WOL very heavily. Different clinics have varying office hours/days and we have collections set up to wake machines up about 15 minutes before the beginning of business for them. We’ve been very successful with that. The WOL issues that we have run into in the past have usually been attributed to either mis-configured BIOs settings or users hard-powering off machines. Mike From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Adam Juelich Sent: Wednesday, March 29, 2017 2:55 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] Maintenance Windows & Restart Behavior Hello Everyone, This isn't as much of a question as much as a poll on how people are doing this. I know everyone is in charge of different environments, different sizing, and other complex variables. I'd like to know what settings you specify for the following items: 1. Maintenance Windows * What are your MW for Windows Clients? * Do you usually just do it for 'Restarts' or 'Installs' as well? * Are you leveraging WoL and/or AMT? * If so, what is your success rate? 1. Restart Behavior * What do you specify for the two Client Notifications? 1. Communication * How have you communicated this to end-users? It's obviously a delicate balance between security and end-user convenience. Every environment is different but I'm curious. Anything else that I missed in this realm, I would appreciate knowing! Thanks! ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues 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.
