A number of requests I have had of late have been to build in a time delay into the workflow of a service request in SCSM.  An example of this was building a server de-provisioning workflow, which needed to have a two week delay between powering off the server, and completely deleting it.  The workflow I put together for this involved Orchestrator runbooks to perform tasks such as removing System Center agents and powering down the server, however I did not want an Orchestrator runbook to be running for two weeks before the server deletion could be performed.

To solve this problem, I used a runbook activity within the Server De-Provisioning service request to generate a new service request for Server Deletion, based on a template that I had already created.  This means the original de-provision service request will complete successfully, with all tasks completed except the server deletion, which will now be performed under the new service request.

Unfortunately, this still left the issue that I needed a delay of two weeks before I could initiate a runbook activity to delete the server.  So, after putting my thinking cap on, I came up with this solution, which may not be the best, so if anyone has a better solution, please let me know…

 

The Solution

In order to achieve the two week delay I performed the following actions to build a new management pack in the Service Manager Authoring Tool:

1.  Created a new class based on the Activity class.  I could have used an existing activity class, such as manual activity, but I wanted to make it clear what this activity was in the workflow, and to make it easily identifiable later in the workflow.

ClassActivity

 

2.  Create a scheduled workflow that looks for all instances of the PostponeActivity class that are In Progress, and complete the tasks if the End Date has passed.  In this case, the scheduled workflow is triggered every 12 hours and runs a PowerShell script to assess the End Date with the current date, and change the status to Completed if the End Date is in the past.

WF Properties

 

WF Script

 

The PowerShell code in the script activity is:

 

3.  Saved and sealed the new management pack which will generate an MP and a DLL file, amongst others.  Import the MP file into the SCSM management group, and copy the DLL file to the workflow management server, and restart the Microsoft Monitoring Agent service.

4.  Once the MP is imported, create a PostponeActivity template based on the new class.  Other than providing a template name, nothing else is required in the template.

Create Template

PA Details

 

5.  With the template created, the Server Deletion service request I discussed earlier can be updated for the workflow to include the Postpone Activity.

SR Workflow

 

6.  Now, the Scheduled End Date just needs to be set within the postpone activity that will provide the required delay, which in this scenario is 14 days.  Obviously the Scheduled End Date cannot be hard coded in the template as it’s always going to be different, so I set this date in the runbook that creates the Server Deletion service request.

7.  Wait for the PowerShell workflow to run after the Scheduled End Date has past, and watch the Postpone Activity automatically complete, allowing the next task in the workflow to run… In this workflow, that’s a runbook activity to delete the server.

That’s all there is to it 😉

 

I appreciate this may seem slightly confusing, as I have not covered all the steps performed in the runbooks, but this should give you the information you need to achieve a similar result, and to help you along I have attached a sample management pack based on the above, which you can download from the TechNet Gallery, here.

And, I will post the full server de-provisioning process I put together very soon!

David