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

I am looking the issue/design from SMS 2003 to SCCM 2012 version. I am not sure if any purpose must be behind of this design of collection default query select * from sms_r_system.
Whenever a user create the query based device collection, if there is any modification in the query
He/she shouldn’t remove the entire query and apply OK.
If user applies ok, its automatically select * from sms_r_system query will enabled, it will targed to all system which is “All system” as limiting collection.
It has serious issue in most the companies, deployment is performing by L1 or L2 engineers.
It is nowhere document in the MS TechNet or in Blog.
I would strongly recommend to have some kind of mechanism to avoid this kind of changes in upcoming released.
You can reach me on email : kannancs@hotmail.com if you need any clarification.

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.

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 !

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.