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.

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.

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

3. 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.

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.

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.

- 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
================

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 Win32_ComputerSystem 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 Win32_ComputerSystem 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