System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

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.

1,081 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Joe shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Noted  · 


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Ondrej Seda commented  ·   ·  Flag as inappropriate

        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.

      • SomeDude commented  ·   ·  Flag as inappropriate

        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!

      • Anonymous commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        You should never allow users to make decisions! They do not manage the workstation, YOU DO

      • Todd Miller commented  ·   ·  Flag as inappropriate

        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.

      • andrewjohnporter commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Simon commented  ·   ·  Flag as inappropriate

        This still is a huge point of contention, we have many customers where the behavior of coming back on the network after a deadline for updates leads to some pretty poor user experience and often CIO-level complaints.

        The notifications leading up to the restart aren't prominent enough, and when it is required they just aren't sufficiently manageable for environments where some users must be able to opt out at critical times

      • Carl commented  ·   ·  Flag as inappropriate

        Any updates on the reboots / more intrusive notifications?

      • Josh commented  ·   ·  Flag as inappropriate

        Throwing in a "Me Too" for my enterprise. ~20,000 workstations.

      • Robert commented  ·   ·  Flag as inappropriate

        Agreed, the level notification is not currently customizable and it needs to be. Specifically for patching and servicing, why can't the sccm admins increase the level of notification. It appears that nothing "really" notifies the user until a deadline is met. It needs to be MORE nagging to ensure that a forced reboot won't make them lose all of their work. It was great back in the PRE-servicing and PRE-win10 - not sure why they turned down the notifications and suspends.

      • Tom Steger commented  ·   ·  Flag as inappropriate

        This is a huge deal for us. No auto-restart with logged on user existed before we switched from WSUS/GP/WPP to SCCM.

        For now, we keep extending the deadline... not a good choice or method.

      • Brachus commented  ·   ·  Flag as inappropriate

        Microsoft - you MUST do something to improve this if you really want customers using the Windows 10 Servicing capabilities of SCCM.

        Enterprise End Users have to be babied and coddled or else there are backlashes against IT.

      • Claus Ilginnis commented  ·   ·  Flag as inappropriate

        I would prefer (of course) something like Linux. Tell user what packages have to be updated and also the reason (security or simple update) then leave it up to 14 days to the user for security updates ( and even longer for others).
        Because forcing something is alway a bad idea - better improve the way to schedule a nightly update.

      • Roberto Franke commented  ·   ·  Flag as inappropriate

        I also would prefer the "Spam" method mentioned by Steffen Weik. Or at least there should be a possibility to postpone a reboot for up to 72 hours. Maybe with an additional "work in progress" switch. So in case a reboot is required it would automatically be postponed for a configured duration. So it's possible to start a long running test on Friday evening and receive the results on Monday morning without being afraid your test-results are gone because of an unexpected reboot.

      ← Previous 1

      Feedback and Knowledge Base