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

While testing some new functionality in SCCM 1602 current branch I inadvertently searched for a possible new variable using the 'set dynamic variable' step.

Unfortunately that doesn't list read only variables in the 'existing variables' list (read only variables begin with _). It would be awesome if this gui would list all built-in variables (including read-only ones) as this would make searching for a particular variable easier than having to google or bing it.

Secondly, how about the option to list all custom defined variables in this gui, along with their values (if any). today we get the following headings Name, Description, how about adding one more, Value.

The reasons I think this is important is

* saving time searching for new variables on Technet
* as ConfigMgr changes version often, being able to list all current variables available to that product version would be great
* debugging task sequences to see what custom variables values are set to what value

cheers
niall

Right now, the automatic Client upgrade scheduled Task is not aware of any running installations. So if appenforce.log shows a running Installation and at the same time the randomly timed scheduled tasks kicks in, the Installation cannot finish without error and will randomly leave the Installation or the SCCM Client itself in a unhealthy state. A reinstallation is the only way out.

Repro steps
- Activate automatic Client Upgrade in Hierarchy settings
- Exclude some test clients from automatic client upgrade
- Create an Application with a deploymenttype using a custom script
- As the script, use a batch file pinging localhost with parameter -t so that the dummy installation will newer end. That gives you time for the test.
- Deploy the app to the excluded test clients
- Let the installation run
- Set the clients to not be excluded from automatic client upgrade, so that the scheduled task for the upgrade will be created locally
- run the scheduled task manually to simulate the client upgrade
- you will see some errors in appenforce.log telling you that the installation could not be finished without error

Expected behaviour:
- The automatic client upgrade function should not run if an installation is allready running
- instead of scheduling a scheduled task you should schedule a package install, so that the sccm client can only start the package/upgrade if no other installation is running

It would be great to be able to customize the Windows 10 image or allow a "clean up script" to run post install. I like the concept of the Windows 10 Servicing part of the SCCM console. I think it will become important as upgrades start rolling out 1-2 times a year and majority of companies have Windows 10 clients that need servicing. Being able to create Servicing plans will help keep IT on top of the upgrade process through different updates.

The current model just doesn't work for a lot of companies. Not many places allow games such as the Xbox app for corporate use. Candy Crush? come on.... Twitter? Maybe.

I think if you start with the ability to tag on a PowerShell script to run, it would make this much more usable to many companies. Down the road I would like to see the different security updates for the different builds put in there as well. It's going to get messy getting the same vulnerability patched in 3-4 different builds.

Another idea might be to ability to link task sequences into servicing plans.

DSC is a wonderful framework for handling baseline configurations across Windows and Linux machines, but it's completely unsupported in SCCM directly. While a Pull server is certainly more simplistic than an SCCM hierarchy, it would still be very beneficial to have some integration in a couple of areas:

Management Points can easily be configured to host mof configurations for clients, and a new client policy class for allowing the SCCM agent to configure the pull server settings on a host would be great. Alternatively a new role could be made ... not sure that would feel as elegant.

The baseline section could contain DSC configuration files or items for a more open/standard baseline control. THe current baseline scripts feel so dry it would be great to see it replaced with a standard DSC formatting.

The certificates store under administration can hold public keys for password encryption for MOF files when generated.

Distribution Points could house modules for said Pull server calls. Want to get clever? Blend in some chocolatey goodness and allow us to create ADRs for pulling the latest versions down on an interval.

Reports! Yes, the reporting module in DSC is dry ... and how great would it be to have some canned DSC reports for easy at a glance compliance settings.

Needs for confiuration are changing ... some great work is being done to make declarative configurations happen ... but SCCM still uses simple and clunky scripts for baselines. Lets standardize on power-shell already.