Many of our users (300000) need a feature to temporarily suspend any SCCM activity at least for a limited time per day.
Activities that need to be suspended are:
- Downloads
- Installs
- Reboots

Business cases:
Customers Skype sessions often get disturbed while a download is running in the background. We thought the setting "Suspend Software Center activities when in PowerPoint presentation mode" would help but from what our user reports it doesn't.

Another scenario are users working on metered connections, e.g. as they are provided by Deutsche Bahn. Users working on such a connection quickly use up their quota when a large download pops in. After that line speed is reduced dramatically which in turn makes it almost impossible to work online.

We have implemented something on our own to let the user disable SCCM for a limited time per day but we keep finding corner cases where deactivation of SCCM does not work.

We really think an enterprise product should provide this functionality out of box.

There are several registry keys which contain information about the currently installed Operating System as well as Installation/Upgrade history/errors/status information. These keys provide a valuable source of information that could be used for building reports/collections related to OS Deployment. One of the major barriers mentioned for not deploying Windows 10 Feature Updates from Windows 10 Servicing in the console is the lack of visibility/reporting available. Adding these registry keys to the default hardware inventory included in SCCM instead of having to customize inventory would make it easier to share reports/scripts/etc related to this data and could likely be built so that it could all be collected into a single table instead of several separate tables which result from current MOF customizations.

Examples of the keys (and sub keys in most cases) include:

HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion - shows all current OS installation information including the ReleaseId which is not included in inventory today.

HKEYLOCALMACHINE\SYSTEM\Setup\Source OS * - a new date stamped key is created for each upgrade that is done on a machine. You can use this to build upgrade history reports and distinguish between upgrades and new builds.

HKEYLOCALMACHINE\SYSTEM\Setup\Upgrade - the DownLevelBuildNumber key shows build of the last OS that was upgraded from.

HKEYLOCALMACHINE\SYSTEM\Setup
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup\Voatile - This key will show error codes for failed upgrades.
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup\SetupDiag - this key is created when you run SetupDiag on a box to check for failure codes.
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup\Tracking - logs the number of install attempts and failures.

We have been extending our inventory to included these keys and it has greatly simplified our upgrade and OSD reporting and remediation efforts.

Microsoft has added new properties to the Win32_ComputerSystem class since Windows 8/Server 2012, but SCCM CB has yet to include them as an option to select to allow them to be inventoried.

In addition, because the Win32ComputerSystem class is already defined by default in SCCM CB, it does not seem to allow the creation of a custom MOF with different labels that reference the Win32ComputerSystem class because of the existing internal class.

An example use case for inventorying this info is with the Surface Pro (5) that is only called "Surface Pro" in the "Model" properties, even though there are different versions of it (with and without LTE).

The property "SystemSKUNumber" exists locally in the Win32_ComputerSystem class on the system to differentiate the models, but this property is not available in SCCM to be selected for being inventoried.

Useful Win32_ComputerSystem class properties to add to SCCM to allow inventorying if needed, would be:

SystemSKUNumber
HypervisorPresent
PCSystemTypeEx
SystemFamily

See the following for reference: https://msdn.microsoft.com/en-us/library/aa394102

In SCCM CB, only the BITS setting of version 1.5 is supported in the client settings.
These allow only restrictions to common day and make no difference between the workdays or maintenance days.

The support of a more recent bit version (eg 3.5 - Windows 7 or later) would allow more significant improvements to the content download of Agents and Pull DP:
1. Differentiation between working days and days off
2. Differentiation of bandwidths depending on the job priority
3. Set maintenance days

A large IT organization with about 1500 Pull DPs has successfully implemented the BITS 3.5 Settings via GPO:
1. The download of software packages to Pull DP could be accelerated considerably, because the weekend could be better used.
The download period increased from 75 hours to 105 hours (ca.50%). The bandwidth limitation of the pull DP is more comparable to a standard DP.

1. The installation duration over the weekend could be reduced to 25% until 5% depending on the package size.




2. Emergency deployments or system customizations are distributed with high package priority and can be installed without BITS restrictions.

Currently, these settings can only be implemented using AD-GPO or with a script.
Different BITS settings depend on the system role or system state are difficult and inconvenient.

Support for BITS version 3.5 in the client settings of System Center Configuration Manager would be much easier and safer.

Current behavior on 1810 or older is that the Taskbar pop-up "Software Changes are Required" only comes quickly and disappears. Users might not know about Software Center existance and not all go there themselves. If a Software Updates are Deployed as a required, with long deadline, 90% computers starts install them only when deadline kicks in. At this point, the "Snooze and remind me.." function is disabled, no use of that.

I would like to have an option, that the behavior of Software Changes Are Required - notification would be conrollable via Client Settings, to hide it, to display it for XX min, to display it mandatory for XX min or to display it forever until the required updates or apps will get installed.

Currently, when "Suspend BitLocker PIN entry on restart" is set to Always, if the user initiates the restart Bitlocker PIN entry will not be suspended. This makes sense if we assume that the user is sitting at their computer when they trigger the restart. Unfortunately, due to COVID-19, we currently have many users accessing their onprem computers via RDP. If ConfigMgr prompts them to reboot and they click reboot over RDP, there computer will reboot and prompt for PIN entry, requiring the user to physically go in to the office and enter the PIN.

Bitlocker Network Unlock would likely be the best way to address this issue. This option requires additional infrastructure to be built.

One way to address this would be to rename the current "Always" option to "If User Not Present". Then, add a new option that will always suspend PIN entry for reboots initiated by the ConfigMgr client.

Today we can choose to limit metered connections to the following activities:
Client policy retrieval
Client state messages to send to the site
Software installation requests by using the Application Catalog
Required deployments (when the installation deadline is reached)

However, it would be much better if each of these items had a check-box when allowing limited metered activities. For example, downloading policy and sending state messages may be desired while installing required deployments is not over LTE, especially when a required deployment could be a Win10 OS servicing exceeding 1GB. The current options are not granular enough to permit desired activity while preventing costly activity.

I was at MMS and I know you guys are working on this, but I thought I would share a simple idea in case no one has thought of it. Make the current cache size setting into the "Base" cache size. Add a second setting called "Expanded" cache size. Normally the cache will be at the base size, but when it needs to download something larger than the base amount, the expanded setting kicks into effect. For the expanded setting, you specify "Use up to x% of free space on drive" The expanded setting would use as much cache as needed, but would never go over the % that you specify in the expanded setting. Once the installs are completed, the cache would purge what it needs to go back down to the base cache size.

SCCM Client considers AD GPO first than SCCM policies as next for Sitecode, SUP Server name and this increasing dependancy on AD, lead to scenarion where client cant find right site, even if SCCM gives it correct, due to broken AD GPO or some settings, or in VPN user cases etc. Instead doesnt SCCM make this an option so either we can chose whether AD GPO or SCCM policies in settings in console... or change the order so SCCM policies are honoured first, than GPO later...This has been observed to give lot better compliancy in few clients of us, but lot of changes need to be done as above option isnt present

We have the need to exclude windows update installation on specific computers while running on battery. The settings that exist today are site-wide and do not control the actual installation of the updates, but only the scan and evaluation. Moreover they are not easy to set (need to update the control file in the DB).
It would be great if we could add a setting in the client settings that would say just "Do not install on battery". This could apply to windows updates but also to all SCCM client installations in order to reduce the amount of battery drained by SCCM installations.
The SCCM client would need to check this property at each installation and would install accordingly. If the installation is not executed, the SCCM logs should report a message like "Due to policy xxxx the installation doesn't run on battery"

- We have tested Peer Cache settings on Domain Joined machines which works well but when testing on Workgroup machines, it doesn't work and gives the error as below:

Detected a workgroup client or a client on internet. Superpeer agent won't start

Please find the documentation as below:

https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/client-peer-cache
Requirements and considerations for Peer Cache
• Peer Cache is supported on any Windows OS that is supported as Configuration Manager client. Non-Windows operating systems are not supported for Peer Cache.
• Clients can only transfer content from Peer Cache clients that are in their current boundary group.
• Each site where clients use Peer Cache must be configured with a Network Access Account. The account is used by the Peer Cache source computer to authenticate download requests from peers, and requires only domain user permissions for this purpose.
• Because the current boundary of a Peer Cache content source is determined by that client's last hardware inventory submission, a client that roams to a network location and is in a different boundary group might still be considered a member of its former boundary group for the purposes of Peer Cache. This can result in a client being offered a Peer Cache content source that is not in its immediate network location. We recommend excluding clients that are prone to this configuration from participating as a Peer Cache source.

Expected Design Change:

Peer Cache feature to work with Workgroup Machines as well