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?

Solution 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.

Solution 2

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.

Solution 3

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.

Solution 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.

Solution 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.

View more solutions

Comments

[Massimo]

I indeed already thought of this, and it would probably work (except in some crazy scenario where a computer doesn't get patched for a ridiculously long time... which, however crazy, is well known to happen).

[Massimo]

But I'd anyway be a lot more confident on the product if it actually did what I told it to do, i.e. not apply patches when the deadline is reached.

[HopelessN00b]

@Massimo Yeah, no arguments from me on that. Just sharing what helped me work around that mess. Of course, if one year's not long enough, there's always that oldie song. In the year 2525... I'll be dead, and it can be someone else's problem if the server running a 500-year old OS reboots.

[Massimo]

No, this is not what I'm looking for. I need the equivalent behaviour of setting Automatic Updates to "check for updates but let me choose whether to download and install them" (or "download updates but let me choose whether to install them"). I need whichever people in charge of a given server to be reminded he has to install updates as soon as he can, but not be forced to do it unitil he's ready to actually reboot the machine.

[Massimo]

I know this can easily done with WSUS (or even plain Windows Update); but having SCCM deployed in the environment, using stand-alone WSUS just feels quite wrong.

[Massimo]

And no, when SCCM manages a WSUS server, it does not approve updates on it, it only uses it as an update database; thus, if a managed computer actually checks for updates using Windows Update, it doesn't find anything available; only the Software Center sees there's something to be installed.

[Chris McKeown]

Yep, very true. I have Definition Updates set to auto approve in WSUS so that they don't need manually deploying from SCCM. Not sure if this has changed in 2012 but in 2007 this was the recommended way to do it

[Massimo]

Confirmed by Microsoft support the product behaves this way by design, and the only solution even they could think of was the same you suggested.

[Massimo]

BTW, the customer thought this is absolutely crazy and ended up going back to WSUS. I couldn't agree more.

[Massimo]

So, the scenario you describe (expired and no recurring maintenance window, required updates, no automatic action when deadline is reached) would satisfy my requirements (no automatic update installation, logged on users reminded that updates should be installed)?