SCCM 2012: How does Automatic Client Upgrade work?


Some of the questions that often comes up on the Microsoft TechNet forum, are from people that don’t understand why the Automatic Client Upgrade feature don’t behave as they expect. In this blog post I’ll try to explain how this feature was designed, and in what scenarios you can use this feature.

Cumulative Updates

One of the most common misconceptions is the checkbox that says “Upgrade client automatically when new client updates are available”, and I don’t blame them. It is confusing.

The reason for this confusion are the two words “Upgrade” and “Update”, so let’s have a closer look to the meaning of these two little words.

When a client needs to be “Upgraded” it means that we’re installing a new build number of the product. That only happens in the following scenarios:

  • Upgrading from ConfigMgr 2012 RTM (7711) to ConfigMgr 2012 SP1 (7804).
  • Upgrading from ConfigMgr 2012 SP1 (7804) to ConfigMgr 2012 R2 (7958).

Note: This feature does not work at all in the RTM version, but after SP1 it actually does work.

Cumulative updates are however not considered an “Upgrade”. They are much smaller, and is therefore just an “Update”.

More information on build and version numbers can be found here:


So what does this mean?

It means that automatic client “Upgrade” will NOT automatically apply cumulative “Updates” to your clients! You must use the packages created by the CU installation process to update your clients.

Here is a quick start guide that will help you install a CU update on the Primary Site Server and afterwards “Update” your clients:

OK. But how does the client upgrade feature work then?

The process of enabling this feature is pretty simple. To enable the Automatic Client Upgrade process,  you need to navigate to \Administration\Overview\Site Configuration\Sites\, and click Hiersrchy Settings in the ribbon. Select the Automatic Client Upgrade tab.

When you enable this feature, you also have the option to configure another important option that allows you to specify the timeframe which the client should be upgraded.


Pretty simple. But we still need to know exactly how it’s working to fully understand and troubleshoot this feature, when something isn’t working as expected.

So how does this work?

After this feature has been enabled, and the numbers of days are specified (in this example I’ve configured it for the default 7 days), a new policy for each client with a lower build number are created. When that policy is retrieved by the ConfigMgr Client, the Upgrade task are created.

The upgrade task are created a simple windows scheduled task, with a random runtime. In this scenario it will be somewhere between 1 and 7 days. This is designed so the upgrade process won’t happen on all clients at the same time.

When the scheduled task kicks off, the upgrade process are started (by running ccmsetup.exe), and the scheduled task will be deleted automatically.

Real World Note: Clients in slow or unreliable boundaries, are not upgraded automatically.

That’s it…


+Ronni Pedersen

About Author

My name is Ronni Pedersen and I'm currently working as a Cloud Architect at APENTO in Denmark. My primary focus is Enterprise Client Management solutions, based on technologies like AzureAD, Intune, EMS and System Center Configuration Manager. I'm is also a Microsoft Certified Trainer and Microsoft MVP in Enterprise Mobility.


  1. Great post Ronnie as usual! Two question:
    1. Would this “update” discovered AD objects without a client?
    2. Would this “update” ConfigMgr 2007 clients during a migration?
    Thank you,

    • 1. No. It can only be used to upgrade existing clients. (it needs to get the policy)
      2. Great question.No sure. Havent tested it. My guess is that it would Work, but I’ve never tested that specific scenario.

    • As an answer for Ken Jones’ question #2:  “Would this “update” ConfigMgr 2007 clients during a migration?”
      I have tried it a few times, so I can verify that it will upgrade from previous versions.
      I have done it from 2007 to Current Branch, 1610.

  2. Hello, this option isn’t avaliable for me, please do you have any idea? I read some link’s but I till can’t enable this option.Thanks.

  3. Hello,

    Do you think the auto client upgrade feature is suitable/safe to use on 2000 client machines.
    I’m thinking about setting the upgrade time feature to 90 days.

  4. Thank you Ronni! This is very concise and helpful.

    I heard there is an “unsupported” way of modifying the client installation to automatically include updates as long as they reside in the same (source) folder where the client.msi resides. It sounds like a smoother way to handle client installs for new machines and client reinstalls. But is this true? And is it reliable?

  5. hi,
    I was reading your article and had some questions, but after a few searches I got my answers, thought I should share:
    apparently it does work with cumulative update from r2 sp1 CU1 ” after upgrading to R2 SP1 with CU1, automatic client upgrades will also install cumulative updates!! ”

    + it doesn’t bybass maintenance windows.

    great post & blog, thanks!:)

  6. What would you recommend setting the upgrade feature days to for approximately 20,000 computers?
    A good portion of these computers are mainly connecting via wireless too.

  7. Semen Zhukovskyi on


    Can you answer me for one question? 🙂
    Currently I have SCCM 2012 R2 CU3 environment. I use GPO with scheduled task with powershell script for installing SCCM client 5.00.7958.1000 build (native R2 client without CU) + old package method for installing CU3 for clients.
    It was done in that way due to migration from SMS 2003 to SCCM 2012 R2
    Right now I don’t have any SMS 2003 clients.
    I don’t use client push installation method. (Account not specified under SCCM Client Push tab)
    I need install SCCM 2012 R2 SP1 and update clients, can I use Automatic Client Upgrade feature without Client Push account?

    Thank you!

  8. just an FYI theres a typo in your post.

    “Hiersrchy Settings”

    …..navigate to AdministrationOverviewSite ConfigurationSites, and click Hiersrchy Settings in the ribbon. Select the Automatic Client Upgrade tab…..

  9. Hi Ronni (or anyone else that has had experience with the Automatic Update Feature),

    I had a few questions:

    1. From your experience, does the client upgrade process require a reboot? From what I read, it doesn’t appear so, but any additional confirmation would ease my concern.

    2. I would imagine that since “upgrade” is in the name of the feature, the feature doesn’t perform a fresh client installation on existing machines detected in the targeted collection. Is this correct?

    3. Would you happen to know what specific collection is targeted when this feature is used?

    Thank you for the post and for the additional help!

  10. Pingback: What Does The Sccm Client Do | Razeeti5

  11. Hello,

    I Realize I am about to type a whole bunch of info and more than a few questions so I appreciate whatever info you can share and may not answer to all. THANKS in advance.

    We just upgraded from 2012 R2 to Current Branch 1602 and are planning to use this feature to upgrade the clients.
    Are you able to describe how this process actually works? what is created and happens (both visibly and not)?

    After upgrading the servers and enabling the upgrade for the pre-production collection I notice my pilot machines were not upgrading. I observed two traditional packages had been created (no program or deployment) but only non pre-staged DPs would successfully receive the content. Even though “Specify the behavior that you want to occur…….” was set to “Automatically download content when packages are assigned…….”.
    I tried updating the DPs….no joy in Mudsville.
    I didn’t want to mess with the auto-created packages so I manually created a duplicate of the “Configuration Manager Client Piloting Upgrade Package” and before I had really spent much time troubleshooting the original package had finished updating all DPs. I don’t think this was a matter of patience because it had been a few days since I had done the upgrade.
    So with DPs updating and some workstations starting to show client upgrades, I deleted the duplicate package I had created.
    This is where it got weird. The 2 auto-created packages also disappeared from the package node but they are still visible in the content node of the monitoring workspace.

    So the questions I am left with are….
    1. how does this process actually work?
    2. what is created (i.e. the 2 packages)?
    3. why do the packages not have/need a program or a deployment?
    4. what might have caused the 2 packages to disappear (only from the package node as well?) when I deleted the duplicate which I had created?
    5. why would MS use a package instead of an application model?

  12. Hi Ronni,

    Great post! My question is after applying the CU what changes do I need to make to my OS deployment to push out the new client on a fresh install?

    Thank you,

    • Its been a long time since I’ve done that! 🙂
      It can be done by updating the client installation part of the task sequence by adding the the patch parameters.
      But instead I’d highly recommend to move on and upgrade to current branch. It’s really not a complicated task 🙂

Leave A Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.