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 !

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.

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.

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

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.

The recent Servicing Stack Update released out of band in May was made a requirement for the June cumulative updates but itself did not require a reboot. This created a conundrum for organizations patching devices with maintenance windows. Because of the lack of reboot on the servicing stack update there was no option to run a full evaluation that would detect that the cumulative update was now applicable and install it within the same maintenance window.

A few ways to solve that problem but the one that strikes me as straight forward is to modify, extend, or duplicate the "if any update in this deployment requires a system restart, run updates deployment evaluation cycle after restart" feature introduced in CB 1606 to allow it to run a full evaluation after all of the updates have installed, regardless of the reboot condition. Where maintenance windows allow this would enable the user to install updates that are newly available regardless of reboot.

Bonus Points: Support an option that does so even if the updates fail. So many times simply retrying an install solves the problem.

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.