Configuration Manager Software Application Lifecycle
To better manage application software, Windows operating systems, and associated drivers, the System Center Configuration Manager (SCCM) support staff need for older versions of software to be cleaned up and removed from SCCM.
Let’s start with definitions of “versions”, where “N” represents a specific version of software:
- N = current packaged, deployed production version
- “N – 1” = latest version before current version (one version back/older).
- “N – 2” = two versions back.
- “N + 1” = The “just released” newest version; not packaged and/or not yet widely deployed; in beta testing phase.
Versioned Config Manager user applications:
At the campus NCSU level, the Config Manager software packaging & core teams will maintain the current version and two versions back.
When the N+1 version comes out, then the N-2 version will be retired at the end of the semester at the time the N+1 version is widely deployed.
Near the end of the semester, we will announce the N-2 version retirement, and ask the colleges and departments to migrate any systems that are in the N-2 collections to a newer collection (preferably the N+1 version, but minimally the N and N-1 collections). If departmental units do not migrate their systems to a newer version, the Config Manager team will move the systems to the N+1 collection of the software. After the N-2 collections have been vacated, we will remove the N-2 versioned software from Config Manager.
After the N-2 version is removed, then the versioning representations shifts. N-1 becomes the new N-2, N becomes the new N-1, etc..
Any requests for exceptions should be submitted to the activedirectory_packaging Service Now queue, and will be evaluated on a case-by-case basis.
Auto Config Manager user applications:
NC State University’s Config Manager application deployment strategy uses Active Directory security groups, that are colloquially referred to as “software groups”, to populate the corresponding Config Manager collections. Each application has two deployment methods, required and available, as designated by the lack of or inclusion of “-SS” appended to the group name respectively.
In addition, software groups are designated as versioned or AUTO depending on the way an administrator would like new versions of assigned applications to be installed. AUTO software groups ease a department’s/college’s administrator’s work when it comes to managing an application’s lifecycle for their computers.
For versioned software groups, when a new version of an application is released, a package is created for that version. The application packaging process creates the software groups in Active Directory, the corresponding collections in Config Manager and the collection membership rule that adds the software group members to the collection.
With versioned software groups, when a computer is added to the group, the Config Manager client installs that version of the application. When a new version of the application becomes available and is packaged using a new versioned software group, if an administrator wants to install the new version on the computers they manage, the computers in the old group need to be moved to the group.
When an application is packaged using AUTO software groups, future versions of the application will be packaged and deployed to the already existing AUTO software groups. This means that any computers that are already a member of the application’s AUTO software group will automatically have the old version uninstalled and the new version installed without the administrator having to move all the computers to a new software group.
The lifecycle for AUTO applications at the NCSU level will follow the same lifecycle as versioned applications as defined above where we will maintain the current version and the two previous versions of an application.
Windows Desktop operating systems:
Currently, for Windows 10 Education, there are the fall versions (H2) and the spring versions (H1). The lifecycle of the fall versions are 30 months from release date. The lifecycle of the spring versions are 18 months from release date. It is recommended that the fall version is generally deployed
To keep the campus desktop systems on a supported build of Windows 10, we mandate an annual upgrade. After the deployment of the mandatory upgrade, we will remove all non-LTSC versions of Windows 10. Colleges/departments can maintain their own images that are still under support from Microsoft.
Windows 10 Long-Term Servicing channel (LTSC)
We will maintain an NCSU level LTSC Windows version(s) until Microsoft ends support for them. After Microsoft ends support, we will remove it from Config Manager as an option for installation.
Windows driver packages:
Driver packages are available for most CPI models. For drivers, we will maintain the current versions and one version back.
For non-CPI model systems, or, for those older CPI models that enterprise drivers fall out of support from the vendor, we will attempt to create driver packages for the HBA & NIC (disk controller and network interface), but this is “reasonable effort”. If our efforts fail, then it will be the departmental admin’s responsibility to install Windows from Windows media, or accept the version of Windows preloaded on the system. To domain join a Windows system, it must have either Windows Professional, Enterprise, or Education editions. Windows Home edition cannot be domain joined.
If the system is not on CPI list, long term management may be possible, but problematic.
Zero membership collections:
There are some number of software collections that have zero systems assigned to it that appear to be abandoned. To reduce the total time it takes to evaluate device collection membership, any device collection that has zero members and has not had a membership change (a device added or removed from the collection) in the last six months is considered unused and will be deleted. Any associated Active Directory groups that are used to populate the device collection’s membership will also be deleted.