Extend PowerShell DSC with Operations Management Suite

Summary: Learn about extending the capabilities of PowerShell Desired State Configuration with Microsoft Operations Management Suite.

Good morning everyone, Ed Wilson here. So Monday Teresa (aka ScriptingWife) and I were in Manchester for the PowerShell user group meeting and yesterday we were in London for the WinOps conference. Today, we are still in London doing a post conference Azure day, and tomorrow we are speaking to the London PowerShell user group. I thought I would take a few minutes to talk about using Microsoft Operations Management Suite (MS OMS) to extend Windows PowerShell Desired State Configuration (DSC).

The thing is, that as I begin to use DSC to help me to optimize and to extend my investments I need to be able to integrate my new systems with my existing systems. I can use Windows PowerShell modules and DSC resources to help me to manage all of this. So, I spend time and money writing a lot of PowerShell scripts that contain modules, and that perform various tasks and now everything is working beautifully.

But then I also need to be able to automate things by using workflows to create a series of steps that need to occur in order, or for steps that can occur at the same time. And I need to be able to specify that I want certain configurations to be set in a specific way. I need to make sure my services are reliable, and that the services they rely upon are also available. I need to be able to manage this and still permit departments to manage their own systems. At the same time, I need to improve system uptime, reduce potential configuration errors and ensure that as I bring new systems online they are also configured the same way as other systems that perform the same functions. This becomes more critical as I attempt to scale up and down based on demand and as I move services to the cloud.

OMS automation permits me to use PowerShell scripts to automate complex end to end processes. I can do this with Runbooks that I can run on demand, run immediately, or that I can schedule to run at a later time. Once I have the PowerShell script in the runbook, I can basically do anything I want to do with that runbook.

I can also use my PowerShell DSC configurations to enforce how my machines are configured. So because of this, I can reuse my previous investments in PowerShell … either as runbooks, or as DSC.

A huge advantage of OMS Automation is that I have a centralized store that is available with my Azure automation account. In this centralize secure store, I can store credentials, certificates, variables, connections, PowerShell modules, PowerShell DSC resources, draft versions and published versions of my scripts, as well as schedules. This makes it easy for me to manage many many systems without having to worry about moving pieces of my automation solution around the network … wherever it may exist. To highlight what a huge win this is, just think about how many times you wanted to give permission for a low level technician (or user) to run a PowerShell script that required elevated permissions but you did not want to share the credentials to that user that the script required – no more storing credentials on a network share, or in the script.

OMS automation provides a highly available, scalable and manageable solution that creates an execution environment for PowerShell. In addition, we get a PowerShell DSC Pull / Reporting server that just simply works. There is also a REST API, C# SDK, PowerShell cmdlets and even a portal that can be used to manage all aspects of the OMS Automation service.

In addition we get historical analysis of our PowerShell environment. I can see at an instance a historical view of the runbook job executions, view the runbook version that was used for each job, and get both a high level and a low level view of DSC node compliance … both as it exists now, and as it existed in the past.

So, by using OMS automation, I basically get PowerShell as a service … and it is a service that solves many problems that have perplexed me over the past several years. It is way cool.

That is all I have for you today. Join me tomorrow when I’ll talk about using PowerShell in automation runbooks.

I invite you to follow me on Twitter and the Microsoft OMS Facebook site. If you want to learn more about Windows PowerShell, visit the Hey, Scripting Guy Blog. If you have any questions, send email to me at scripter@microsoft.com. I wish you a wonderful day, and I’ll see you tomorrow.

Ed Wilson
Microsoft Operations Management Team