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

Currently, Power Management is assigned to collections. Machines can be in many collections so one needs to be careful to make separate collections and use them exclusively for power settings. If a computer is in multiple collections with power management settings, then the results are unpredictable. If Power Management were moved to client settings, then the Power Managemebnt settings would be predictable and follow other well known and understood models of management. The Client Setting with the highest score would win. Even seasoned CCM admins when asked to adjust power settings looks into Client Settings and wonders why they cant see them. Power Settings on the collection properties makes absolutely no sense. I understand that the transition from this would be difficult. The ability to manage power settings pre-dates client settings and so the transition of those settings to client settings would be a challenge, but I really think that work is worth doing == and while you are in there, how about adding in the rest of the power settings that are not visible as options in the powersettings present in Collection properties?