{"id":983,"date":"2012-05-30T12:09:00","date_gmt":"2012-05-30T12:09:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/windowsserver\/2012\/05\/30\/windows-server-2012-powershell-3-0-and-devops-part-2\/"},"modified":"2026-06-26T09:00:28","modified_gmt":"2026-06-26T16:00:28","slug":"windows-server-2012-powershell-3-0-and-devops-part-2","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/windows-server\/blog\/2012\/05\/30\/windows-server-2012-powershell-3-0-and-devops-part-2\/","title":{"rendered":"Windows Server 2012, PowerShell 3.0 and DevOps, Part 2"},"content":{"rendered":"\n
This concludes my two part series. In my first post, I provided some background information about PowerShell and DevOps. In this post, I\u2019ll provide you a bunch of specifics. PowerShell 3.0, like Windows Server 2012, has a ton of new features and enhancements so I\u2019ll only scratch the surface. <\/em><\/p>\n\n\n\n While PowerShell has always been focused on the goals of DevOps, PowerShell 3.0 and Windows Server 2012 take this to a new level. With Windows 2012, we shifted our focus from being a great OS for a server to being a cloud OS for lots of servers and the devices that connect them whether they are physical or virtual, on-premise or off-premise. In order to achieve this, we needed major investments in:<\/p>\n\n\n\n Automating Everything<\/span><\/strong><\/span> There are already a large number of hardware and software partners that are shipping PowerShell cmdlets and those that haven\u2019t released them yet are working to quickly deliver them in the next versions of their products. This was very clear at the recent MMS conference in Las Vegas and I think you\u2019ll see even more support at TechEd. You should definitely make sure that any product you buy delivers a full set of PowerShell cmdlets. If it doesn\u2019t, you should think twice and do some due diligence to make sure you are getting a product that is current and is still being invested in. If they didn\u2019t do PowerShell, what other things they missing? The good news is that a lot of the products will support PowerShell by the time Windows Server 2012 ships and that the products that have delivered cmdlets found it easy to do and mention the very positive customer feedback they get. EVERY product that ships PowerShell cmdlets, increases their investment in PowerShell in their next release.<\/p>\n\n\n\n Robust and agile automation<\/span><\/strong><\/p>\n\n\n\n Workflow<\/strong><\/span> Operators can use any of the available Workflow designers to create workflows. However we took it a step further and simplified authoring by extending the PowerShell language with the workflow<\/strong> keyword. Any operator or developer can now easily author a workflow using the tools that ship in all Windows SKUs. The behavior of a workflow are different than a function and it has a few more rules but if you know how to write a PowerShell function, you are 80% of the way to being able to write a workflow. Authoring workflows using PowerShell is much easier than working with XAML and many of us easier to understand than Workflow designer tools. You also get the benefit of being able to paste them into email and have someone be able to read\/review it without having to install special tools. Below is an example workflow which operates on multiple machines in parallel collecting inventory information in parallel on each of the machines.<\/p>\n\n\n\n <\/p>\n\n\n\n The command below will get this inventory information from a list of servers contained in servers.txt and output the results to a file. If any of the servers is unavailable, the workflow will attempt to contact the server every 60 seconds for an hour.<\/p>\n\n\n\n <\/p>\n\n\n\n Workflow is exactly what DevOps practitioners need to reliably and repeatably perform operations. One of the key techniques of DevOps is A\/B testing<\/a> where two versions of software are deployed and run for a period of time. They are measured against some goodness metric (e.g. increased sales) and then the winning version is deployed to all machines. The workflow capabilities allow PowerShell to perform operations against a large number of machines over a large period of time making it easy to automate A\/B testing.<\/p>\n\n\n\n\n
Windows Server 2008\/R2 shipped with ~230 cmdlets. Windows Server 2012 beats that by a factor of over 10 shipping ~ 2,430 cmdlets. You can now automate almost every aspect of the server. There are cmdlets for networking, storage, clustering, RDS, DHCP, DNS, File Servers, Print, SMI-S etc. \u2013 the list goes on. If you\u2019ve read blogs about Windows Server 2012, you\u2019ve seen how many things can be done using PowerShell. If you haven\u2019t kept up to date, check out Jose Barreto\u2019s File Server blog posts, Yigal Edery\u2019s Private Cloud blog posts, Ben Armstrong\u2019s Virtual PC Guy\u2019s Blog posts, the Clustering and High-Availability blog posts or Natalia Mackevicius\u2019 Partner and Customer blog posts and you\u2019ll see what I mean. Windows Server 2012 is, by far, the most automatable version of Windows ever.<\/p>\n\n\n\n
We integrated the Windows Workflow Foundation<\/a> engine into PowerShell to make it simple and easy to automate things that take a long time, that operate against a very large scale, or that require the coordination of multiple steps across multiple machines. Traditionally Windows Workflow has been a developer-only tool requiring visual studio and a lot of code to create a solution. We\u2019ve made it an in-the-box solution that operations can easily create a solution using their existing PowerShell scripting skill. Workflow provides direct support for parallel execution, operation retries, and the ability to suspend and resume operations. For example, a workflow can detect a problem that requires manual intervention, notify the operator of this condition and then suspend operations until the operator corrects the situation and resumes the workflow.<\/p>\n\n\n\n
<\/figure>\n\n\n\n
<\/a><\/figure>\n\n\n\n