What happens to the automation activity when a checkpointed runbook restarts?

Stuart_Douglas

We're creating a user off-boarding offering that will start an SMA runbook to disable the affected AD user object; however, we're allowing a requesting manager to specify a date/time for termination that can occur in the future. This leaves open the possibility that monthly server patching could disrupt a running runbook. Setting a checkpoint will let it restart gracefully, but I'm curious how the status update back to SCSM will be affected. My suspicion is that the activity wouldn't automatically be updated with the completion status and that we'd have to find a way to do that programmatically within the runbook.

Tony_Collett

I'm not sure what would happen if an existing runbook that was in a pending state (waiting for a date) were to be checkpointed and reverted. It is possible it would still be in it's waiting state. But I'm not really sure. 

There are other methods you could try which could be to split the RB into 2 - the first RB would do whatever you need it to do then a manager specifies to do it immediately or after a date/time. If the manager says immediately, then force it to run runbook 2 which would complete the process. 
If it's for a certain date/time then leave a note in the incident (which would stay open/active) then runbook 2 would continuously monitor Incidents to find dates and when the date passes it would then run. 
This way you don't have several instances of Runbooks running at a time and the patching interruptions wouldn't cause a problem

I hope that makes sense

Stuart_Douglas

Interesting idea. We could fork the activity flow based on the manager selection for processing ("immediate" or "future"). The "immediate" path would trigger the RB that would do the account disable, while the "future" path would not, and would instead rely on another RB that runs every N minutes checking for open SRs with "future" = $true and doing a date comparison between now and the manager-specified date/time, calling the account disable RB when the time arrives. This could work, thanks!

Tony_Collett

I'm not sure what would happen if an existing runbook that was in a pending state (waiting for a date) were to be checkpointed and reverted. It is possible it would still be in it's waiting state. But I'm not really sure. 

There are other methods you could try which could be to split the RB into 2 - the first RB would do whatever you need it to do then a manager specifies to do it immediately or after a date/time. If the manager says immediately, then force it to run runbook 2 which would complete the process. 
If it's for a certain date/time then leave a note in the incident (which would stay open/active) then runbook 2 would continuously monitor Incidents to find dates and when the date passes it would then run. 
This way you don't have several instances of Runbooks running at a time and the patching interruptions wouldn't cause a problem

I hope that makes sense

Stuart_Douglas

Interesting idea. We could fork the activity flow based on the manager selection for processing ("immediate" or "future"). The "immediate" path would trigger the RB that would do the account disable, while the "future" path would not, and would instead rely on another RB that runs every N minutes checking for open SRs with "future" = $true and doing a date comparison between now and the manager-specified date/time, calling the account disable RB when the time arrives. This could work, thanks!