Systems Center 2012 Orchestrator and PowerShell: Part 2

Summary: Make data from a Windows PowerShell script in System Center 2012 Orchestrator accessible on the data bus.

Hey, Scripting Guy! Question Hey, Scripting Guy!

We love using Windows PowerShell with System Center 2012 Orchestrator, but we’re having a hard time figuring out how to get our data to Orchestrator from Windows PowerShell. Can you lend us a hand? Please? Pretty please?


Hey, Scripting Guy! Answer Hello TS,

Honorary Scripting Guy, Sean Kearney here. I’m continuing to fill in for Ed this week.

So last time we saw how to get data IN to Windows PowerShell from Orchestrator:

Access Data from Orchestrator 2012 with PowerShell

Now is the time to flip things around and send it back. So would you believe me if I told you this is actually very easy to do?

Take a look at our tiny script from previously. Let’s pretend it has its own information that needs to be sent TO Orchestrator.

Image of menu

So here we have three pieces of data in a Windows PowerShell script. We’d like to make this information accessible to the next activity in the runbook.

To do this, you need to use the Published Data option. Click it to open it.

Image of menu

Click Add to open the Published Data Wizard (Hey, does this wizard have a cool wand? No?)

Image of menu

In the Name text box, type the Name to be used on the data bus if someone needs to subscribe to it. It can be a different name than your Windows PowerShell object, but it can also be the same.

Orchestrator (at the time of this post) supports three types of data: Date/Time, Integer, and String. In the drop-down list, select String.

In the Variable Name text box, type in the name of the Windows PowerShell variable you want to publish to the data bus.

In our earlier example, if we were trying to publish the object called $Important, we would fill out the Published Data as follows:

Image of menu

We just need to remove the $ from the name of the object. The name is also not case sensitive. As I mentioned earlier, the Name does NOT have to be the same as the Windows PowerShell object name. I could also publish it as FlyingRubberChicken or EvenMoreImportantDataThanTheFirstTime.

Image of menu

All this means is that if I access Published Data from that particular activity, and the names don’t match, I should have something in my documentation to draw a reference to the new name. Personally, I try not to change the names, but you can if you like or need to. Click OK whenever you’re done.

If you were publishing the Date/Time data, it would look like this:

Image of menu

Not so tricky is it?

In this case, I decided to publish all of the data. It turned out like this when I was done and clicked the Published Data tab:

Image of menu

When I click Finish and check the runbook in, I can access this data from other Orchestrator activities as I normally would with any other Published Data.

In the case of this particular script, I published all of the values. But I can publish as little or as much as I want. As you can tell, it is a manual process, and you must enter each object to be published individually.

So now we’ve seen how to get information IN and OUT of Windows PowerShell and Orchestrator. But is there anything else we need to worry about? Anything we can or cannot do?

Check back tomorrow and we’ll talk more…

I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Sean Kearney, Honorary Scripting Guy
Windows PowerShell MVP

Comments (3)

  1. @Degan123

    This is an old post and your question is from June but if I recall correctly you can flatten the data that is returned, if you look under Run Behvaiour of your activity, even the .net one. I’m not sure if this answers your specific question though.

    Going off your example it sounds like you need to get a list of users from somewhere and add them to a group in AD. The way I set my runbooks up is typically in pairs, I have a runbook that I set parameters on, and then use that data to call a second runbook.
    Typically I do this because most of the things I run have to run in the context of specific service accounts, and this is the only way I’ve found to do this.

    I think the easiest way is, assuming your user data is coming from a csv, create a .net activity that reads that in, and just drops the result on the pipe, this would be similar to how you might debug a script…

    $users = import-csv c:tempuser.csv; $users;

    Then like this post suggested just publish $users as your data, the next runbook would receive {Users} and for each user in that list add them to a group.

  2. Hayden Hancock says:

    Good question and answer. Thanks for providing this information!

  3. Degan123 says:

    Hey scripting Guy – another question – what if my powershell script output is in the form of CSV. ie: Value1;Value2;Value3. In terms of accessing the published data how do I differenciate between each of the CSV Values or Call specific Values in downstream
    runbooks ie: Use Value 2 and Value 3 for another function ie: Add all Value 2 listings to an AD Group?

Skip to main content