Content Replication from Site to DPs should be a frustration free Process or SCCM Admins. Unfortunately, I know no customer without smaller or bigger issues in this area.
Here is an uncomplete list of some issues I´ve noticed:
• Content Eval - Scheduled Task lost
o SCCM does not check if the schedule task got lost/deleted
o Suggested Solution: SCCM should verify the Scheduled Task on Service Startup
• Content Eval - Hash mismatch/Eval fails for package
o When content Eval fails for a package, the admin must manually redistribute it / take care of the error
o There should be an option in SCCM to automatically fix packages where Content Eval fails
• Content Eval - Immediately validate content after distribution
o When an invalid package gets send to a DP, it can happen that it goes into the state "Successfully distributed content"
o However, to content is invalid. If you run a content validation immediately will go to "Could not validate…"
o Makes troubleshooting much harder, as you must verify every package before it is "really" OK
o Suggested Solution: Immediately validate content after distribution
• Content Eval - Failed to retrieve the package list on the DP
o If DP has this error, it never gets fixed automatically
o If WMI Entry is missing and .INI file is there, smsdpmon.log does not tell which package is affected
o Content Eval Task does just use package list in local WMI (SMS_PackagesInContLib), but it should verify all packages assigned to it.
o WMI/INI fix script (eg: here, but many scripts like this exist on the internet) can fix the error, but will cause other issues.
o Suggested Solution: When Content Eval runs, the DP should download a list of Packages to verify (PkgServers Table?)

• Waiting for Content - Content did not arrive from CAS
o Content available (and verified) on Primaries - however some Secondary Sites have the status "Waiting for Content from CAS”
o Workaround: Reset Status in DB for Primary and Secondary and Redistribute
• DP and Pull DP - Handle Empty Packages
o SCCM DPs cannot handle Packages without content
o Scenario 1: Deployment Packages get empty automatically, because Updates expire
o Scenario 2: Create Package with content and deploy to DPs – Remove “this package has source files” checkbox
o Content Validation on DP will fail - DP will go to warning state
o Workaround: Detect and remove empty packages
o Suggested Solution1: DPs should be able to handle empty packages
o Suggested Solution2: SCCM should detect empty packages and remove them from all DPs
• DP and Pull DP - Redistribute does not fix .INI file issues
o If Content of INI file in PkgLib is invalid, a redistribute does not fix it
o Suggested Solution: Always rewrite INI File on redistribution

• Database - PkgServers, ContentDPMap and PkgStatus not in Sync
o Content is distributed and verified successfully to DPs
o Content is not written correctly to ContentDPMap Table (can happen if status message gets lost)
o PullDPs and Clients can´t download the Package
o Workaround: Redistribute affected Package
o Suggested Solution: If Content is OK on a DP, the ContentDPMap+PkgStatus should reflect this => When Package is successfully validated on a DP, all needed Tables should get checked/updated

The idea would be to have a setting (maybe Custom Client settings is a good place) where we can specify a specific order of priorities for network adapters from which SCCM takes the ipv4 address for content distribution and site assignment.

For example, we currently have the following settings in the network adapter configuration
1- wireless
2- LAN
3- Remote Access connections

For VPN clients this is a big issue if we have a boundary which conflicts with one of the internal ones, like 192.168.x.x since they'll use the local IP as a top priority instead of the VPN one.

If we have such a setting, we could specify for a specific "ServiceName" (in the wmi class of the network adapters) to have priority over the others it would be terrific! We would not have to change any network setting, we just instruct SCCM to override the default provider order so it can use the correct address.

When a package fails to distribute to a DP, the only option right now is to 'Redistribute' the package to the DP. This is inefficient for large packages since 'Redistribute' transfers all package content to the DP even if some content may have already been transferred prior to the failure. For large packages, this not only takes a lot of time but consumes more network bandwidth than necessary.

When a package is 'added' to the DP, only the missing files are copied to the DP however there is no way to simulate an 'add' action from the UI.

Having the ability to trigger an 'add' action for a Package/DP will help remediate content transfer issues a lot quicker as it will only require copying the content that's actually missing on the DP instead of 'redistributing' all content.

Currently, if there are 100 jobs in DistributionJobs destined for a given Pull DP, and PkgXferMgr fails to connect to the DP for the first one, only that job is marked with a retry time 20 minutes (by default) in the future. We then move on to the next jobs, all destined for the same DP, and mark them individually for retry. In a very busy environment with lots of Pull DPs and jobs, having just 5 or 6 DPs that are offline, this looping prevents PkgXferMgr from scheduling most of the jobs that are destined to DPs that are online.

The ask is that the update to DistributionJobs set the retry time for all jobs destined to the unreachable DP (via DPID) to 20 minutes (or the current setting) into the future. This would align with Sender not trying to connect to a remote site that is offline for an hour and would allow jobs to online DPs to be actioned in a much more efficient fashion.

ConfigMgr Team, your best practice document regarding the set up of boundary groups actually breaks peer caching.

https://docs.microsoft.com/en-us/sccm/core/servers/deploy/configure/define-site-boundaries-and-boundary-groups

To quote: "it is a best practice to create a separate set of boundary groups to use only for site assignment."

This is good advise, and I use this also for Management Points and Software Update Points so that if I add or remove a site system, I only have to modify 1-2 boundary groups instead of 150.

Since Peer Caching is now based on Boundary Groups, if you have implemented this best practice, then effectively every client in a site that has Peer Caching enabled is within the same boundary group, and therefore any client at any site across the world can search for and download content from any client at any site across the world. (We are experiencing this right now, as a matter of fact.)

In order to better control where clients can and cannot use Peer Caching, I would suggest that a setting be added to the boundary groups that the clients can read that would tell them whether or not they can use Peer Caching when inside this boundary. Since the client setting controls who can be a SuperPeer and who cannot, this setting will be good to ensure that the clients stay within their actual physical boundaries and only select SuperPeers within that boundary.

As a bonus, if you designate a Distribution Point to a boundary that is enabled for Peer Caching, then that will be the first DP that the clients reach out to if there is no content available on a SuperPeer within the boundary.

When a package is deleted from the console, the packages/apps are removed from the database. If for any reason a pull DP or DP is not available, or WMI has issues on those remotes site systems, the files on the remote SCCM content Lib are not removed. This creates orphaned files on the Content Lib and causes storage issues on the servers.
We are working with a customer that as a large number of PullDP's so we would like to suggest on the behalf of our customer, to have a retry mechanism in the console to delete the content from the PullDP/DP when they are available and/or the WMI issues are fixed.
This could help to minimize orphaned files and prevent storage issues in the customers DPs/PullDPs.

If you install Hyper-V on Windows 10, it will create a default adapter and randomly create an IP address, usually in the 172.x.x.x subnet. If by chance, you have a boundary that this random IP address falls into, the SCCM client will think it is part of this boundary, in addition to the boundary associated with it's physical NIC. The client considers both boundaries to be a Current boundary group and will therefore potentially download content from DP's associated within either boundary. In most situations, this additional DP will likely be across a WAN link which of course can cause issues.