It would be useful to integrate AD authentication in the WinPE boot image for PXE boot OSD.

When deploying operating systems with MDT and WDS, users are prompted to authenticate against AD when PXE booting. However, in SCCM the only supported way to secure the PXE point is with a DP password that all users share.

There are third party "hacks" which can integrate AD authentication in the WinPE boot image (Johan Arwidmark's ADSI drivers) but it seems like this would be simple to implement within the product itself since it is already done in MDT/WDS.

Provide a better way to support preflight checks for OS upgrades in terms of success/error being shown to users. Being able to show users a warning sign instead of a hard stop error would give better user experience. Currently, we either get "Installed successful" message, with having continue on error checked, or hard stop or scary error message that's presented to users if requirements aren't met. Everyone uses preflight checks now for OSD, please support it better with better notifications (customized) and error/warning handling.

The new Model field on drivers is useful, but needs to be extended to other content types, like Packages & Applications, where Model specific items need to be installed (e.g. specific HP SoftPaqs, or video drivers that need to run from .EXE etc).

While a Step for Run Command line can be used for most Windows Installer, if an application uses a EXE it would be nice for the application to be downloaded and the exe used.

Be able to recover deleted task sequences. In case of accidental deletion.

If you are doing BIOS updates as part of a Task Sequence you are sometimes faced with "unexpected reboots" because the BIOS update program restarts the computer if you want or not (e.g. Lenovo ThinkStation BIOS updates).
Those reboots will cause the Task Sequence to fail.
It would be very helpful for those scenarios to be able to prepare a task for such reboot events and to ignore the errors in order to continue the Task Sequence after the reboot.
Maybe a modified "Restart Computer" task which prepares a Task Sequence reboot but doesn't execute it could be an approach.

at the moment we need to use scripts with passwords in it against a CES/CEP because SMS Agent is in provisioning mode. It would be great to do certificate enrollments during deployment with the certificate enrollment point as the proxy. we use tpm attested certificates to check if the machine is known to increase security

It would be very useful to be able to control if a Task Sequence has been "Installed" or not by adding a custom detection method like we have in the AppModel.

This is valid in scenarios where we do a bare metal required rollout and in in-place-upgrade scenarios. Combined with having different versions of a task sequence being deployed.

Please allow Task Sequence specific passwords. Currently the only built in option to password protect a task sequence is to password protect a PXE point.

Display the Step No. in the Task Sequence Editor so it can be easier to find where in the TS an issue is occurring. This could be handy because you could have multiple steps of the same name (especially gather & User Toolkit)

The "Mandatory Task Sequence Warning" message is hardcoded to 2 or 3 minutes. It is possible for most applications of this to be a good idea. In the case of rapid deployment such as I am establishing for large numbers, it is way too long. The ability to modify this timeout would significantly improve the process.

Make it possible to password protect the F8 command prompt during OSD.

the F8 support is very usefull for troubleshhoting but it is alos a security issue. Having two bootmedias (one with and one without) isn't a workaround since you will have to reboot to get the F8 support and the problem may not occur during the second atempt.

Allowing us to password protect the prompt gives a secure function that doesn't require a reboot when you have to troubleshoot.

During an OSD deployment we install several applications that return a reboot exit code.

Each time they install they reboot, rebooting takes a minutes or two to restart the task sequence engine so each application is adding 2-3 minutes to the build time.

I would like to ignore these reboot exit codes because I know I will be rebooting at the end. We would prefer to not have a separate application for OSD and for Software Center.

After creating stand alone media from a task sequence, all packages in the task sequence are not encrypted. All files in applications, packages and also os image can be exported easily. The all media in the stand-alone media should be encrypted with pre-given password (determined when standalone media created) . So, the all files will be protected.

There is a buisiness need to be able to select a different bootimage as the one linked to a task sequence. This can be used for administrative tasks of a client such as booting MDOP DaRT over the network. Implement the ability to define which bootimages can be selected at a TFTP boot. (Of cause, OSD is only possible with the image linked to the task sequence)

While Running Task Sequence to deploye custom image for Windows 10 version 1903, task Sequence doesn't show any progress bar in Full OS Mode.

Task Sequence progress bar works fine until WinPE Phase which includes image applying and download of "Setup Windows and configmgr". Right after the reboot when we are expecting to start Full OS phase starting with SCCM Client installation, there is blue screen shown with message "Just a moment..." till the time all the all the steps of task sequence completes successfully.

This doesn't bring a good customer experience.

By default when ConfigMgr adds drivers to a boot image, unsigned drivers are not allowed and causes the 'Update Distribution Points' action to fail with the following error in C:\windows\logs\dism\dism.log:

Cannot install non-signed boot-critical drivers on amd64 images. Use /forceunsigned switch to override.

The workaround is to manually add the unsigned drivers to your boot image using DISM and /forceunsigned.

If we could automatically add the /forceunsigned switch when ConfigMgr attempts to update the boot image, this would be a non-issue.

When using task sequences to deploy applications or settings that require a restart, please include a check box on the "Restart Computer" action to suppress the user logon actions (ie. Ctrl + Alt + Del).