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