We made some changes in the TS step for App Deployment, that gives you more control over cache. Try this out in #SCCM TP 1906
I agree with adding more control of this inside of the task sequence and application model itself, but for anyone else looking for a workaround without changing default client settings in the meantime, I've had success setting the 'SMSCACHESIZE' installation property in the "Setup Windows and ConfigMgr" task sequence step.
Doing this allows you to specify a cache size during OSD when the client is initially installed/initialized in the SysPrepped OS, but it will eventually get set back to your default client settings specification after the task sequence completes and a machine policy evaluation runs.
Updated by bobmn for sangeev/OSD
I completely concur with this one. It feels like an integrated piece that's been missing for quite a while now, without you having to duplicate the logic for different deployment types.
If you have an app you've added multiple deployment types and detection methods for and you have to add in commands or a script into a task sequence to do those same things, then you now have two places that you have to update your uninstall commands and detection for whenever a change is needed instead of just modifying the application.
Check out the new uninstall behavior in 1804 tp.
I concur with this. It should be registered during console installation, just like the AdmPwd.PS module feature when you install the LAPS package.
I absolutely second this.
It may not be so important for ZTI, as everything can be done with scripts using the OSDDiskIndex variable to identify the correct disk to partition, but in the case of interactive OSD GUI's, being able to use a variable for the disk NUMBER in the Format and Partition step is essential.
Here's my personal use case:
I've built my own OSD menu that allows our techs to choose all options and software for the deployment at the start of the task sequence. In the menu is a combobox drop-down that I populate with all of the physical disks in that machine so the user can select the disk to format and use for the operating system.
To be able to use the built-in "Format and Partition Disk" step in the task sequence, I have to create duplicated entries of these steps for as many possible physical disks that could ever be in any system (which may or may not change over time). Doing this also litters the task sequence with duplicate steps that wouldn't need to repeated if the step accepted a variable.
Currently, I've only created steps to account for Disk 0 and Disk 1, since we don't USUALLY have more than two disks in a machine, but it does happen, in which case this doesn't work at all. Essentially, the format and partition steps use a task sequence variable set by my menu that determine if they should run based on the selected disk number in the menu.
In my opinion, the most intuitive way to implement this would be to either allow %VARIABLE_NAME% input into the "Disk Number" field, or to allow a separate radio or to use combobox to specify a variable name to refer to for the disk number/index. Obviously it would require a valid input and should fail with an error code if the task sequence variable does not exist or is not a valid integer corresponding to disk that is present.
Normally in a scenario like this, I'd just write my own script to format and partition the disk instead of the built-in step, using my own variable to determine which disk to format, but the built-in step does a LOT more than it appears to do in terms of setting other required TS variables needed for other steps, from the "Apply Operating System" step, to the driver application steps to determine the location to stage the drivers and the OS version to choose drivers for.
I've tried isolating all of the variables that the built-in step creates but they're obviously subject to change with CM updates and I've seen it happen before so this is just too much maintenance.
Please let us know if this can be implemented, Microsoft.