none
Forcing Reboots But Allowing and End User to Stop it

    Question

  • I work in a hospital with AD 2012 and Windows 7 on all of our operating systems, approximately 1000 devices. We want to be able to reboot all of our clinical pc's once a week in order to refresh them and get users who have used the switch user option logged off as we tend to see huge build ups of users logged in over time.

    We have agreed to do this in the early hours of the morning once a week and give the end user a on screen warning that this is about to happen however, we are concerned that if there is work on the screen and the user notices in the last seconds that its about to reboot that they'll lose that work. In a hospital this isn't an option as users have patient information that they may have worked on for hours.

    In short I'm looking for a way through GP that we would be able to send the notification to the desktop that it is about to reboot and still allow a user to intervene and stop the reboot, or even better, a solution that someone else is using that may be better all together. Any thoughts would be appreciated.

    dontspamme@outlook.com

    Thursday, June 23, 2016 8:20 PM

Answers

  • Group Policy Preferences will allow you to deploy scheduled tasks to Windows targets.
    The scheduled task can run whatever you like, whenever you set the schedule.
    The catch will be to run something which can notify any/all logged-on users, allow postponement, and provoke the restart.

    something like this: http://blog.coretech.dk/kea/new-version-of-the-coretech-shutdown-tool/
    but I'm sure there are many other ways to do it.

    Do you have a deployment management solution/tool? (ConfigMgr or LANDesk or Managesoft or anything)

    Make sure you have senior management support for your initiative - you may need your supporter/sponsor to back you up if things get nasty.
    I suggest you also tackle the communication/culture aspects through your organisation - introducing something like this can be very disruptive, and in the scenario you described could be poorly received. Consider a very generous notification period, and let that run out for a while and then see how that's accepted with a plan (communicated) that you will be reducing the notification period to shorten it.

    Test/pilot your solution, communications and tweaks on a small number of machines, to see how it works out, before you push it out too broadly.
    Request/Expect feedback and acknowledge the feedback. Prepare your response ahead of time (predict the typical questions/objections).

    Get the popup/notification to look official - otherwise people might thing it's a fault or a virus. Use the organisation name or logo if you can.


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, June 23, 2016 9:27 PM