Once the cache has been filled all subsequent application deployments fail until the cache self-cleans. In CAS.log you see that the client is refusing to download the content because the cache, not the actual disk, is full.

This strikes me as a non-optimal design choice if the goal is to successfully install applications. If I want to install an application I do not want it to fail because of an artificial limit that until very recently was set at the time of client install. Most of the time the cache clears in 24 hours and there's no problem but there are two specific and prevalent cases where it is.

Task Sequences: During OSD we want every app and every update applied before the user gets the machine and we want it done quickly. It's very easy to go over a limit that day-to-day is ideal. This has forced SCCM admins to either abandon the application model during TS (a common MVP suggestion) or write custom scripts to temporarily increase the cache. Neither of these are ideal.

Large Applications: There are some applications (ex. CAD) that are just incredibly large (20+ GB) and all their own will exceed what an organization desires to reserve for cache size. Again, admins are either abandoning the app model entirely for these or running temporary cache modification scripts. This simply shouldn't be necessary for a system designed to deploy applicatons.

So, what to do? One option would to implement a rolling (first in, first out) cache where if cache space is needed the oldest non-persistent content for a compliant application is removed to make space. If the new app's content is larger than the cache itself then simply don't cache it. The only hard limit should be on the amount of free disk space to reserve before the SCCM client refuses to download content of any type.

TL;DR: Stop breaking application deployment just because the cache is full. No one wants to troubleshoot app failures.

It happened to me yesterday with SCCM 1602 CB, I was editing two task sequences at the same time, trying to copy a section from one into the other when the console crashed. I needed the work done and this didn't help as as soon as I started the console again I got the familiar message shown below. The problem is you have to wait 30 minutes for the sedo lock to be removed or use PowerShell cmdlets to try and remove the lock.

I don't think that is necessary at all as there is already a retry button on the popup, and what it should do is 'check what username is logged on, if that username matches the one editing the task sequence (or object), then when they click retry, remove the sedo lock.

That's my idea, please vote for it !

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

Replace the OSD Boot Image "Enable CMD Support (testing only)" feature with something that is more robust, helpful, and useful outside of testing like the F8 Troubleshooting Environment Steroids (F8TES).

Info: Display full name of task sequence and its ID
Info: Display full name of TS Deployment and its ID
Info: Display full name and type of error step
Info: Display error code
Info: (Stretch Goal) Display useful error message for top 10 errors

Button: “Open Command Prompt”
- Launches the command prompt
- Defaults to Insert instead of Overwrite (it currently defaults to overwrite in the WinPE phase)

Button: “Open SMSTS.log”
- Launches CMTrace and opens SMSTS.log
- Knows where the current log file is so you don't need to know where it bounces around to
- Includes CMTrace.exe in the task sequence environment so it persists in target OS phase
- Stretch goal: just include CMTrace in the client package so it always gets installed to windows\system32\ during client setup (in OSD and standard client install)

Button: “Show TS Variables”
- Simple out-gridview style view of variable name and value
- Allows filtering of built-in, non-built-in variables
- Hides the built-in variables for storing passwords, other long/garbage-looking variables

Buttons: "Retry Step" & "Skip Step and Continue"
- Stretch goal... Maybe a v2 goal.
- Would it try to download policy again and resume from step with same name?
- Would it check if the content has been updated and redownload if needed?

Feature: When launched, the built-in error message box should stop being modal. Mouse support in RDP to VM scenario is bad... can't move modal box out of the way to see the step name, and don’t want it blocking this UI. Bring modal back up when closing.

Feature: The task sequence reboot countdown should be paused while F8TS is displayed so it doesn’t reboot while troubleshooting.

Feature: Allow setting a password so that it can be lightly controlled (it would be just as insecure as a Network Access Account but better than security-through-obscurity).

Feature: Have the F8 Command line be a Boot Image feature, but have this F8 Troubleshooting Environment Steroids thing be a Task Sequence Deployment feature so it could be more selectively enabled.

Feature: Maybe for version 3: Include the ability to easily integrate and launch DaRT. Needs easy way to integrate into WinPE, target OS.

Feature: Maybe for version 4: Is there a way to enable the Remote Control features on the client during target OS phase so you can remote in without DaRT.

The Microsoft Local Admin Password Solution (LAPS) is great because of the security it provides, but is not in widespread use because it isn't enabled by default and requires desktop/server teams to work together to implement.

Integrate the functionality of Microsoft LAPS into the ConfigMgr infrastructure.

This could include simple steps to control replace the group policy need with a new compliance item node, or could include completely supplanting of the functionality (similar to how MBAM makes it so you don't need AD for managing BitLocker recovery keys).

Anything that ConfigMgr can do to bring down the bar for securing local admin passwords would do a great service to organizations.

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.

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

Creating SCCM Collection Queries is an art, and like most art, some of us are more suited to stick-figures while others produce beautiful creations worthy of a place in the Louvre, featuring graceful sub-queries, artful tabbing and good code practices.

When creating a collection, it would be helpful to have an optional 'Community Collection Catalogue' to choose from, which could have a user-voice style 'Most useful' collections list.

Users could create collections here, possibly even having a community 'wish-list' area for those without skills to request from those who would like to share.

Contributions in the community catalog could be counted for MVP or other recognition, possibly displaying badges. Gamification elements could be added, including Facebook or Twitter links to individual contributions.