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

When viewing the completetion statistics of an application it says that an amount of deployments have experienced errors, in this case 11. When I go to the tab "Errors" when inside "Deployment Status" i only see two errors.

I have seen this in other applications too, statistics reports alot of errors but when i open the "Errors" tab its empty.

If i run the report "Application infrastructure errors" i can see that the amount of errors reported in the statistics match the number of errors in the report. Most of them are "CI documents download timed out" (which i have nailed down to reitrement of applications).

It would be nice if the errors reported in the report ended up in the deployment status tab "Errors" of the same application.

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.

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.

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.

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

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