The Automatic Deployment Rule (ADR) feature in ConfigMgr2012 is quite handy, especially for people moving from WSUS that aren’t too worried about updates being automatically deployed.

Many larger organisations however tend to have a more controlling approach to which updates are approved for deployment and will approve/decline each update as required.

One thing I liked in WSUS was the ability to have updates automatically approved, but being able to set the client policy to say “Notify Only”. On my servers I could have them scan and determine applicable updates, but then I would manually approve them and reboot as required, or I could exclude some updates if they were causing problems on a per-server basis (e.g. .NET). Sure you could do all that through WSUS itself if you wanted to setup lots of different computer groups, but for small environments with half a dozen servers it’s easier this way.

In ConfigMgr2012, there is no way to “auto create” and update group unless you use an ADR. However the ADR configuration makes all deployments Mandatory with a deadline and does not give a “Required” notify only type option.


More of a work-around than a solution, but you can create the ADR for your servers, but just set the deadline to “12 months” (or some other distant date) in the future.


This creates the same notify options, but effectively takes the forced install deadline away. This does of course rely on those updates being installed, superseded, or removed from deployment at some time prior to that deadline date, but 12 months should be plenty of time to get things done.

  1. Ludovic Thissen says:


    As I noticed that two days ago, I’m searching for a solution to this problem.
    I really think that it’s only the interface that is preventing us to do as we want.
    Actually if you try to change te deployment type after the deployment was created, it does the trick.(but we can’t imagine doing this for every adr)
    May be Powershell will be the solution…


    (and sorry for my english :/)

    • Scott says:

      While you could change the deployment after it is created, that defeats the whole point of having an “automatic rule”. That would then require you to not only change the deployment, but you would need to make sure you do each time it is updated by the ADR, otherwise you will suddenly end up with a bunch of “required” updates being installed.

      There might be a way you could create a script that updates the deployment for you. Could probably even use Orchestrator to monitor and change, but there are too many potential failures for that to be a safe option. The ADR will likely keep working, but if the process you use to update the deployment fails, you are back to a sudden required update deployment.

      • Ludovic Thissen says:

        Yes indeed, it’s not a solution at all, but maybe a hint that only the interface prevent you to choose available when you create an ADR.
        I’m not an powershell expert, but as Microsoft is trying to prefer powershell command to the use of the interface. I think there could be a chance that with powershell you could create an ADR with no deadline (just available)

        • Scott says:

          Oh, I understand what you are suggesting now. That’s a really great idea, I might have a look at that to see if there is something exposed in the PS API.

  2. Bill says:

    We do this, and also set an expired Maintenance Window against the Collection to which we deploy. This way, even when the deadline is reached, the Updates will no install so long as you do not allow them to in the ADR. Works like magic 🙂

  3. Les says:

    I know it’s an old post. Seems there is still no solution to this.

    That is clever putting an expired maintenance window on that collection. I guess that will work as long as that system is not in ANY other collections that have valid maintenance windows.

    An issue with deploying to a collection with a far-future deadline is that the updates will start downloading to the system even if you never require to install them.

    • Scott says:

      Updates don’t get downloaded until install time, so seeing a future date won’t cause that problem. I’ve actually started doing the opposite now, setting the window to a time in the past like 1/1/2000.

      With the new versions, being able to set different Windows for updates and application deployments, I have all my collections that handle software update Windows in one place. While there is the potential if someone creates an “applies to all”, it hasn’t been an issue as we don’t tend to use maintenance windows for anything else, and if we do then we set it specifically as an application deployment window.

  4. Les says:

    “Updates don’t get downloaded until install time”…

    My understanding is that if the deployment is Available, it gets downloaded at install time. If it’s Required, it’s deployed via BITS as soon as it’s available on the DP.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s