ConfigMgr 2012 - How to automatically make updates available to computers without forcing them to be installed?

Question

I'm using System Center Configuration Manager 2012 with the Software Update Point feature; however, in this environment patching has to be strictly manual, because server reboots need to be approved and scheduled by different people; thus, I need to use ConfigMgr's SUP like I would use a plain WSUS server with auto-approval but with manual installation.

I created some Automatic Deployment Rules to automatically download and deploy critical updates, and to have an installation dealine of "as soon as possible"; but then, I've also configured those rules to not do anything when the deadline is reached, and to not perform system restarts even if needed:

Also, I've configured the device collections to where those rules deploy updates to not have any valid maintencance window.

However, I'm experiencing quite the opposite of what I was expecting: as soon as the new updates are processed by the ADRs, they get automatically installed on all systems by the Software Center, and the computers are subsequently restarted.

Why is this happening? Am I getting something wrong or is just ConfigMgr 2012 not behaving like it should?

Answer 1

I know this question is a bit old, but there's some untruths being posted here. There is nothing wrong with how SCCM 2012 functions, the problem is a misunderstanding of how it deploys software and updates. It is not fair to quote Microsoft when they say it was behaving "by design" and that you cannot do anything but set a deadline far into the future. This actually IS by design, but based on YOUR design. You didn't set maintenance windows, so of course the updates will apply as soon as the deadline hits. That's what it does by default. In that type of design, you must set your deadline far into the future to avoid the installation starting. However, that's NOT the only way to do what you want, nor is it the simplest.

Did you know you can reverse SCCM's default behavior of "anything goes unless told otherwise"?

To do this, create a new collection (named anything that makes sense, like "Deploy Manually") and include the "All Systems" collection in its membership. Then get Properties on it, and set a Maintenance Window using any effective date in the past, like 01/01/2013 from 12:00am to 12:05am, and set the recurrence schedule to None. You will get a warning about recurrence not being set, but click OK anyway. From that point forward, every device in your SCCM environment will automatically have an expired Maintenance Window set on it, and can no longer install anything without a new Maintenance Window, or by checking the override maintenance window box when making a deployment. This is the opposite of its previous behavior, because it will now run no installs or updates until explicitly told.

This is very powerful, but the caveat is that you now have full manual control over when installs can run and when reboots can take place -- just like you wanted. Now those checkboxes have a meaning. For example, if you have auto deployment rules, like Endpoint Protection Definitions, you need to make sure they can install outside of maintenance windows unless you enjoy logging into servers every day to apply them. You have the option to suppress reboots even if an install is allowed to run outside maintenance windows. One benefit is that you can easily deploy anything and simply use "As soon as possible" when choose assignments and deadlines for manual installs, and if you're clever about maintenance window setups, you can deploy patches once, but schedule the actual install and reboot by using other collections with new maintenance windows. Remember, maintenance windows are cumulative across all collections, so design your environment accordingly.

Answer 2

Have you tried setting the deadline to ridiculously long into the future?

That's how I handle advertisements to my servers in SCCM 2008. I set the deadline for 1 year from the date I roll out the advertisements to the servers. Nice and convenient, since when the patching window rolls around, all the updates are there, waiting to be installed, but won't kick off without manual intervention. Also requires less effort on my part than mucking around in those settings you're trying to get to work as expected.

Answer 3

Why not just make your deployment "available" rather than "required"? That way the updates will appear in Software Center but not automatically install.

Also, maintenance windows apply to the Client, not to the Collection.

"An additional gotcha is that if a machine is a member of more than one collection that have Deployments targeted to them, and one of those collections does not have a maintenance window defined, the maintenance windows of the other collections are effectively ignored."

Actually the maintenance window of the CLIENT will be the sum of whatever maintenance windows are applied to it. So if you have a one-hour maintenance window applied through membership in one collection, and the client is also a member of a collection with NO maintenance window defined, your effective maintenance window is one hour.

Answer 4

Assuming that SCCM 2012 behaves like SCCM 2007, the absence of a maintenance window means that the machines in that collection will install updates whenever they feel like it (at or after the deadline), as you have found.

Personally what I do is to have collections based on AD security group membership. Servers that are members of the Tuesday Maintenance group, for example, become members of the Tuesday Maintenance collection and (surprise) are updated on a Tuesday evening.

Servers that cannot be rebooted on a weekly basis are kept in a collection that has no Update Deployments targeted at it, and so they never download or apply any updates except for Definition Updates.

On the occasions when I am able to update these critical servers, I just temporarily add them to an AD security group that is targeted by a collection that has a suitable maintenance window - or just create a new one in advance.

Not sure if this approach will be what you're looking for, but perhaps might give you some ideas.

Answer 5

You seem to have the wrong answer selected. The check boxes you have circled in your graphic clearly only apply to Machines that have a maintenance window defined. It plainly says as much in the line of text above the check boxes. In SCCM, if no maintenance window is assigned, it is assumed that it's ok to maintain that server any old time. Which makes perfect sense. If you'd like those check boxes to apply to your deployments, then you need to set a maintenance window. If you set one in the past, and specify no recurrence then the maintenance window has expired for everything in that collection and there will never be another maintenance window for it. In this scenario, the only way they can be installed now, is if you do it manually.

Caveat: This is only true if those machines are not in any other collections with recurring maintenance windows. In that scenario, this maintenance window is ignored since it is expired, and the other will be observed since they are cumulative.

Seems pretty straight forward to me. And yes, the behavior is by design.. You just designed your deployment wrong. :)

Your mistake was in assuming that since no maintenance window is defined, it's NEVER ok to install those patches, when exactly the opposite is true. The reason for this is that people need to be able to install patches and software, and make changes to systems whether or not a maintenance window is defined. (think highly reboot tolerant machines like workstations.) For these systems the extra step of defining maintenance windows is cumbersome, and can cause problems with software distribution, etc., due to overlap of policies, etc. This way allows to you keep the number of maintenance windows to a minimum, and hence easy to manage and predict what the behavior will be for your deployment.

As you have it set in your image.. If you had a maintenance window set in the past, with no recurrence, you would have exactly the behavior that you wanted. :)

All of this being said.. Now if you throw the various group policy settings that govern automatic updates into the mix, it can be very confusing. Microsoft could simplify the interface for software updates quite a bit, or add some explanations to the settings that exist. That goes for SCCM 2007 as well.

Answer 6

It gets worse. In my experience with ongoing deployment of patches to try to enforce compliance, and it can be a real problem. Here's why. Policies are generally assigned to clients by virtue of the collection they are in. Collections are updated periodically, but not all at the same time. Now imagine the scenario where you install the client on a server, knowing that the client install will not require a reboot.

The server will eventually reside in a collection with a Maintenance Window, and a collection with an ongoing deployment of critical patches. But it just so happens that the timeline that happens to unfold is this, the collection with the deployment gets updated first, then the client happens to hit its' Policy Retrieval Evaluation Cycle interval, before the Collection with the Maintenance Window assigned to it is updated. The result can be the server applying patches and rebooting at an inappropriate time.

Unfortunately, we cannot assign a maintenance Window to the, "All Systems", Collection, to create a default maintenance Window. Part of my solution to this problem conceived so far is to mirror the, "All Systems", collection with a collection that has it as an Included Collection, set updates on that collection hyper frequently, and assign a Maintenance Window to that. And while we may want to continue to have ongoing deployments of critical patches for desktops, we might want to expire them for servers, or at least change them from Required to Available after our main maintenance push.

I also like the idea of applying a non-recurring Maintenance Window in the past.

Answer 7

It appears this might be a known bug in SCCM. I can't, however, find any MS documentation, but @ least the OP knows the problem doesn't lie in his setup.

Answer 8

Im actually in the process of updating servers for the first time using SCCM.

Assuming that SCCM 2012 behaves like SCCM 2007, the absence of a maintenance window means that the machines in that collection will install updates whenever they feel like it (at or after the deadline), as you have found.

I too have found this to be the case. You have to assign maintenance windows or the updates will apply whenever they feel like it.

As for server updates, what I have been doing is deploying updates as available to servers but then logging in and manually applying them (after taking a snapshot of the machine if it is a VM).

What would be nice however is an "install all updates during the next maintenance window, rebooting if necessary" button so that I can initiate this process during the day then get up early and make sure I don't have to roll the snapshot back.

Answer 9

Lots of confusing half-truth answers here. Those settings you've circled only apply if a machine has a maintenance window applied. If you want your systems to never reboot unless you initiate it, then you should make a maintenance window either far in the future, or one far in the past.

Without a maintenance Window, SCCM will allow a system to restart after installing updates. The way to block that behavior is under SCCM Client Settings, found under Administration -> Client Settings.