SCORCH – Use Orchestrator to build a password expiration notifier tool

In this post, I’ll show you one of the possible ways on how we can use Orchestrator to build a password expiration notify tool. Based on this example, you will be able to customize how many days before the expiration that you would like to notify the users (you can use more than one policy) , use different template for the  password change reminder emails, set up different policies based on OU, etc… Of course, there are other ways to accomplish this task, such as PowerShell, but by using orchestrator, it will be very easy to extend the Runbook and add some features such as notifying the manager of the user, creating an incident in service manager when the password is expired, adding some logging/error handling, reused the same process for different tasks, such as account expiration and so on.

Ok, so before going further, here are some details on my environment;

  • Windows 2008 R2 domain and forest functional level.
  • Windows 2008 R2 DCs.
  • The service account use to invoke the child Runbook has the proper read permissions on AD users attributes.
  • The service account use to invoke the child Runbook has permissions to create table on a SQL Database.
  • Orchestrator Service account has Data Reader permissions the DB created by the PowerShell script.

Also, here are other things to consider;

  • If the orchestrator service account has the proper read permissions on AS users attributes, you do not need to invoke a child Runbook.
  • If you want to schedule the Runbook to run a custom schedule, you can use Orchestrator Schedule.
  • If needed, you can modify the PowerShell script to output some error and adding some condition in the Runbook to monitor those errors.

Ok, so here are the steps;

  • create the following variables in Orchestrator (and if defined, use your naming convention)
  1. SQLServerName =  “SQLServerName”
  2. SQLDBName = “SQLDataBaseName”
  3. SQLTableName = “SQLTableName”
  4. OUToMonitor = “OUDistinguishedName”
  • create new Runbook and use the following PowerShell script to the Import AD Data to SQL;



You can download the PowerShell Script to import AD data into SQL from here,


  • Configure the return value of the Runbook as;



  • Then create another Runbook with the following activites;



make sure to thick the check box, wait for completion and then configure it to invoke the first Runbook (make sure that the account use to invoke the Runbook have to proper AD and SQL permissions.)


add these conditions on the link


use this query to get the information from the database (in my example I will send  two reminder, so one 14 days before the expiration and the other 3 days.) And if needed, you can change the values in the where clause to match the your need. Also, add the SQLSERVERDBNameVariable from Orchestrator to the FROM clause.




those values should match the ones set in the SQL query WHERE clause and you also have to configure them for each of the reminder you want to implement.  (In my examples, I use two reminder)


again you have to configure this activity for all the reminders set in WHERE  clause of the SQL query.

And voila, at this point you have to configure the proper schedule then start the Runbook, and you should be good to test 🙂 … and please make sure to test this before implanting this on a production environment.


SCORCH – SCObjectGuid is not valid for the given criteria

Recently, we’ve been working on Service Manager performace optimization, and one of the change we’ve made (based on both technet and MMS 2013 recommendations; ) is to change the group caculation interval.

Since then, most of our service requests who contained runbook activities, have started to fail…with the error, “SCObjectGuid is not valid for the given criteria”.


So, after investigating a bit, I noticed that the user account defined in the SCORCH integration pack, is impacted by this setting…

Then based on my knowledge, I was facing two choices, either give administrator privileges to the SCSM account in SCORCH or configure a loop in the Runbook with the following value and that until the service request relationship change (in my case 10 minutes)

–          Loop Exist condition, does not match the pattern

–          value;  ^$ (check for null value)

So, If you want to check if you’re impacted by this behavior, you can look at the SR history and check when the relationship class changes happen vs. when the RB activity.