Every now and then you think “wouldn’t that be a nice feature”. You fire up Google, spend some time browsing the net, end up looking at pictures of kittens and then finally somewhere deep down an archived website build in the late nineties you find what you’re looking for.
These are two features that I needed when working on SCCM task sequences. My first problem was that we had some tasks that couldn’t be part of the task sequence it self, but had to be available immediately after running the task sequence. The folks at Microsoft thought about this, and created the SMSTSPostAction variable. I won’t bore you with the actual implementation of the variable, so here’s the short version: define the variable at your favorite place (somewhere in the TS itself or as a variable on your collection), set the value to be the task that you want to be processed at the end of the TS. For example, “gpupdate /force /boot” or “c:/temp/postosdscripts.bat”. After running a deployment, you will see in your SMSTS.log that your value is the last task that is executed. This occurs after the SCCM client has been taken out of provisioning mode.
My second problem was.. well, forgetful onsite support colleagues. Every once in a while, your SCCM deployment will fail. An error message is displayed for 15 minutes after which the system will reboot and, depending on where it fails, will show a CTRL+ALT+DEL login screen. This might be just the old OS in case of preinstalled systems or redeployments, or the new OS without the rest of your TS. Originally, we tried to solve this issue by setting the background of the computer to “Deployment Successful” when it was successful. The onsite support guys know this, but still occasionally give uses a half-deployed system and then complain that OSD isn’t working as it should. So, to fix this, I decided that the task sequence error message should stay indefinitely. Again, there’s a TS variable for that! SMSTSErrorDialogTimeout. Again, add this to your deployment and decide on your value. 0 is forever(-enough), the rest is the time in seconds. Personally, I cannot think of a reason the error message should ever disappear without user interaction, but that might be me.