Users are regularly informed via a pop-up that new software is available. If you then open the Software Center, you will see countless entries with status Installed or Available. However, it is not recognizable for the user whether a program listed is suitable for him, whether it represents a new version of a software already used by him or should not even be installed.
It would be better to let the user know which new software is a new version of an already installed one and, moreover, what features this new software provides. Thus, a distinction for the user would be much easier and he would also be able to deliberately select and use new and meaningful software.

We are supporting companies around the globe out of our Configuration Manager; it goes from Australia to Americas. So, we have all the time someone deploying a machine using the OSD task sequence. But we also have to update content used in the Task Sequence.
If ‘Update Distribution Points’ is started and a new revision is created, the content goes in yellow (in Progress) on all DPs. If you now want to start a Task Sequence, it will fail due to missing content. If some DPs have blackout times, e.g. not allowed to replicate content during daytime, it is even worse, they cannot deploy new machines until next day.
It would be great to have a setting in the task sequence to allow the use of revision N-1 content if it is available on the DP and revision N is in progress.

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.

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