Configuration Manager 2012 SP1 – Part 4: Upgrading clients

In Part 1 of this series, we covered the preparation for upgrading your SCCM 2012 site hierarchy to SP1. In Parts 2 and 3, we covered the upgrade of Primary and Secondary sites, respectively. In Part 4, we will continue on with upgrading the SCCM 2012 Clients to SP1 and explore some of the options available to you to help automate the process.

David Stein By David Stein - Tue, March 12, 2013 - 3 comments google+ icon

David is an author and consultant, working for Endurance IT Services in Virginia Beach, Virginia, specializing in Microsoft enterprise systems and Business Process Automation.

Articles in this series

Configuration Manager (SCCM) 2012 SP1 upgrade

How many ways?

As with almost anything in the technology world today, there are multiple ways to accomplish a big task like upgrading dozens, hundreds or thousands of SCCM 2012 clients. Thankfully, Microsoft has listened and done an outstanding job of helping us out with some improvements.

As with a new Client deployment “roll-out”, you have the same tools available for deploying the SP1 updated Client:

  • Application Deployment
  • Package Advertisement
  • Client Push Installation
  • Compliance Settings
  • Software Updates
  • Remote Control
  • Group Policy Software
  • Operating System Deployment (OSD)
  • Scripting
  • Interactive
  • Automatic Client Upgrade

There are obviously pros and cons to each option, but it always depends upon your particular circumstances as to which option(s) may work best for you. My personal favorite is the much-improved Automatic Client Upgrade feature, but even it has some limitations.

Automatic Client upgrade

You may be familiar with this feature in the RTM version of SCCM 2012, but it has been improved in SP1, making it more reliable and dependable.

To enable and configure this feature, navigate to the Administration section of the management console, and drill down into Site Configuration / Sites and click on the CAS or Primary Site you wish to configure. Click on “Hierarchy Settings” in the Ribbon menu along the top to open the Site Settings Properties dialog form.

Select the Automatic Client Upgrade tab. Once you check the option Upgrade client automatically when new client updates are available, a warning box will appear to confirm you really wish to continue (see screenshot below). To proceed, click the OK button. You can now configure the options for enabling automatic client upgrades.

Enable Automatic Client Upgrade

Enable Automatic Client Upgrade

There are two (2) options available for configuring the automatic client updates:

Automatically upgrade clients within (x) days and Automatically distribute client installation packages to distribution points that are enabled for prestaged content.

The first option helps to constrain the total time window you wish to allow for all of your site clients to be upgraded. Allowing more time for upgrades will spread the process out, reducing the potential traffic overhead on your network links. The trade-off is, of course, taking longer to get all of your clients upgraded. If network link traffic is a sensitive matter in your environment, I would suggest testing this in a lab environment first and taking time to assess the traffic impact to help you decide whether to adjust the number of days to provide the most benefit and least overhead.

Limitations of Automatic Client Upgrades

Before you do anything, I strongly recommend that you read the section in the middle of this form!

Limitations of Automatic Client Upgrades

Limitations of Automatic Client Upgrades

With the information-overload problems Administrators deal with today, it seems to me like these three bullets should have a bold, red outline around it to make it stand out more. While they seem clear enough, I feel I should elaborate a little on what these really mean:

These settings apply to all clients in the hierarchy.

If you are managing a standalone Primary Site, every client in that site, as well as subordinate Secondary Sites, will be impacted (upgraded). If you are managing a CAS, then this will impact every client in all of the Primary Sites and Secondary Sites beneath it. Both of these conditions come with the caveats described below.

Automatic client upgrades will not be installed until clients are assigned to a site that is the same version as the top-level site in the hierarchy.

The automatic client upgrade process is based upon a system in which clients check their own version against the Site of which they are assigned. If the Site Server has a newer version of the client available, the client requests an upgrade in order to bring itself up to the same version. The Client installer is then downloaded and executed to perform the upgrade. If a Client is assigned to a Site which has not yet been upgraded to Service Pack 1, it won’t be upgraded. This can be confusing if you are managing multiple Sites which are not part of the same hierarchy.

Clients in slow or unreliable boundaries will not be upgraded automatically.

This is potentially one of the biggest caveats to be aware of, depending upon your environment. If you have clients on slow or unreliable links you cannot rely upon this feature to handle automatic upgrades for the clients in those sites. In such cases, you will have to use one of the other methods mentioned earlier to perform the upgrades.

Applied to Windows operating systems only.

Personally, I feel this should say “Applies to” rather than “Applied to” but anyhow, this is fairly self-explanatory. If you are managing Mac (OSX), Linux or other operating systems within your Configuration Manager environment, you will need to use one of the other client deployment methods to upgrade their Clients:

  • Interactive Script (./install)
  • Automation Scripting (Login or Startup, RedHat Kickstart, etc.)
  • OS Provisioning (Kickstart, FAI)

Applied to Windows operating systems only

Applied to Windows operating systems only

The link provided at the bottom of the Site Settings Properties form takes you to the Microsoft Download with links to various operating system clients, including OSX, RedHat Linux (RHEL), Suse Linux (SLES), and Solaris (UNIX).

Wrapping up

I hope this series of articles has been helpful to you? It’s impossible to cover every possible scenario for every environment, but I tried to focus on what seems to be the most common scenario: A single Primary Site, with a possible Secondary Site, and the Clients to upgrade on the tail end. I would appreciate your feedback on this, so please post comments and questions below? Thank you!

Acknowledgements

I want to thank to of my colleagues at Endurance IT Services, Chris DeCarlo and Justin Chalfant, for generously offering to help with comments, corrections and suggestions throughout this series.

More Resources

Series NavigationConfiguration Manager 2012 SP1 – Part 3: Upgrading Secondary Sites -

-1+1 - Rate this post
Loading ... Loading ...
Disclaimer
Your question wasn't answered? Please ask in the new 4sysops forum!

3 Comments- Leave a Reply

  1. Alex says:

    David, is updating the SCCM clients post SP1 required for functionality or can it be done later on ?
    Thanks

  2. BramV says:

    Thanks David, your SCCM upgrade guides have been very helpful.

  3. David M. Stein says:

    Alex, I apologize for taking so long to reply. I didn’t see this until just now when I got an email alert for BramV’s comment. Anyhow, you can upgrade the clients from 2012 to 2012-SP1 whenever you want, but yes, some functionality won’t be available until you do. If you read the “What’s New in Configuration Manager 2012 SP1″ it spells out some of the new features.

    BramV: Thank you very much! I really appreciate that!

    Dave

Please share your thoughts in a comment!

Login

Lost your password?