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.

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

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.

Enterprise security policy may block C$ share. File collection targeted to a collection may be also prohibited due to network traffic concern. It is troublesome to analyze sccm client log file for troubleshooting remotely even the support has local administrative right on the PC, as it requires to re-create the C$ share first, and unshare it later. It would be nice to also have an option to copy certain OS files to this share, for example, windowsupdate.log. RBAC should govern who can create the share and who can control the file copy list. This should make supporting SCCM environment easier without messing with GPO.