By brinkMay 21, in Configuration Manager I feel like I keep posting questions. I tried to do a search on this but everything was bringing me to the exact opposite of what I am trying to do.
It seems that even though I have maintenance window set for 18 hours on a collection every day for my testing. The machines install the updates but the user's are prompted to restart instead of just restarting the computers.
When deploying the software group you essentially have to check the same fields otherwise it may not work. I cant seem to figure out why you have to do this twice it seems like wasted work to have to perform this step twice for an Automatic Deployment Rules.
You can post now and register later. If you have an account, sign in now to post with your account. Paste as plain text instead. Only 75 emoji are allowed.
Display as a link instead. Clear editor. Upload or insert images from URL. Configuration Manager Search In. Force Computers to Restart after Install Software Updates By brinkMay 21, in Configuration Manager restart clients sccm force computers software updates.
Recommended Posts. Report post. Posted May 21, Share this post Link to post Share on other sites. The problem is 2 things need to be set correctly. Posted September 25, OK, let me try your Solutions, i will keep you posted.
Thank you. Posted September 26, Join the conversation You can post now and register later. Reply to this topic Go To Topic Listing. Sign In Sign Up.This rule alows system restarts and Software Update Installations outside the maintenance window once the deadline passes. We are encountering a situation where reboots don't get forced after the deadline passes. We want users to have some control over this by allowing them to set up their setting via the Software Update Center they get when the deployment rule runs each month.
However, if they ignore it, we do want forced reboots after the deadline. Thanks for checking in Jeff! I currently have our device settings to be 90 for Display a temp notification and 15 for display a dialog box. Would changing this force the reboots after the deadline is over? The goal is to allow user control until the deadline and then the machines are rebooted anyway. Yes it would, that's why we have it set in that fashion cause you don't want a exec in the middle of budgets to lose data or in the middle of a presentation.
I'm just sorta confused on that. Aren't these just time interval settings for notifications? I'm just wondering how that would enable a force reboot only after the deadline is over.
The deadline is the deadline i. Firstly check under the user experience of the deployment that "software updates" and "system restart" are ticked.
Are the updates being installed after the deadline and it is just the reboot that is missingor are the updates not installing at all? The actual behavior past the deadline is that there are no reboots unless the user allows it through the Software Center. Updates that don't need reboots do get installed. The goal is to allow the users to control when the machines reboot until a deadline has passed and then it forces the reboot outside of work hours after 5 PM and before 8 AM.
OK, so they only way I can think of this is to setup a duplicate ADR, but have deployment set to required, the available and the deadline set to the same time which matches the original ADR deadline and have this ADR deployment configured to do a system restart if required.
That way it will try to install the patches, find they are already installed, then start the system restart process ,bases on the client settings as Jeff has shown above. So there isn't a way to force a reboot after a certain period of time unless I create a second ADR? If I set it to be the same times as the original ADR, wouldn't there be potentially a conflict where the second ADR files all of the updates first and then forces the reboot?
So I take it that the second rule is the way to go? Not sure why SCCM wouldn't give me enough leeway to suppress reboots for a limited amount of time in one rule though. The concept of available, and then required at the deadline, means people can choose to carry out the installation and restart if required.
When it is available, they deliberately choose to patch knowing that a reboot will happen if required. Unfortunately you are allowing people to patch without rebooting, which is not a preferred option. The reality is that the patches are not always installed and are generally staged, meaning you are still susceptible to the security exploits that the patches provide protection from.
So it looks like the forced reboot action on a separate deployment rule does work. However, the user never got a prompt that a force reboot was going to happen.This week I will do a small post about working with the restart behavior of installations in combination with the Application Model in ConfigMgr In previous versions there was sometimes a need to use a batch file to catch some weird installation return codes.
The nice thing about ConfigMgr is that it gives us a possibility to specify those return codes and to react on it. In the rest of this post I will show in three steps how to configure ConfigMgr to work with return restart codes. The first thing I always do is running the installation of an application a few times and see which return codes it gives me.
Based on those experiences I create, if needed, some extra entries in the Return Codes —tab of the Properties of the Deployment Type. By default the following return codes are pre-defined:.
The second thing I do is determining how I think the client should react on the return codes. The following options are available including small explanation :.
The third, and last, thing I do is more a general client setting. From the moment we decide to restart the device we should think about the configuration of the Computer Restart —settings in the Client Settings.
The following Device Settings can be configured:. The combination of these three steps gives us a lot of options to work with the restart behavior of installations. In most cases the default configuration is perfect, but in some case some tuning is needed. For example, the installation of an application is not allowed at any time.
This can be achieved by either configuring a custom return code in the first step, or by specifying No specific action in the second step. The task sequence will respond to the exit code of the installation. If the exit code indicates a reboot, the task sequence will reboot.
Does this mean that No specific action merely tells ConfigMgr to ignore a restart request by an application installer, or does it have some kind of super-power whereby it can suppress ANY attempt by an application to reboot the system? The note above would seem to indicate that it has the supreme power of suppression, but I think it may be just be inaccurately worded. It really means what it states.
You can change the reaction of the client to a return code of an installer and that includes the reaction to for example a message of the installer. To clarify, can it suppress an installer from rebooting a machine?
Say, for example, a command line of shutdown -r -t 0? Would it block that? No, ConfigMgr can not block every reboot. The only thing it can do is react on exit codes of installers and command lines that are started via the ConfigMgr client.
Hi, I have a vbscript as a program.It is common to both installation and uninstallation. What about if I need a reboot in installation and a logoff or nothing at uninstall? The return codes are shared between installs and uninstalls. As for customizing the behavior, it would depend on the application setup and its return codes but you cannot specify different actions for the same return code. For example, if the setup returns 0 for install and 0 for uninstall, you cannot set post-install action as a restart and post-uninstall action to do nothing for the 0 return code.
You can maybe wrap one of those actions the install for example in a wrapper which detects the 0 exit code and then you customize the return code in that wrapper to a different one and specify an action such as restart for that customized return code. Are they case when you need a hard reboot. Now with Windows 8. I have a program who I can control during the setup the reboot. So I will need to exit my script with But the uninstaller do not control the reboot.
So I believe the OS will reboot without control. Will SCCM view this as a failure or a success? Just so we're clear on the definition of those terms, a hard reboot is not like resetting the system. Soft reboot means that the installer requested a reboot but the CM client is free to install other applications if any. A hard reboot means that the installer requested a reboot and nothing else can be installed until the system restarts. There are usage scenarios for both.
Can you elaborate a bit? What do you mean by "the uninstaller do not control the reboot". Usually after a software uninstall there would be a popup asking to reboot or in quiet mode the software will do Nothing.
Manage device restarts after updates
I am new to SCCM and our previous patching solution had a dummy patch that got applied at the end of patching which initiated a reboot whether required or not by the monthly patches we applied.
We are transitioning to SCCM now for patching. Does anyone know of a method that will automatically reboot the client machine after any round of patches?
Prajwal Desai Forum Owner Staff member.
Tech Talk Live Blog
You can do that using maintenance window in SCCM. Prajwal Desai said:. Edy Well-Known Member. In your ADR deployment settings, if you check the the System Restart if necessary box in the Deadline behavior then it will fix your issue?
Working with the restart behavior of Applications in ConfigMgr 2012
You can use Group Policy settings, mobile device management MDM or Registry not recommended to configure when devices will restart after a Windows 10 update is installed. You can schedule update installation and set policies for restart, configure active hours for when restarts will not occur, or you can do both.
In Group Policy, within Configure Automatic Updatesyou can configure a forced restart after a specified installation time. To set the time, you need to go to Configure Automatic Updatesselect option 4 - Auto download and schedule the installand then enter a time in the Scheduled install time dropdown. Always automatically restart at the scheduled time forces a restart after the specified installation time and lets you configure a timer to warn a signed-in user that a restart is going to occur.
While not recommended, the same result can be achieved through Registry. For a detailed description of these registry keys, see Registry keys used to manage restart. When Configure Automatic Updates is enabled in Group Policy, you can enable one of the following additional policies to delay an automatic reboot after update installation:.
Devices that do not have locally logged on users, or active RDP sessions, will be restarted. You can also use Registry, to prevent automatic restarts when a user is signed in. As with Group Policy, if a user schedules the restart in the update notification, it will override this setting.
Active hours identify the period of time when you expect the device to be in use. Automatic restarts after an update will occur outside of the active hours.
Users can change the active hours manually. Starting with Windows 10, versionyou can also specify the max active hours range. The specified range will be counted from the active hours start time. When the policy is enabled, you can set the start and end times for active hours.
This method is not recommended, and should only be used when neither Group Policy or MDM are available. Any settings configured through Registry may conflict with any existing configuration that uses any of the methods mentioned above. You should set a combination of the following registry values, in order to configure active hours.Servers are easy to keep up to date as they are always powered on, and we have maintenance windows set on a regular schedule so that they can reboot after updates are installed.
User computers present additional challenges since in our environment they are mostly laptops that are taken home and are not powered on after hours. Out of the box SCCM gives us a few options when deploying updates. There is not a clear option as to which is best as each has pros and cons:. As you can see there is not always a clear answer for which option is best.
For our scenario, mostly laptops taken home, we tried the first two options. Ok, so given that we tried the first two scenarios and were not going to try the third where did that leave us? This is one of those areas. Kent spoke of a tool that Coretech developed called Shutdown Tool download link here. This tool creates a pop up that forces a reboot of the computer after a given amount of time. The great part is that a user is allowed to postpone the reboot until the time period you give is elapsed.
This gives us greater flexibility than SCCM, which will force the reboot whether the user is ready or not. This combination will ensure that the computer stays up to date without our constant intervention or relying on a user. So how can we pitch to management the need to force users to reboot every week? Thankfully, SCCM already has the necessary information stored, although not in a canned report. I created a report, based on the following query, which displayed all the computers that had not rebooted within the last seven 7 days.
Name0, dbo. One of our main goals at Tech Talk Live is to build a community. It is our hope that this blog can be a forum for discussion around our content. We see commenting as an integral part of this community. It allows everyone to participate, contribute, connect, and share relevant personal experience that adds value to the conversation. Respect counts. We believe you can disagree without being disagreeable. Comments should keep to the topic at hand, and not be promotional or commercial in nature.
Please do not link to personal blog posts, websites, or social media accounts that are irrelevant to the conversation.