Back in my MMSMOA session Hacking the Task Sequence 2014, I presented on what at the time was a unique situation – speeding up Task Sequences that were running in disconnected states. Earlier that year, I was creating a demo on how to OSD (Wipe-and-load) over Wi-Fi, only I ran into a problem in the fact it was taking way too long. This was a simple Task Sequence for a Surface Pro 2 and my goal was to get it down to sub 15 minutes. However, even the simple Task Sequence was taking 35+ minutes. No one is going to sit around watching this demo for that long so I need to figure out why it was taking so long.
As for the goals, the looked like this:
- Goal – to rebuild (refresh) a Surface Pro 2 over Wi-Fi in sub 15 mins
- Did not want to make wireless work in WinPE – we already have what we need prior to WinPE
- Want to control what was downloaded and therefore ‘download all contents’ before starting the TS was not a viable option
- Even with a simple TS, build time was taking 35+ mins
When checking out the smsts.log, I noticed that when in WinPE, each step had a ~10 second, then ~25 second, the ~45 second retry delay for each step. This was approximately an additional 80 seconds that were being lost because the task sequence was trying to send a status message back to the management point. And since the device was in WinPE with no Wi-Fi support, it was unable to send these messages. I figured there has to be a way to turn this off and after check with some of my Microsoft contacts, the answer was ‘nope – no way to turn them off’.
Well, usually where there is a will, there is a way. I started thinking what types of scenarios do not send status message??? Then the light bulb turned on – Full Media. In a Full Media build, ConfigMgr assumes that the device is not network connected and therefore does not even attempt to send status messages. I just needed to figure out how I could trick the currently running task sequence into thinking it was now running as a Full Media build. Dumping the task sequence variables of each type, I found a variable called _SMSTSMediaType. When it was running my deployed task sequence it was set to BootMedia. When it was running from a Full Media build, it was set to FullMedia.
The solution was then simple – before restarting into WinPE, change the read-only TS variable _SMSTSMediaType to FullMedia using TSEnv2 (a handy utility from 1E):
- TSEnv2.exe set _SMSTSMediaType=FullMedia
Once back in the new OS, re-enable status messages by changing it back to bootable media (BootMedia):
- TSEnv2.exe set _SMSTSMediaType=BootMedia
Now for the disclaimer – changing read-only variables is not supported (but it does work).
Now for the good news – in Configuration Manager Current Branch 1802 there is a new task sequence variable called SMSTSDisableStatusRetry. Set this variable to TRUE when you want to turn off the retry functionality and then set it to FALSE when you want to turn it back on. You will have to set it to TRUE if you have multiple reboots during the disconnected state, as it only stays off until the next reboot.
Originally posted on https://miketerrill.net/
2 thoughts on “Status Message delay during disconnect parts of a Task Sequence”
will this work in an upgrade sequence too? I am testing it, but thought you may know already :).
It should work for any type of TS.