Welcome to Day 5 of the “100 Days of DevOps with Powershell”! Today, I want to take a quick detour to finish up an important topic I actually started before this series actually begin.
A few weeks ago, in “PowerShell DSC: Enterprise-grade Management of Node / Configuration ID Data”, I argued that the proper way for every enterprise to store the PowerShell DSC configuration ID (GUID) associations is in their CMDB. I mentioned that which vendors CMDB you used didn’t really matter, but as the center of all knowledge around assets, configuration and IT operations activities (changes, releases, incidents, etc.), the CMDB is the place your PowerShell DSC configuration ID (GUID) associations belong.
Today, I want to briefly show you how you would extend your System Center 2012 Service Manager (SCSM) CMDB to support DSC configuration ID storage for both your Windows and UNIX / Linux computers.
With this critical piece of data in a reliable and secure location, we can move forward with an ITIL-integrated strategy to support continuous deployment.
Add a Property Windows Computer Class
To add a property to a class in your Service Manager CMDB, you will use the Service Manager Authoring Tool. If you have never before used the authoring tool or extended a class, you can find another intro article to get you acquainted here on SCC. Visit “How to extend an existing class in Service Manager” and come back to this article in a few minutes when you are done.
1) Start by launching the Service Manager Authoring Tool.
2) From the File menu, select New to create a new management pack (MP). For this example, I named my MP Configuration.PoshDSC.Contoso.
3) Find the Class Browser, and search for the Windows Computer class.
4) Right click the Windows Computer class and select Details.
5) In the Management Pack Explorer window, right click Windows Computer and select Extend class.
6) You will be prompted to select an MP in which to save your changes. Select the MP you created in step 2.
7) In the fields provided, provide a class name and description, like the example below.
8) Next, click the Create property button.
9) In the Create property box, type DSCConfigID and select Create.
10) The result is a new property for the Windows Computer class, but of a data type of String. We want a data type of GUID to support storing the PowerShell DSC Configuration ID for your servers, which is a GUID.
11) For the data type, go to the Details pane in the lower right of the authoring tool and select GUID. This is the same data type as the PowerShell DSC configuration ID you will generate for managed computers.
Save your changes. You are now ready to import your management pack into SCSM.
Import the Management Pack into SCSM
1) Launch the Service Manager Admin Console.
2) In the Administration pane, right click the Management Packs node and select Import.
3) Browse to your MP and complete the import wizard.
Now you are ready to check your Windows Computer class for the results.
Update Computer CIs
1) In the Service Manager Admin Console, go the Configuration Items pane and select the Windows Computers node.
2) Double-click on any Windows computer and select the Extensions tab. To validate your change, paste the PowerShell DSC configuration ID for the computer you selected into the field.
Mission accomplished! Now you have a proper home for this critical piece of PowerShell DSC data.
Repeating the approach for UNIX / Linux computers
Storing the DSC configuration ID for your Linux computers in the Service Manager CMDB involves completing the steps above, replacing the Windows Computer class with the UNIX / Linux Computer class. The one challenge you may encounter is that the Service Manager CMDB does not include a UNIX / Linux Computer class by default. Fortunately, we have another tutorial to show you how to add a UNIX / Linux Computer class to your CMDB to support your DevOps efforts with PowerShell DSC.
As someone who spends a great deal of time with both automation and ITIL, I advise customers on the importance of an automation strategy that does not leave ITIL behind. For continuous deployment, integration with ITIL processes like change and release management is the key to a sustainable DevOps strategy. I’d appreciate your thoughts or comments on how you approach the process aspects of DevOps in the comments section below this article.
Below are previous installments in the “100 Days of DevOps with PowerShell” series.
- Day 4: Automating Application Installation Using PowerShell Without DSC or OneGet
- Day 3: PowerShell and Team Foundation Server 2013 – Getting Started
- Day 2: How to install DSC Providers for Linux on CentOS 6.2
- Day 1: Intro to PowerShell DSC and Configuring Your First Pull Server
- Announcing the “100 Days of DevOps with PowerShell” Series