account permissions

John Curtiss 66 Reputation points
2020-08-26T00:53:49.337+00:00

orchestrator 2016 runbook calling a powershell script in the .net script activity. script is wrapped in "$result = powershell {ipmo SomeModule}".

the script also calls a creds file with an AESKey which was created using the orchestrator runbook service account. specifically, this script is using the psPAS module for cyberark available in the gallery. but i don't know if that's relevant.

if i RDP to the runbook server as my orchestrator runbook service account and run the powershell script, the script works.
if i RDP to the runbook server as my orchestrator runbook service account and run the Runbook Tester, the runbook works.

but if i launch the runbook from the orchestrator web console, it doesn't work. (of course the activity shows Success.)

main question, what could be the difference between
running the runbook tester as the service account on the runbook server (works)
vs
the runbook service, running as the service account, running the runbook on the runbook server? (doesn't work)

System Center Orchestrator
System Center Orchestrator
A family of System Center products that provide an automation platform for orchestrating and integrating both Microsoft and non-Microsoft IT tools.
215 questions
0 comments No comments
{count} votes

9 answers

Sort by: Most helpful
  1. Stefan Horz 3,461 Reputation points
    2020-08-27T17:22:48.73+00:00

    Hi,
    +1 one to Andreas: If the Runbook works on the same Orchestrator Runbook Server and the same user running Orchestrator Runbook Service, excecuting the Activity should have the same result:
    ... if yo have the the same Input Data. Do you have a "Initialite Data" Activity with parameters in the Runbook?
    Do you have more than one Runbook Server which executes Runbooks.
    Is the Runbook checked in when you trigger the Runbook with Orchestrator Web Console in the same version than running with Tester before?
    To get perhaps more infos from "result" take a look at https://sc-orchestrator.vasol.eu/looking-inside-the-thing-with-21/
    Regards,
    Stefan

    2 people found this answer helpful.
    0 comments No comments

  2. John Curtiss 66 Reputation points
    2020-09-04T20:44:21.697+00:00

    wrapping it in $result = invoke-command localhost {$mystuff} instead of $result = powershell {$mystuff} seems to have fixed it.

    1 person found this answer helpful.

  3. Andreas Baumgarten 97,566 Reputation points MVP
    2020-08-26T14:46:08.373+00:00

    Basically the quick answer is "there is no difference" in the scenario you described.

    The Runbook Tester is running with the same account than the Orchestrator Runbook service that is used if the runbook is started by the Orchestrator webconsole.

    Is there anything helpful detail in the $result variable?

    Regards
    Andreas Baumgarten

    0 comments No comments

  4. John Curtiss 66 Reputation points
    2020-08-28T21:04:54.71+00:00

    the runbook is running on the correct runbook server, and it's not checked out. i can see the activity in the log. it succeeds. it just doesn't accomplish anything.

    there is an initialize data activity. if i fill it in with the same information in the runbook tester and the orchestration console, the runbook tester (running from the runbook server as the runbook service account) is the only one that actually accomplishes anything.

    for testing, i configured an email activity in the runbook that sends me $result in the body. the email is blank when i run it from the orchestration console, but from the runbook tester (running from the runbook server as the runbook service account), the email has a bunch of information.


  5. John Curtiss 66 Reputation points
    2020-09-01T14:45:18.973+00:00

    testing plain reply

    this forum doesn't seem to want me to post code using the "insert" code snippet.

    "You don't have permission to access "http://learn.microsoft.com/answers/answers/77011/post.html" on this server."

    0 comments No comments