One of the lesser known differences between RunCommand and CustomScriptExtension is the fact that we do promise to not re-run your script in RunCommand, but no such promise exists for CustomScript. This is mentioned in the documentation, which isn’t often fully understood.
- Write scripts that are idempotent, so that running them more than once accidentally doesn’t cause system changes.
However, more than once I’ve been asked: when does CSE actually re-run the script?
The answer is, it may run on a reboot. This can happen if your script never finished running. This is actually by design, since many scripts run by CSE may reboot the machine. So, in that case the scripts runs, installs some stuff, reboots the machine, then we call it again so it may complete the setup. Note that we say may because the OS may not accept the request to reboot immediately, so it depends on how your script is written. If you really want to continue after a reboot, use DesiredStateConfiguration (DSC) instead of CSE.
RunCommand is very different here. Once your script starts, regardless what happens, we won’t rerun it – even if it reboots the machine.
So, for a comparison:
Extension | Reboot Behavior |
CustomScript | May re-run the script if it didn’t finish. |
RunCommand | Will not re-run the script even if it didn’t finish. |
VMApplications | Will re-run the application operation if it didn’t finish. |
So, that’s when CustomScript will re-execute. That seems simple, but the problem is you often can’t guarantee that the machine won’t be rebooted when running it. Numerous times I’ve seen a script start executing, then something else reboot the machine. This could be patching, some other process on the VM, or an operator. When the script comes back up, it executes from the beginning and causes havoc – or just fails.
For that reason, we advise all CSE scripts to be idempotent. You may think you have total control over whether the VM will reboot while executing your script, but you don’t.
0 comments