Latest posts by David Stein (see all)
- How to deploy a scripted application installation with SCCM 2012 - Mon, Sep 23 2013
- How to deploy an MSI package with SCCM 2012 - Mon, Aug 19 2013
- SCCM 2007 – General client troubleshooting tips - Tue, Aug 6 2013
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)
- 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
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
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
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!
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 ^
- Introduction to Client Deployment in Configuration Manager 2012 (Microsoft)
- How to Install Clients on Linux and UNIX Computers in Configuration Manager (Microsoft)
- How to Install Clients on Mac Computers in Configuration Manager (Microsoft)
- Unattended Ubuntu Linux Installations Made Easy (Linux User & Developer)
- FAI – Fully Automated Installation Project for Linux
- Configuration Manager 2012 Task Sequence Export and Import (Microsoft)