Neil Person PFE is the presenter.
What is PowerShell Workflow?
Introduced with Posh 3.0. Common syntax but different execution. Uses Windows Workflow Foundation (WF). Used by SMA.
Windows Azure Pack (WAP)
A collection of on-premise Azure tech. Gives you a true cloud: multi-tenant and self-service, with presentation of broad network access and reusable resources provided by Hyper-V and SCVMM. Add-ons provide the measurement billing.
What is SMA?
A process automation tool built on WF that has native integration into WAP. A component of System Center Orchestrator. The files to install it are on the SCORH media. A unit of automation is called a runbook. They are built using POSH workflows in SMA, rather than GUI in SCORCH.
HA and scalable infrastructure.
SMA and WAP
WAP provides a GUI to SMA. You can admin the SMA system and edit SMA runbooks in WAP. You do not need WAP to run SMA, but SMA provides a console to manage it. Once you integrate SMA into WAP, you can use SMA runbooks for WAP activities, e.g. creation of a VM triggers a runbook for post-deployment configuration.
WAP is not a service provided by tenants. It is a service used by the cloud admins to automate work. Might benefit the users/tenants.
Authoring, admin and execution
Can edit in WAP Portal or PowerShell ISE. Tags are used to categorize runbooks – Folders are not used. Runbooks can transition through states: draft, published, or in-edit. There are several ways to execute runbooks – Posh module, a web service. A job is an instance of an executed runbook.
SMA Architecture
3 components:
- Posh module
- Web service – the centre of SMA – authenticating users, accepting requests, etc. Deploying this creates an SMA database.
- Runbook workers.
Requests made, maybe via Posh module or via HTTP to the web service. The request is placed in the SMA database. Results might be sent to the web service. Runbook workers pick up jobs from the database and send job state information back to the database – if using state persistence functionality.
Install and Post-Install
Deploy the SMA components. Deploy multiple runbook workers for HA. Deploy WAP if you want that integration and console. Configure the WAP integration.
Automation in WAP is where you work with SMA. You need to register the SMA endpoint to integrate SMA with WAP. Any runbooks that you’ve created will appear.
SMA also appears under VM Clouds as Automation tab in WAP. This requires a second integration. You can use “an existing endpoint” from the previous step.
There are PKI requirements that have not been covered. Also some admin rights stuff.
There are a bunch of sample runbooks that you’ll see when you install it.
Tags
Runbooks are tagged for sorting or filtering. Runbooks can have more than one tag. Gives a multiple result possibility that folders cannot offer. Useful for nested runbooks where a runbook is reused for several greater tasks.
Managing a runbook
Created via the New menu is used in WAP. Drill into the runbook to see more. Use Configure to tag the runbook and enable logging. Authoring is where you can build the runbook from within the WAP GUI. There are draft and published tabs. SMA will put in a script block (snippet) for the workflow in draft to get you started. The code that you add is PowerShell. He uses Get-ADUser as a simple “hello world” demo to dump data on the output stream (write-output).
The test button gives you immediate feedback on code syntax. Publish the code, and then you can run the runbook. A job is created. It goes from queued to starting as a worker picks up the job from the database.
He copies the code into ISE. He runs it in ISE to test the code. It’s just a POSH workflow. Now he has code from the SMA module. His code runs get-smarunbook to query all the runbooks. Then Import-SMARunbook to import a PowerShell script to create a new runbook. Publish-SMARunbook will publish the runbook, readying it for execution. A new job is createed by running Start-SMARunbook. Get-SMAJob queries the status of the job. The output stream is showsn with Get-SMAJobOutput. And finally he deletes the runbook with Remove-SMARunbook.
Note he has a variable for the web service endpoint that is used as a parameter in each of the above cmdlets.
Assets
A collection of globally available settings we can use in any runbook. A connection asset is used to conenct to an external service. More than just username/password/server name. In ConfigMgr, the site code might be there. Might have a place for a certificate. Similar to what you see in SCORCH. A variable is used to share data across multiple runbooks. Credentials can use PSCredential or certificate to embed ID in a script securely. A schedule allows you to automate the scheduling of runbooks.
Checkpoint/Suspend
We can checkpoint a runbook. This is a save state action. Not like Hyper-V. For example, a script is creating a user and configuring it. If the script is interrupted after creating the user, a resumed execution will continue from the last checkpoint, therefore not trying to create the same user a second time.
Checkpoint-Workflow
Don’t go nuts with them. They have a performance impact. Be judicious, e.g after a critical action or after doing something that cannot be repeated.
A runbook can be suspended – pause and resume. Let the runbook do stuff, let someone inspect the work, and then resume execution to finish the runbook.
Nesting Runbooks
Don’t create a massive runbook. Use nested smaller runbooks. This encourages code resuse and higher quality runbooks that are more heavily tested.
A parent runbook orchestrates the execution of child runbooks. We can start a runbook inline by referencing the name of the child runbook and passing it any required parameters. They appear as one job. All of the output is rolled up into that one job thanks to your inline execution. Synchronous execution.
Start-SMARunbook is a second way to start child runbooks. The child runbook gets its own job. Output is specific to that job. Asynchronous execution.
Inline Script
Some code that you have lying around might not work. They can be encapsulated in an inline script. The workflow creates a POSH session to run that encapsulated script. Any returned data goes into the workflow. Checkpointing and suspending won’t work inside inline script, but can be done before or after the inline script.
$variable = inlinescript {
code
}
Demo
Parent runbook is taking in parameters that will need to be provided when starting a job. This parent will kick of children to create a user, populate groups, move the user to an OU, and send and email to a manager.
Get-AutomationPS<something> is used to pull inforation from SMA assets into POSH variables so that they become usable in the runbook code.
EmulatdAutomationActivites module allows you to run the runbook locally on a PC as if it was in SMA.
He calls the child runbooks simply by using the names of the published runbooks in the script as if they were cmdlets.
He publishes the scripts, and filters the tags in WAP. He goes into Assets and clicks Add Setting to add the required assets for the parent runbook. He starts the parent runbook. The parent’s required parameters are supplied via a pop up screen. A single job is created because inline runbook execution is used. The job runs – it creates a user, configures it, and sends an email to the manager.
Post-VM Deployment Servicing Demo
In VM Clouds we see that the VM Create action is tied to a runbook. Run this action will trigger this runbook. He wants to rename the guest OS computer name from the WAP-default random name to match the VM name in Hyper-V.
The scipt goes into a loop until the VM is up and running. He does this using Suspend-Workflow.
That’s all folks. SMA as a concept is pretty simple, as is SCORCH. The magic is in the code that you write. Learn PowerShell.