We have a service request to disable an AD account and 90 days later delete the account.

Which is the best approach to take bearing in mind we want an easy way to know the status of each stage

a) put a 90 day sleep in a orchestrator runbook - we assume it will survive orchestrator server restarts

b) add a delay in the service manager workflow e.g. https://msdn.microsoft.com/en-us/library/ms734721(v=vs.85).aspx or http://aquilaweb.net/2015/07/31/scsm-custom-postpone-activity/

Thanks

David

Those are both bad ideas. Make a runbook to find all computer accounts that have been disabled for 90 days and delete them. When it finds an account to delete have it find the computeres related service request and update it. Then just schedule that to run once a day. 

Thanks although there is no fool proof way of finding the date that accounts were disabled without having auditing (which itself doesn't sound easy to search):

https://social.technet.microsoft.com/Forums/scriptcenter/en-US/aa366608-4368-4411-b696-598a36398997/account-disabled-date

Is there any particular reason not to run extended time runbooks or service manager workflows?

Delay style runbooks tend to not work well because they are difficult to recover after an Orchestrator reboot. (In fact, most scheduling implementations in Orchestrator are less than ideal).

Creating a delay workflow in Service Manager is just a matter of building a polling workflow that examines timestamps and takes actions once your object has met or exceeded the timestamp. The workflow isn't "running" for 90 days, it's just polling every few hours (or once a day) to see when 90 days has passed. I use those types of scheduled/delay activities in a lot of my service requests.

From an ITIL perspective, however, delay activities skew "hours worked". Most folks count the amount of time a work item has been in the opened state as "hours worked"..introducing artificial delays can ruin those kinds of numbers. An alternative would be to put the service request on hold during the delay. This, of course, is only necessary if you need to track the progress of your process, or put a delay in the middle of a long complex process. If you just want to delay for 90 days, Pete's suggestion is sufficient and requires less work.

I'd suggest changing the expiration date of the account and then marking something unique in the notes/description field of the AD account. Then, limit who can actually modify those fields.

As Pete is suggesting (along with my own pitch here) another runbook executes every day looking for any account disabled, 90 days old, that has some special notes/description.

Delay style runbooks tend to not work well because they are difficult to recover after an Orchestrator reboot. (In fact, most scheduling implementations in Orchestrator are less than ideal).

Creating a delay workflow in Service Manager is just a matter of building a polling workflow that examines timestamps and takes actions once your object has met or exceeded the timestamp. The workflow isn't "running" for 90 days, it's just polling every few hours (or once a day) to see when 90 days has passed. I use those types of scheduled/delay activities in a lot of my service requests.

From an ITIL perspective, however, delay activities skew "hours worked". Most folks count the amount of time a work item has been in the opened state as "hours worked"..introducing artificial delays can ruin those kinds of numbers. An alternative would be to put the service request on hold during the delay. This, of course, is only necessary if you need to track the progress of your process, or put a delay in the middle of a long complex process. If you just want to delay for 90 days, Pete's suggestion is sufficient and requires less work.

• Proposed as answer by Stefan Johner 18 hours 57 minutes ago

Delay style runbooks tend to not work well because they are difficult to recover after an Orchestrator reboot. (In fact, most scheduling implementations in Orchestrator are less than ideal).

Creating a delay workflow in Service Manager is just a matter of building a polling workflow that examines timestamps and takes actions once your object has met or exceeded the timestamp. The workflow isn't "running" for 90 days, it's just polling every few hours (or once a day) to see when 90 days has passed. I use those types of scheduled/delay activities in a lot of my service requests.

From an ITIL perspective, however, delay activities skew "hours worked". Most folks count the amount of time a work item has been in the opened state as "hours worked"..introducing artificial delays can ruin those kinds of numbers. An alternative would be to put the service request on hold during the delay. This, of course, is only necessary if you need to track the progress of your process, or put a delay in the middle of a long complex process. If you just want to delay for 90 days, Pete's suggestion is sufficient and requires less work.

• Proposed as answer by Stefan Johner Friday, September 11, 2015 12:19 PM

Just realised that the service request may also be submitted several months before the staff member leaves so it looks like we need to go the route of 'building a polling workflow that examines timestamps and takes actions once your object has met or exceeded the timestamp'.  Any pointers on how to do this since the first activity in the service request has to wait until the due date.

Thanks

David

Here's a simpler implementation approach: Create a management pack that contains a new "delay activity" class inherited from System.WorkItem.Activity. Give that class an "InProgress" datetime property and a "DelayForDays" integer property.

Next, you'll need two workflows.

Create a powershell based workflow that triggers when an activity of your new class goes in progress. This workflow will set the "InProgress" property to the current date/time.

Next, create a powershell workflow that runs once a day. This workflow retrieves all activities of your class that are in progress. For each activity, the workflow compares the current date/time to the "InProgress" date/time plus the number of days in "DelayForDays". If the current date/time meets or exceeds InProgress+DelayForDays, set the activity status to completed.

Now you can create an Activity template based on your new activity class. Set the "DelayForDays" value to 90. Insert that activity into your service request template.

So now when your activity goes in progress, your first workflow will set the date/time that it went in progress. After that, your other workflow will examine that activity every day to see if the 90 days has passed since it went in progress and, if it has, set the activity to completed.

Here are the caveats: This is, of course, one of the simplest delay activity implementations and will have some compromises. For instance, if your activity is rerun, then the timestamp is essentially reset. This implementation does not respect work days or holidays or anything like that (a slightly more complicated problem, believe it or not). This implementation is limited to a daily granular level. If you want something more granular, like hours or minutes, you would have to adjust the logic and the 2nd workflow's frequency accordingly.

The advantages to this implementation is that it's pretty straight-forward to implement. It's also light-weight in that a workflow will only run once per day plus the number of times one of your activities goes in progress.

Hi Aaron

Looks good but am struggling slightly with this...

In the authoring tool I 'create other class', choose the 'system work item activity library' and choose 'Activity' as the base class?

And are the powershell workflows created within new management pack? - are there any faqs/walk throughs on how to do this?

Thanks

David

Hi 

in addition you can use power shell script to get list of users who has not logged in to domain from last 90 days and check if there is service request on user to disable the account.

refer below link for powershell script 

http://windowsitpro.com/systems-management/use-get-aduser-find-inactive-ad-users

https://gallery.technet.microsoft.com/scriptcenter/Get-Active-Directory-user-246f17c7

regards