For most companies, Configuration Manager is becoming a mission critical service the requires less and less downtime. Upgrading large environments/DBs can take up to 5 hours for the CAS, and 4-5 hours for primary sites. Also, most customers want to get the latest hotfixes installed right after performing an upgrade. In some cases, the hotfixes take just a long to complete as the original upgrade. Overall, this can require long outages (sometimes 2 days) to get current.

Potential Solutions:

1. The ability to upgrade directly to the latest hotfix as noted here:
https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/33166225-upgrade-sccm-directly-to-rollup-version

2. Reduce the time needed to regenerate DRS sprocs and reporting views. These two steps seem to take about 80% of the overall upgrade time.

Hi, I don´t know why a small Hotfix, for example the PXE Bug in SCCM CB 1806 (KB4471892), which only change the sccmpxe.exe file, need a complete SCCM CB update cycle.
We manage 120.000 clients in a SCCM hierarchy (1 CAS / 3 PRI / 15MPs / 6SUPs / 350 DPs / 3 CMGs / 6 CloudDPs /... ). A SCCM CB Update + UpdateRollup is just possible on a update weekend. When we need also a hotfix on top, we run out of time.
The Update Step "INFO: Executing spDRSRegenerateAllDrsSprocsAndFuncs" takes up to 3 hours on each CAS/Pri Site + waiting until the DB Replication is back again (Site Readiness check cycle) + SiteComp Update MP/SUP/DP cycle ,.... takes a while for each update.
It would be fine to speed it up and little hotfixes would be treated separately.

With the new feature of having a remote content library for the primary site (a prerequisite for HA ability), there is an issue with the access permissions set on the remote content library.

During the process of adding a new application/package/driver/bootimage/etc, configmgr creates all the necessary files and folders in its own content library, however on one particular file structure for each package, it takes off inheritance of permissions and adds only the storage servers: 'users' and 'administrators' group.

This causes issues when the storage is hosted remotely and the primary site computer account is not a member of the storage local groups (in the case of using Linux boxes hosting NetApp storage, they don't even have groups).

This is currently controlled PER app/package/driver etc, by using the ribbon and selecting 'Manage Access Accounts' and then you can add in an AD group containing your primary site computer account. But this cannot be set globally for SCCM. This essentially renders the remote content library useless on a large scale.

Suggestion is to fix the access accounts to automatically include the primary site server, or allow the setting globally for all objects somewhere in security.

The new way to upgrade SCCM is great. However in order to have a restore point if the upgrade fails, we are currently running indipendent backups on CAS and our 3 Primaries. If we ever would need to rollback, we are not sure to be able to restore the infra from the backups we have taken, because they are not synchronized (each one run at his own speed). It would be great if there would be a task that would take a backup / snapshot of the full CAS and PRI (something like an SCCM backup for all sites that will be upgraded automatically through the task, excluding remote DP's). In case of disaster, this would allow to restore everything back to a stable infrastructure.

As noted in the licensing FAQ (https://docs.microsoft.com/en-us/sccm/core/understand/product-and-licensing-faq) and more specifically in the comments (https://github.com/MicrosoftDocs/SCCMdocs/issues/464) the SQL Server license included with ConfigMgr does not allow hosting databases for solutions commonly integrated with ConfigMgr.

This is a request to include rights to use relevant Microsoft / 1st party products (MDT, MBAM, PowerBI integrated with ConfigMgr) and 3rd party solutions which have the exclusive purpose of maintaining a healthy ConfigMgr environment (CMMonitor / Ola Hallagren's SQL Server Maintenance Solution, Anders Rodland's ConfigMgr Client Health solution, etc.) in the SQL usage rights that are included with ConfigMgr.

Microsoft solutions which do not integrate with ConfigMgr, and ConfigMgr related 3rd party solutions (1E Nomad/ActiveEfficiency, Adaptiva OneSite, etc.) whose purpose is to extend functionality, not simply maintain ConfigMgr, would continue to be excluded from usage rights.

From an ConfigMgr administrative perspective, it makes no sense to require SQL Express or an additional SQL server license to use solutions (Ola's and Anders) whose sole purpose is to address SQL/ConfigMgr issues (performance / client health). Additionally, it just makes sense to use the same SQL instance for Microsoft solutions which integrate with ConfigMgr.