Skip to main content

Written by Fred Bainbridge.

September 2014 MNSCUG Meeting - Notes

Last night was all sorts of awesome.  Thanks to Ryan Andorfer!  He showed some really amazing SMA uses.  Jaw dropping stuff.  

Also - we never got the name of the guy who won the epic rock paper scissors duel. Oops!  Please contact me to claim your prize!  

Below are notes from the meeting.  However if you missed it these notes do not do it justice.  It was absolutely astounding, eye watering, make you rethink your life type of stuff...

SMA notes -

  • PowerShell has a larger user base than Orchestration.  This appears to be a fair statement based on a user poll of attendees.
  • Orchestration was not designed to be a PowerShell engine, but it was something it could do.
  • Opalis was purchased by MS and the first release looked just like Opalis. Orchestration 2012 R2 felt the same way and was more like a hot fix.  However included in the release was SMA. 
  • SMA is a PowerShell based automation engine.  The biggest difference between SMA and Orchestator is that SMA does not have a drag and drop interface (yet). 
  • Drag and Drop looks good to management but downplays actual real world complexity.  This is not reality.  There is a reason really smart people have either not automated or have automated something (PowerShell).  Drag and Drop is not a good representation of business processes.
  • SMA is web service oriented and has runbook servers along with a database.  (similar to Orchestrator). There is no more thick client, SMA is all web based client.
  • The SMA web based UI is housed in windows Azure pack.
  • Why SMA - standard language PowerShell 4.0 (not old 32 bit PowerShell). Scalable infrastructure.

SMA lessons learned -

  • Nothing is extraordinarily simple.  Its not PowerShell, its PowerShell Workflow!  This is a significant difference.  Aka, learn PowerShell workflow!  It is essential for automation work.
  • Use checkpoints to be able to know what happens when a service or server dies during a process. 
  • Inline scripting - takes a block of code and runs it normal PowerShell.  You can change this block of code to run as a different user. 
  • Author your tools locally.  Use the ISE.  i.e.  Test the workflow from outside of SMA.  USE SOURCE CONTROL!!  I.e. Team Foundation Server.
  • Follow the normal Development process when working with SMA / PowerShell.  DEV-> QA -> Prod.
  • Orchestration made it VERY hard to promote or demote code from tier to tier. (QA to prod, etc)
  • Workflow vs. Module - repeatable code use a module.  For business specific tasks use a workflow. 
  • SMA Monitors - this is a concept from Orchestrator.  I.e. how do you tell an automation to do work?    Push and Pull methods.  (looking for information or getting handed information)
  • Track your executions - you do this to keep metrics on how much time you have saved.  This is critical to justifying an automation team.
  • SMA can load balance across runbook servers.

Getting started with SMA - (First learn PowerShell)

http://Aka.MS/bcb

http://Blogs.TechNet.com/b/orchestrator

http://gallery.technet.microsoft.com/Service-Management-fcd75828

  • Created on .