When we deploy an operating system we like to deploy the majority of the required applications at that time to ensure the computer is locked for the entire process and when the user then goes to use the computer all the applications are available. The issue is some of our applications are large and we have to break up the install application step with a clear cache step to ensure the applications install successfully. Now with 1702 we can have up to 99 applications in the install application step but with out the intelligence built into the task sequence to clear the cache we still need to separate out our large applications.

I would like to see the task sequence install application step clear the cache after each successful install of each application included in the step. Or an option to set this on each Install Application step.

The 30 Day Rollback option is available for all windows 10 users, but currently can not be automated using SCCM.

This should change, as this feature closely integrates with Microsofts testing strategy of using different branches which grow bigger in size as the rollout of a new build progresses.

When planing to integrate a similar scenario, in our case, we anticipate errors which have not been cought in testing of the previous branch and need to be able to quickly restore operations.

I am well aware that if all our applications were packaged this would not pose much of a problem but as you all know this is rarely the case.
Because of that a reinstall of the previous build (and local applications) would cause a massive loss of time (and money).

Since MS is pushing Enterprise Customers to become part of their testing chain and offers reasonable support times only with LTSB this feature - available even for home users - should be automated using SCCM.

When deploying Operating Systems, we are using the Pre-Cache so customers can install at a more suitable time; however there is no notification in Software Centre to advise if the files required for install have been cached.

This leaves a "pot luck" install, especially for those on slower broadband links on whether the install will start instantly, or if it still has to download the content and wait an inexplicit amount of time before the install can take place.

Can the "Available" change to "Ready to install now" or similar, so customers know they wont have to wait for downloading content?

Please Make CM aware if an OSUninstall (Reverting to previous Build) has happened, so it can heal itself into a functional state. Currently if you perform an OSUninstall from say 1809 to 1709, after you've upgraded originally to 1809 using a CM Task Sequence, the CM Client is non-functional.
Client is in Provisioning Mode, Services are disabled, and once you fix that, it thinks it's int he middle of the Task Sequence and shows the Upgrade TS "Installing", so then you need to clear that out.

Please make OSUninstall & CM Play Nice together, so we can offer users the ability to revert to previous build if they find an application problem or other issues after upgraded.

I get so many customers asking me this question: How can we deploy X amount of DPs/MPs or Primary Servers via a task sequence?

May I suggest a custom task sequence which builds out the above server and has a final step which adds the necessary roles without having to show the sccm site server install credentials?

This way the CM cmdlets can be invoked via the step - all that is needed are the parameters for the server.

if you have to do this manually for 800 DPs it would be simply adding all the server machine names to a collection and the task sequence will take care of the job.

It would be nice if a checkbox "Perform Windows Setup Compatibility scan withnout starting upgrade" inside "Upgrade Operating System" step in SCCM Upgrade Task Sequence would be language neutral.

What I mean by this is that we would like to run this scan prior to the Upgrade itself but to be able to do that currently we have to switch the running OS to en-US (the same language as the Upgrade iso), then run the scan and in case an error is found, we need to switch back to original language again and reboot the computer. This is not a best approach and add additional time to the deployment and is bothering the users.

We are running SCCM 1706 and upgrading computers to 1709.

Since Microsoft introduced the strategy to deliver two new OS builds per year for Windows 10 and a mandatory expiry date of SAC builds, the focus / Engineering task focuses back to perform in place Upgrades via Task Sequences.

As those Task Sequences are not deployed at a specific time during the week it might happen that some Windows OS Quality or Office Update are pending or queued for Installation. It does not make sense to deploy a Quality Update for the OS Build which is queued to be upgraded to a new OS Build (with new Quality Updates).

My Feature request is to priorize those in place upgrade Task Sequence deployments over OS / Office Updates in order to perform the in place upgrade for the Endpoint ASAP after its Deployment and prevent long reboot sessions due to earlier OS / Office Update installations.

When you update content that is referenced by an application, devices currently running the task sequence will fail when they get to that step because the version of the files they were expecting is no longer available.

It has been suggested before to keep old versions of the content around on the DP so that these devices can successfully finish.

My suggestion is to either do that, or change it so that the content request is for a version equal to OR GREATER THAN what was validated at the beginning of the task sequence. This would be useful both inside and outside of OSD.