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.

In complex service provider environments are sometimes several SCCM hierarchies. Right now there it is not supported way to install a SCCM Agent from a other SCCM hierarchy on for example Pull DP. This kind of Servers cannot be managed by SCCM and we can not deploy Software Updates to them .We are also not able to Monitor Windows Defender Malware infects. In the most cases Customers are installing a Standalone WSUS for a such kind Servers. Even it is especially important to prevent Malware infects on SCCM Servers, customers are then not Monitoring Malware infects.. Would be great if a installation of a SCCM Agent on another hierarchy would be supported and possible.

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.

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.

When Service Connection Point is offline (No internet) and you need to use the ServiceConnectionTool.exe this process should be as solid as possible.
Had a case where the 1902 update where downloaded and imported to the SCCM 1810. Everything looked good. Installation started and went all the way to Install File step. Installation failed since the initial import did not include all prereq files in the redist -folder.

This could have been avoided if there would be some kind of content validation e.g. after the download or during the import or during the pre-req check.

There are different "manifest..xml" files that contains the information of the needed files and file hashes, so should not be a too difficult to implement. :)

Recently, we tried to deploy SCCM DR solution using SQL AlwaysOn in different Geo locations (multi-subnet), however setup was failing. The Microsoft documentation was not clear for enough. After talking directly with the Microsoft engineer, he confirmed that SQL AlwaysOn in multi-subnet environment is not supported with SCCM (v1802 at that time). Considering this, it’s pretty useless to have SQL AlwaysOn on the same subnet as main purpose of having a cluster is to design a solution for a DR situation.

Can you please confirm if Microsoft is working on AlwaysOn with multi-subnet/multi-site support for SCCM? When this feature will likely be released?

P.S. The error in the installation log is also misleading and does not state a reasonable error description so one can understand the setup is failing because of SQL AlwaysOn multi-subnet.