2. System Center Orchestartor – The Future Ryan Andorfer @randorfer Scorch.codeplex.com #MMSMinnesota #MMSPOSH #MMSSMA

3. Session Goals and Takeaways Goals Understand the Microsoft Automation landscape today. Learn how the product team envisions using the stack of products to deliver value Review Roadmap for automation going forward Takeaways The Microsoft automation stack currently contains three products Orchestrator – Software acquired in 2011 that assists with graphical automation Service Management Automation (SMA) – Software developed in house for automation Azure Automation – SMA delivered in public azure The unification strategy for these products in a vNext timeframe

4. Where we are today

5. Two Automation Engines System Center Orchestrator Uses the Opalis Engine from acquisition in 2011 Graphical Design layer for drag and drop automation Extend and integrate to systems using Integration Packs (.NET Development) Service Management Automation (SMA) Uses a PowerShell based engine PowerShell workflow based authoring Extend and integrate to systems using PowerShell Modules Azure Automation SMA in the cloud Can be thought of as a vNext preview for SMA

6. Orchestrator Integration Packs System Center Integration Packs Operations Manager Data Protection Manger Configuration Manager Virtual Machine Manager Service Manager Datacenter Integration Packs Active Directory VMWare vSphere IBM Netcool HP Operations Manager HP Service Manager HP iLO & OA Azure Exchange FTP SharePoint 3 rd Party Integration Packs OEM Integration Packs Hardware Partner IPs Partner IPs for 3 rd party systems Community IPs on codeplex

7. Orchestrator Demo

8. Service Management Automation Extensions – PS Modules Each Microsoft product team is responsible for writing modules for their owns system (and they do it pretty well) http://www.microsoft.com/cec/en/us/cec-overview.aspx This is why even in Orchestrator we almost always used run.net script and PowerShell. We now have support for PowerShell v4 and 64 bit modules!

9. SMA Demo

10. Where we are Going

11. The Microsoft Story for Investment

13. vNext (Over the Next year) One single tool Feature Set User Interface Web Portal (Windows Azure Pack) with RBAC Authoring Graphical & normal PowerShell Engine PowerShell Workflow Integration PowerShell module based

14. Migration Tools Integration Packs Suggest moving to native PowerShell modules Can use tool to convert Orchestrator IP into a PowerShell module Runbooks Migration tool to export Runbooks from Orchestrator and attempt to import to new system Some fix up of Runbooks required My guess is probably quite a bit. Difficulty is that we are moving from a 32 bit Opalis engine to a 64 bit PowerShell engine

15. What does this mean to mean – New to Automation Service Management Automation is a highly available PowerShell based automation tool You can be very successful with it today Lots of examples online on how to automate processes

16. What does this mean to mean – Orchestrator User Limit usage of integration packs Use run.net scripts as much as possible Continue to break down work into small pieces (contained in Run.net Scripts) Consider implementing SMA and doing new work there In vNext we will have a set of utilities to assist in migration to the new platform Continuing to do work in Orchestrator creates work you will need to migrate so make sure you need the features / functionality

17. Orchestrator and SMA Demo Time

18. Road Map System Center 2012 / SP1 Orchestrator Released replacing Opalis Heterogeneous solution with integration packs System Center 2012 R2 Updated Orchestrator Integration Packs Released Service Management Automation Azure Automation Released SMA in public Azure. Branded Azure Automation now in GA Multi-Tenant support vNext Single Automation solution across cloud and on-prem (cloud consistency story) Graphical Authoring support PowerShell workflow based Tools to convert Integration Packs to PowerShell Modules

19. Questions?

20. Generic Title Page Sub Header