For a Task Sequence, any content you have referenced and as long as you have "Download All Content Before Starting" set on the Deployment, it will download the Content into the CCMCache using BranchCache. However, we don't want to "Download all Content before Starting" in several situations, and in those cases, The Task Sequence doesn't leverage BranchCache at all for the download, which is VERY Bad.

Please enable the ability for a Task Sequence to leverage BranchCache during an active Task Sequence when it downloads content during the Task Sequence.

Priority 1, Make this work in Full OS
Priority 2, Make it work in WinPE

During OSD in Windows 10, the Mouse gets suppressed and you can't see it after the "Setup Windows & ConfigMgr Step" until the end of the TS. Many of us have cheated by adding a registry value in the offline OS

https://garytown.com/enable-mouse-support-in-win10-osd-during-state-restore

MS has even blogged about it:
https://docs.microsoft.com/en-us/troubleshoot/mem/configmgr/no-mouse-cursor-during-osd-task-sequence

My Request is... Build this into the Setup Windows & ConfigMgr step.
In that step, you're already mounting the offline registry, just add that value while you're in there. Perhaps make it controlled via a checkbox on the step or variable.

I see on your page you recommend undoing the change at the end of the TS, but I've never seen this causing an issue by leaving it. Perhaps you could resolve this by adding it into one of your scheduled tasks.

During Offline, you set that key and one additional key that says this key was changed by CM during OSD

CM Scheduled Task POST OSD, checks that key to see if set, then checks to see if it was set because of the TS, it then "fixes" the key and removes the "Set by CM" Flag.

Ok, so we got the alternative to run a TS from within another TS. Each step of a TS and even the run TS-step give you the option of supplying a condition which opens up the possibility of a modular OSD (with similarities of the App model).

But what if you need to makes changes to a boot image and want to test those before putting it in production?

Since one (main) TS=one boot image you need to make a copy of the TS and test the boot image separately.

If everything seems fine you switch the boot image of the TS in production.

But what if changes were made to the TS in production during the tests, which'll happen 75% of the time, and those changes were to affect the outcome of the customization made to the boot image?

If the reboot computer step had the choice of specifying a custom boot image you could use if prod=false to test the new boot image while minimizing the risk of that happening.

802.1x using a certificate and that certificate is about to expire in 8 days from now is a very real scenario.

Edit1:

Further more, enabling support for multiple boot images per TS, would also take care of the WinPE driver issues you face from time to time where you update/add a NW-Driver to get the new computer model to work, only to find out that 3 of your older models haven't worked since..

Having 20+ models of the same brand and find 1 to 3 drivers that works for every single one can be a pain in your rear.

But the later would also require some changes of how the pxe server chooses what boot image to present.

Having the ability to reboot to another boot image after a TS is started shouldn't be as complicated.

Step "Add Operating System Images" should allow adding install.esd file.

When we extract ISO for Windows 10 version. We can see install.esd instead of install.wim file. This has come as new change by microsoft. Rather than providing wim file, they have started providing esd file which make sense as it reduces size by approximately 30%, the same format we can see for Feature Update as well once downloaded through SCCM Windows 10 Servicing.

I am aware of the fact that we can convert the esd to wim by running command:
dism /export-image /SourceImageFile:install.esd /SourceIndex:1 /DestinationImageFile:install.wim /Compress:max /CheckIntegrity

But this seems like an additional overhead of converting the esd to wim first before using it.

If we can get the solution of supporting esd file extension for adding Operating system Image step, that will be the awesome experience.

Currently, when using the Run PowerShell Script step, you can specify a package and a script in that package, or you can use the entry box and enter custom powershell code there. It would be great to be able to specify package source AND use the custom code entry together. An example:

Run Command Line with a Package Source selected:

Powershell.exe -ExecutionPolicy Bypass Import-StartLayout -LayoutPath .\StartMenu.bin -MountPath C:\

Run PowerShell Script with Package selected:

Import-StartLayout -LayoutPath .\StartMenu.bin -MountPath C:\

To do this today using Run PowerShell Script, I would have to create a PS1 file in my Package source and select it as the script to use. This means that any script changes I make there would require updating the package source. If my package payload isn't changing and i just want to customize the script, using the Add Script option & Package source would be a great addition.

Create new task sequence media option: "Standalone hybrid prestagable".

This is basically a standalone task sequence that can function WITH or WITHOUT network connectivity to the SCCM infrastructure. If the content needed by the task sequence engine is already available locally and the connection to SCCM is unavailable, it installs via the local copy of content. Conversely if the connection to SCCM is functional, then it should check if the local content (task sequence, packages, applications) is still the latest revision, and if not, it downloads the content from the distribution point. As with any standalone media, it must be bootable to allow for bare metal or failed boot disk scenarios. The task sequence engine should check for the connection to SCCM servers before each step so it can check/verify content status. If we want to make it extra nice, provide a functionality so the admin can specify whether to prefer “offline” or “online” …. If the admin chooses offline then it always proceeds with the offline copy of the content but still communicates with the MP if possible (for logging, variables, etc.). If the admin chooses “online” then it uses a copy from a DP if its revision is newer. So that covers the “standalone” and “hybrid” parts of the media option.

Options inside of this media:
1. Allow the media to be encrypted except for a limited number of items needed for booting. For decryption, the admin specified “public” key could be stored in a file and used with a “private” key stored inside a Microsoft exe. This would provide protection on non-bitlocker disks while ensuring bootability.
2. Allow prestaging of this media in the form of a deployment to a collection. This means the admin can select which disk/partition on the SCCM managed PC should contain the new media. This deployment must continuously check if the pre-staged content is out of date and if so make the needed updates. It should also allow the content to be pre-staged on a PC where the task sequence was already successfully installed. It should also pre-cache all the needed OSD variables like PC name, network config, etc. in a file inside the prestaged area (needed for network less imaging).

If using both options listed, this would actually provide a means for OSD on wireless devices as the connection during WinPE is 99% not necessary (because we continuously ensure up to dateness of the media). This could also be used for large scale disaster recovery as the media is fully bootable and all content is already cached locally; ensuring devices can reimage without net connection or even if the network is available it ensures we don’t over burden the network by trying to reimage many PCs simultaneously. Lastly since the content is cached locally and regularly updated, this would speed up OSD as the media for the installations don’t have to traverse the network during the imaging process …. Instead they are cached well before they are needed and can p2p concepts like BranchCache and bandwidth controls like BITS (if needed on slow networks). I can even imagine scenarios for reimaging devices that are VPN connected.

I'd love to see a built-in step to add information to the SMSTS.log. Basically just a single-line text field that would parse TSVariables just like any other step that has text fields.

This would allow:
1. Easy way to dump a specific TS variable value at a specific point in time to the log for troubleshooting.
2. A potentially easier way to search the SMSTS.log file for a specific point in the task sequence. While you can search for task name, there are many entries that contain the task name - you could make the content of the step unique enough to find.