Close Menu
    Facebook X (Twitter) Instagram
    Trending
    • Successful Adoption of a “Cloud First” Strategy
    • Speaking at Nordic Virtual Summit
    • Workplace Ninja User Group Denmark February Meetup
    • Workplace Ninja User Group Denmark Meetup – May 2022
    • Workplace Ninja User Group Denmark Meetup – April 2022
    • Speaking at Modern Endpoint Management Summit 2022
    • Speaking at Nordic Virtual Summit 2022 – 3nd Edition
    • CoLabora Recordings – January 2022
    RONNIPEDERSEN.COM
    • Home
    • Enterprise Mobility
      • Configuration Manager
      • Identity and Access
      • Information Protection
      • Intune
    • Cloud and Data Center
      • Data Center Management
      • Group Policy
      • Enterprise Security
      • Hyper-V
      • PowerShell
    • Guides
    • Webcasts
    • Links
    • About
      • Contact me
      • Disclaimer
    RONNIPEDERSEN.COM
    You are at:Home»Enterprise Mobility»Configuration Manager»SCCM 2012: How does Automatic Client Upgrade work?

    SCCM 2012: How does Automatic Client Upgrade work?

    25
    By Ronni Pedersen on August 26, 2014 Configuration Manager, Enterprise Mobility

    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: https://www.ronnipedersen.com/2014/07/configmgr-2012-versionbuild-numbers/

     

    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: https://www.ronnipedersen.com/2013/06/installing-sccm-2012-sp1-cu2-quick-start-guide/

    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.

    image

    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…

    /Enjoy.

    +Ronni Pedersen

    • Tweet
    • Share 0
    • +1
    • LinkedIn 0

    Related

    Ronni Pedersen
    • Website
    • Facebook
    • X (Twitter)
    • LinkedIn

    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.

    Related Posts

    Speaking at Nordic Virtual Summit

    Workplace Ninja User Group Denmark February Meetup

    Speaking at Modern Endpoint Management Summit 2022

    25 Comments

    1. Ken Jones on August 28, 2014 13:18

      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,
      -Ken

      Reply
      • Ronni Pedersen on September 2, 2014 09:53

        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.

        Reply
      • Svoffer on January 9, 2017 12:35

        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.

        Reply
    2. Caio on March 16, 2015 20:34

      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.

      Reply
      • Ronni Pedersen on April 6, 2015 18:41

        To fix the issue log in with the account that installed the primary site server.
        More info: http://blog.coretech.dk/kea/automatic-client-upgrade-greyed-out/

        Reply
    3. Brandon on November 6, 2015 15:38

      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.

      Reply
      • Ronni Pedersen on November 10, 2015 20:46

        Hi Brandon,

        Yes, I do… I’ve used this a many customers without any issues.
        There might be some clients that never get updated, but you can always update them later using the old package method.
        BTW… CU2 was released today. More info here: https://www.ronnipedersen.com/2014/07/configmgr-2012-versionbuild-numbers/

        Reply
    4. David on December 1, 2015 17:17

      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?

      Reply
      • Ronni Pedersen on February 4, 2016 12:55

        Don’t know… but if it’s unsupported, I wont recommend it…

        Reply
    5. David on December 1, 2015 17:30

      Actually, disregard my previous question. I ran across this thread, and saw Jason’s comments along the way. It would be nice to have this feature available, but it looks like CU2, etc will need to continue being deployed after the base client install.

      https://social.technet.microsoft.com/Forums/en-US/9e2d45c4-dd36-47d9-853e-4f94fc12ccd0/best-practise-for-installing-patches-for-sccm-client-2012-both-x86-and-x64-osd-and-client-push

      Reply
    6. Jonathan Weinberg on December 4, 2015 04:57

      Any idea how Auto Upgrade behaves when trying to update EWF enabled Thin Clients (WES 7)?

      Reply
      • Ronni Pedersen on February 4, 2016 12:51

        no 🙂

        Reply
    7. seb on December 5, 2015 07:22

      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!! ”
      http://blogs.technet.com/b/configmgr_geek_speak/archive/2013/09/09/using-configuration-manager-automatic-client-upgrade-to-upgrade-to-the-latest-system-center-endpoint-protection-client.aspx

      + it doesn’t bybass maintenance windows.

      great post & blog, thanks!:)

      Reply
    8. David on December 9, 2015 22:15

      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.

      Reply
      • Ronni Pedersen on February 4, 2016 09:59

        30 days. But it all depends on your requirements.

        Reply
    9. Semen Zhukovskyi on January 14, 2016 16:48

      Hello,

      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!

      Reply
      • Ronni Pedersen on February 4, 2016 09:58

        No. This can only install the CU “update”. The SP1 client is an “upgrade”.

        Reply
    10. Jose Esposito on April 7, 2016 03:03

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

      Reply
    11. Chris on May 24, 2016 02:12

      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!

      Reply
    12. Pingback: What Does The Sccm Client Do | Razeeti5

    13. William on October 26, 2016 22:16

      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?

      Reply
    14. Dave on June 14, 2017 14:44

      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,
      Dave

      Reply
      • Ronni Pedersen on June 14, 2017 14:49

        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 🙂

        Reply
    15. Shyam on May 6, 2020 01:18

      Does the client server ever require a restart after the update takes place?

      Reply
      • Ronni Pedersen on June 25, 2020 12:12

        Yes… Sometime the client upgrade can request a restart.(Exit code 7), but it wont do it Automatic

        Reply
    Leave A Reply Cancel Reply

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

    Follow
    APENTO

    Follow APENTO here:

    Subscribe to Blog via Email

    Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    About
    My name i s Ronni Pedersen and I'm currently working as a Cloud Architect at APENTO in Denmark. My primary focus is Endpoint Management and Security, based on Microsoft technologies. I'm also a Microsoft Certified Trainer and a dual Microsoft MVP in both Security and Windows.
    Recent Posts
    • Successful Adoption of a “Cloud First” Strategy
    • Speaking at Nordic Virtual Summit
    • Workplace Ninja User Group Denmark February Meetup
    • Workplace Ninja User Group Denmark Meetup – May 2022
    • Workplace Ninja User Group Denmark Meetup – April 2022
    Archives
    TOP POSTS
    • Find the TimeZoneName for your SCCM/MDT Deployments
    • SCCM: Failed to Get Client Identity (80004005)
    • SCCM 2012 R2: Where is the SMSTS.log located?
    • Active Directory Based Activation in an multi domain environment
    • Missing “UserType” attribute in Azure AD
    RECENT COMMENTS
    • Sebi on Prepare for Co-Management: Migrate Intune Devices without user affinity
    • Vadim P on SCCM: Failed to Get Client Identity (80004005)
    • TM on Active Directory Based Activation in an multi domain environment
    • unkown on Setting OSDComputerName using CustomSettings.ini
    • TJ Scott on Setting OSDComputerName using CustomSettings.ini
    DISCLAIMER
    The content on this website is presented "as-is" with no guarantees. The use of scripts from this website is at your own risk. Always test before putting something in production! Opinions expressed are my own.
    © 2025 ThemeSphere. Designed by ThemeSphere.

    Type above and press Enter to search. Press Esc to cancel.