Runbook Tester vs Run in Runbook Designer vs Run in Orchestrator Console

Question

Hi! Everyone,

I have hit another brick wall, but as usually, I'm clueless and hope I can get some knowledge here.

I have completed the creation of a Runbook to unlock AD User accounts following the workflow attached. The steps includes;

1. Initialize Data - Get user input for AD User login ID
2. Run .Net Script (Powershell) - Check Input for null value in entry
3. Run .Net Script (Powershell) - Check whether Inputted user login ID user object exist in AD
4. Run .Net Script (Powershell) - Check whether Inputted user login ID user object is enabled and lockout status is true
5. Run .Net Script (Powershell) - Check whether Inputted user login ID user object is in the same AD Group as the Runbook user
6. Run .Net Script (Powershell) - Unlock Inputted user login ID

I test run this Runbook in 3 ways;

1. Runbook Tester - Completed successfully
2. Using Run in Runbook Designer - Failed, no pop-up screen to request for input
3. Using Run in Orchestrator Console - Failed, while executing the below script less the quotes

"$CurrentUserGroupObj = Get-ADUser -Identity $CurrentUser -Properties MemberOf"

Can someone shed some light what is going on?

Thank you and best regards.
Ronald

Answer 1

The options are:

• SCSM -> "shoot sparrows with cannons"
• 3rd party solution -> not allowed
• Enter the user in the Initialize Data as a second input parameter

Answer 2

Hi,

Based on your script, $ENV:Username may return a computer account when you run the script with the System account.

As Leon/Stefan/Andreas mentioned, which account do you use to log on the Orchestrator Runbook Service?

Answer 3

Hi,

The Runbook Tester is different compared to when you run the runbook normally by using the "Run" button, or when running the runbook via the "Runbook Console" (web console).

The Runbook Tester enables you to simulate the most steps of Orchestrator Workflows, however there are some functionalities that are not the same. Below you'll find a list of different things when running a runbook with the Runbook Tester:

• Runbooks are not executed with the “Orchestrator Runbook Service”.
• Runbooks are executed with the account running Runbook Designer / Runbook Tester.
• Runbooks are executed on the system running Runbook Designer / Runbook Tester.
• Runbooks must be checked out.

Stefan has posted a good blog post about the differences over here:
Functionality differences executing Runbook with Runbook Tester

From the above blog post:

Below are some differences for the runbook activities, when running the Runbook Tester:

• All Standard Activities like “Run .Net Script”, “Run Program” or Activities from categories “File Management” and “Text File Management” are executed with the user account which started Runbook Designer / Runbook Tester. This account may have other permissions than the logon account of “Orchestrator Runbook Service”.
• All Actives are executed on the system running Runbook Designer / Runbook Tester and not with “Orchestrator Runbook Service”. If this are different system there may be different firewall settings or access permissions.
• In tab “Security” you can specify alternate credentials in the most Standard Activities. The Activities may fail if the user running Runbook Tester has not the permission to impersonate the user.
• The “Invoke Runbook” Activity will fail if the Runbook that should be invoked is also checked out (behavior in System Center 2012 SP1 Orchestrator).
• The Counter values are not saved into the Datastore and the original Counters are unaffected by execution with Runbook Tester.
• The “Send Platform Event” Activity will execute in the Runbook Tester, but it will not write an event in tab “Events”.
• The Instance of the “Runbook” executed in Runbook Tester will not be saved in “Log History” of the Runbook.

Before you transfer a Runbook to production make sure that it is executed with “Orchestrator Runbook Service” as you expect:

• If you need to pass values to the “Initialize Data” Activity you can start the Runbook with “Orchestration Console”.
• Turn on Logging in the Properties of the Runbook to see in in “Log” and “Log History” all Activity specific and common data for each executed Activity.
• Disable the Activities you don’t want to test temporarily.

---

(If the reply was helpful please don't forget to upvote or accept as answer, thank you)

Best regards,
Leon

Answer 4

Hi,

does this post https://sc-orchestrator.vasol.eu/functionality-differences-executing-runbook-with-runbook-tester/ answer you question?
Regards,
Stefan

Answer 5

In addition to Leon and Stefan:
If you like to test PowerShell scripts for use in Orchestrator start a 32-bit! PowerShell ISE or 32-bit PowerShell in the user context of the Orchestrator Runbook Service account.
This way executing the PS Script is working the same than executed by Orchestrator Runbook Service.

Maybe this is helpful.

Regards

Andreas Baumgarten

(Please don't forget to Accept as answer if the reply is helpful)