Prompt users for reboot, but NEVER force it
The reboot settings only allow for the user to postpone a reboot for up to 24 hours. Why can't we expand that time or just keep reminding them forever until they reboot themselves? The longer that they have been pending a reboot, remind (pester) them more frequently. Or auto reboot if nobody is logged on.
This is now available in the 2006 release https://techcommunity.microsoft.com/t5/configuration-manager-blog/update-2006-for-microsoft-endpoint-configuration-manager-current/ba-p/1569562
Its also important to reboot a computer who is logged off. Its an easy task to complete
Its also an idea to check on idletime, so computers whos not used for ex 5 hours can reboot
AdminMark Silvey - ConfigMgr Product Team (Engineering Manager, ConfigMgr, Microsoft Endpoint Configuration Manager) commented
Well, never say never, stay tuned we might have more to share on this one soon.
I thought /noreboot would work, then suddenly systems started rebooting, for me it would be ok to trigger something like CAU in a Failovercluster.
Or does anyone have a good idea on how to solve that?
Also we need to have different options for Software Update Restart and Applications. While we might delay an application restart for longer, the Security Updates we might need to force the user to restart sooner.
William France commented
"IT is not god, policy says no reboots if boss says so and management won't change it - it's a loss of productivity and money."
This says it all and it appears to be falling on deaf ears on the ConfigMgr team.
I support hundreds of attorneys and if I was in anyway involved in forcing a reboot for them under any circumstance, I would lose my job the next day.
I guess people who are in this same boat will be forced to continue to use custom solutions.
Kasper Jensen commented
>While we aren’t doing the NEVER reboot
Sounds like you've made a conscious decision. That's too bad.
To me, it's about flexibility and choice for the individual admin. It's relatively little work for you to remove the timer and let the individual user snooze as many times as they want.
So I guess we'll continue to do our dirty methods of either creating a maintenance window in the past/year 2033 or make a second collection for our "never reboot" machines and have two deployments for everything, where one of them suppresses reboots.
At least third party tools still exist that can give us our "nag prompt". IT is not god, policy says no reboots if boss says so and management won't change it - it's a loss of productivity and money.
Please just give us more choice. TP1906 gave us 20160 minutes (2 weeks), why such an arbitrary number? Just let us type anything in the box and give us a warning if it's over 20160, like your "high risk deployment" warning for task sequence deployments!
Why can the user not schedule a reboot straight in the Restart dialog? Either "Outside my business hours" or a time picker dialog is fine. But only "Restart now" or "Snooze and remind me again in"? Why, seriously? You can say "Outside my business hours" when you have a Required deployment but you haven't hit the deadline yet. See https://docs.microsoft.com/en-us/sccm/apps/plan-design/plan-for-software-center#bkmk_impact.
If you won't do the "never reboot" thing, at least allow users to schedule the reboot themselves. Have a little empathy for those of us who are not allowed to automatically reboot machines.
Cherif BENAMMAR commented
Give user ability to plan restart within a maximum of 24 hours since the first popup and if he didn't set any date then restart ill be done.
Fredrik Rydin commented
I made this tool to do exactly what the description is saying as i had similar need.
Feel free to use it if you want: https://github.com/Fredrik81/Reboot-Dialog
While psappdeploy is great for this, why can't it be handled natively within SCCM?
I would like to see the maximum reboot countdown increased to at least 2 weeks.
We have many academics running long simulations, and a 24hr maximum reboot schedule means we have to suppress reboots always to prevent substantial loss of work.
Nothing happend since 3years. Very annoying!
CAS Computing commented
I don't know if NEVER force is necessary, but it does need to be much more flexible. The 24 hour limit prompted me to write a fairly complicated scripted method (https://github.com/teknowledgist/TeknowTools/tree/master/AutoReboot) using scheduled tasks that won't reboot on a user without their acknowledgement and lots of warning.
Ondrej Seda commented
Hi, i think part of this request should be also: When user do the reboot by himself (clisk start - reboot), SCCM will accept it and will not require reboot after real reboot again.
I created something like this using scheduled tasks and PowerShell.
It was a nightmare and took months. (Lots of scenarios to deal with)
We have a set of scheduled tasks force a reboot on workstations every week (Sleeping or not)
For laptops, we nag the user at logon, screen saver unlock and RDP connection if a reboot hadn't occurred after 2 weeks.
Prior to this we had tonnes of machines that updates wouldn't stick because nobody would reboot. We had 2 guys that hadn't rebooted in over a year!
Our company could also use this feature. We run 24/7 plant operations with a lot of laptop users who turn off at night. While I would love to force the reboots on all users, it is not feasible in this environment. A reboot notification popup every 15 minutes or 30 minutes would be extremely useful (like the one that windows annoys you with for updates). I honestly do not understand why this is difficult as it would simply be another option in that could be in the client settings such as pre deadline notifications.
seb cerazy commented
You should never allow users to make decisions! They do not manage the workstation, YOU DO
Todd Miller commented
I work in a health care environment where we have a lot of shared computers. Think about computers in a patient room or in an exam room. I can't have a decision made by a user 15 minutes ago, who is long gone, affect the next user. So User A says reboot in 15 minutes and then User B gets booted because she happens to be using the computer at the time User A said it was OK to reboot. Once the computer has been scheduled to reboot - it needs to be obvious to anyone using the computer that it is in a reboot pending state, and the user needs to be able to exit or further postpone the reboot pending state potentially indefinitely.
This and the 'SCCM updates: User Experience - Reboot notifications' suggestion should probably be combined. The whole of the user notification and reboot process needs some changes made.
I agree with this. Allow the users to pass on the reboot, but on the 2nd time they do this send an alert to the administrator. This way I.T. knows and can go reboot the computer when the user is out of office, or call them and let them know they will lose network availability unless it is done.
Bill Dunn commented
How about just fixing Windows so Updates rarely if ever require actual reboots, just cycle the proper services. Linux pretty much only needs reboots when you touch the Kernel which isn't often.