In MDT The Sub in LiteTouch.wsf called SubTSXML(oTS, 0Sub) which expands the SMSTaskSequenceSubTasksequence steps in the Parent Task Sequence and replaces them with the content of the Sub Task Sequence should be moved into the Utility Class inside ZTIUtility.vbs

Then the logic in GetTSXML(sTSPath) from LiteTouch.wsf gets updated to call oUtility.ExpandSubTS oTS, oSub

Additionally add in functionality into DeployWiz_Initialization.vbs in the FindTaskSequencesStep(sStepType, sScriptCmd) function replacing the lines

' For efficiency, only load the task sequence if it has changed from the last time we loaded it

If sCachedTSID <> Property("TaskSequenceID") then
Set oCachedTaskList = oUtility.LoadConfigFileSafe(
Property("TaskSequenceID") & "\TS.XML" )
sCachedTSID = Property("TaskSequenceID")
End if

With something like

' For efficiency, only load the task sequence if it has changed from the last time we loaded it

If sCachedTSID <> Property("TaskSequenceID") then
Set oCachedTaskList = oUtility.LoadConfigFileSafe( Property("TaskSequenceID") & "\TS.XML" )
oLogging.CreateEntry "Processing Sub Task Sequences for Task Sequence ID:" + Property("TaskSequenceID"), LogTypeInfo
For Each oSub in oCachedTaskList.selectNodes("//step[@type='SMSTaskSequenceSubTasksequence']")
oUtility.ExpandSubTSXML oCachedTaskList, oSub
Next
oLogging.CreateEntry "Processed Sub Task Sequences for Task Sequence ID" + Property("TaskSequenceID"), LogTypeInfo
sCachedTSID = Property("TaskSequenceID")
End if

The end goal is that when you choose a Task Sequence in the Wizard it automatically expands out the Sub Task Sequences BEFORE it chooses what Wizard pages to show. Meaning you can almost FULLY modularize your Task Sequences! I have our entire standard Task Sequence broken out into Modular Pieces our custom client.xml template for windows 10 is literally just

<?xml version="1.0"?>
<sequence version="3.00" name="BCIT Modular Standard Client Task Sequence" description="A Modular task sequence for deploying a client operating system">
<globalVarList>
<variable name="OSGUID" property="OSGUID">{3b3b86f5-3ff7-4d90-9c86-ce27db81ca72}</variable>
<variable name="DestinationDisk" property="DestinationDisk">0</variable>
<variable name="DestinationPartition" property="DestinationPartition">1</variable>
<variable name="DestinationOSVariable" property="DestinationOSVariable">OSDisk</variable>
<variable name="DestinationOSRefresh" property="DestinationOSRefresh"></variable>
<variable name="DestinationOSDriveLetter" property="DestinationOSDriveLetter"></variable>
<variable name="DestinationOSInstallType" property="DestinationOSInstallType">ByVariable</variable>
<variable name="OSGUID" property="OSGUID">{3b3b86f5-3ff7-4d90-9c86-ce27db81ca72}</variable>
</globalVarList>
<step type="SMSTaskSequenceSubTasksequence" name="Pre Operating System Modules" description="" disable="false" continueOnError="false" successCodeList="0 3010">
<defaultVarList>
<variable name="SubTaskSequenceGUID" property="SubTaskSequenceGUID">{840612ee-fb6f-494a-a117-98d999e416ef}</variable>
<variable name="SubTaskSequenceID" property="SubTaskSequenceID">MW1ABGPREOSQ6K</variable>
</defaultVarList>
<action>cmd.exe /c exit 9999</action>
</step>
<group name="Install" disable="false" continueOnError="false" description="" expand="true">
<condition>
<expression type="SMSTaskSequenceVariableConditionExpression">
<variable name="Variable">PHASE</variable>
<variable name="Operator">equals</variable>
<variable name="Value">INSTALL</variable>
</expression>
</condition>
<step type="BDDInstallOS" name="Install Operating System" description="" disable="false" continueOnError="false" runIn="WinPEandFullOS" successCodeList="0 3010">
<defaultVarList>
<variable name="OSGUID" property="OSGUID">{3b3b86f5-3ff7-4d90-9c86-ce27db81ca72}</variable>
<variable name="DestinationDisk" property="DestinationDisk">0</variable>
<variable name="DestinationPartition" property="DestinationPartition">1</variable>
<variable name="DestinationOSDriveLetter" property="DestinationOSDriveLetter"></variable>
<variable name="DestinationOSVariable" property="DestinationOSVariable">OSDisk</variable>
<variable name="DestinationOSRefresh" property="DestinationOSRefresh"></variable>
<variable name="DestinationOSInstallType" property="DestinationOSInstallType">ByVariable</variable>
</defaultVarList>
<action>cscript.exe "%SCRIPTROOT%\LTIApply.wsf"</action>
</step>
<step name="Next Phase" disable="false" continueOnError="false" successCodeList="0 3010" description="" startIn="">
<action>cscript.exe "%SCRIPTROOT%\ZTINextPhase.wsf"</action>
<defaultVarList>
<variable name="RunAsUser" property="RunAsUser">false</variable>
<variable name="SMSTSRunCommandLineUserName" property="SMSTSRunCommandLineUserName"></variable>
<variable name="SMSTSRunCommandLineUserPassword" property="SMSTSRunCommandLineUserPassword"></variable>
<variable name="LoadProfile" property="LoadProfile">false</variable>
</defaultVarList>
</step>
</group>
<step type="SMSTaskSequence_SubTasksequence" name="Post Operating System Modules" description="" disable="false" continueOnError="false" successCodeList="0 3010">
<defaultVarList>
<variable name="SubTaskSequenceGUID" property="SubTaskSequenceGUID">{3f512083-c22d-45c5-bae6-f554a4c804ae}</variable>
<variable name="SubTaskSequenceID" property="SubTaskSequenceID">MW1ABGPOSTOSQ6K</variable>
</defaultVarList>
<action>cmd.exe /c exit 9999</action>
</step>
</sequence>

Every new Task Sequence automatically references all the steps for Pre OS and Post OS and with each being its own singular Task Sequence that itself calls other sub task sequences and so far on down to the individual shared task sequence steps. All that means if I want to change driver management I change ONE modular Sub Task Sequence and all the rest of my main Task Sequences have the change.

TL/DR this would REALLY open up the use of Sub Task Sequences to more than just steps that don't affect the Wizard's choice of Pages to display

It won't let me attach a zip file of my current Deployment Share with all the working and tested code changes I'm advocating for above. so here is a link to it from my onedrive plus the expanded Control and Scripts folders (Minus the Wim's and Applications to keep the file small) https://1drv.ms/u/s!AkO0CL3iRyesqGlSdUciIhnioz2g?e=Ll1NGE

We have a lot of different kinds of Dell client computers and some of the model names are very alike.

We also have a network which doesn’t allow us to use peer-to-peer techniques to lower bandwidth usage so we need to create rings and make a couple of computers at the time pre-download osupgrade packages and drivers before deploying an IPU to the mass.

Two of the models we have are "Latitude 7390" and "Latitude 7390 2-in-1".
(This is not the only combo of models that suffers from this behavior)
We've created one driver package for each of them.
But the "Latitude 7390 2-in-1" will always download them both due to what is stated here:
https://docs.microsoft.com/en-us/mem/configmgr/osd/deploy-use/configure-precache-content

"The actual query uses a LIKE statement with wildcards: select * from win32_computersystemproduct where name like "%yourstring%". For example, if you specify Surface as the model, the query matches all models that include that string."

"Latitude 7390 2-in-1" LIKE "%Latitude 7390%" will always be evaluated as true so a "Latitude 7390 2-in-1" will not only download the correct driver package, but the package for the "Latitude 7390" as well.

This is the direct opposite of what we're trying to accomplish, saving bandwidth.

Suggestion:
Add an "Exact match of model name"-kind of checkbox to driver packages and make the query model="yourstring" if it's checked.
Or even better, let us write the query, just as with conditions of a TS step.

When running a Task Sequence for Server Builds there should be TS functionality to assign ConfigMgr Site System Roles to the new server (Distributions Point role for example).

Right now we have to run two separate Task Sequences... One to install the base OS and the second to install the Pull Distribution Point, run preload content, add to DP Group, etc.

Due to the Client Framework required for Pull Distribution Points, trying to chain the Task Sequences does not work as during OSD the full client framework is not available so the Pull DP does not complete installation when attempting to install during the OSD process. Would be great if PullDPs didn't have any dependency on the Client Framework or if a method to install standard or PullDP role could be added natively to Task Sequence functionality.

I would like to be able to reimage computers while keeping my 3rd party encryption in place. One of the challenges with doing this using SCCM is that when SCCM restarts the computer to the Boot.Wim, the Boot.Wim formats the UEFI system partition on the primary disk at some point during the boot / loading process.

The 3rd party Pre-Boot Authentication is stored on the FAT32 UEFI System partition, which is also where Windows stores the Windows boot loader. By erasing the system partition, the Pre-Boot authentication application is removed, so that the subsequent restart following the successful execution of the task sequence to reimage the PC results in a BSOD as windows is unable to load the Pre-Boot and unlock the disk.

I suggest that the CM configured Boot.Wim should include the option in the Boot.Wim configuration (properties) to “preserve the UEFI System partition on boot” in which case it will not format the partition or erase any non-Microsoft folders that exist on the partition during the boot to the CM boot.wim assigned to the task sequence.

I would like to be able to reimage computers while keeping my 3rd party encryption in place. One of the challenges with doing this using SCCM is that SCCM does not respect the UEFI boot order when using the “Restart Computer” option. When configuring the “Restart Computer” task, if the option is selected to restart to the boot image associated with the task sequence, the process changes the BCD to boot to the Boot.wim on next boot (as expected) but it also changes the computers UEFI boot order (in the bios) to put windows boot manager first in the list.

3rd party encryption solutions that comply with UEFI boot order expect that the boot order should remain intact, and not change. This is necessary to support preserving encryption during a reimage, as the Pre-Boot Authentication needs to unlock the disk prior to booting from the Boot.wim, as the Boot.wim is located on the encrypted disk.

My suggestion is that the CM team considers adding a sub-option underneath the option to run “the boot image assigned to this task sequence”. The sub-option could be titled “Preserve UEFI Boot Order” and when checked, the restart computer task would simply omit the command(s) used to place windows boot manager as the first option in the UEFI boot order.