Desired State Configuration is a very new technology and declarative configuration management is a very young space yet. We (Microsoft and the community) are still figuring out the best structure for resources, composite configurations, and other structures.
That said, there are certain viewpoints that I’ve come to, either from hands on experience or in watching how other communities (like the Puppet community or Chef community) handle similar problems.
How Granular Should I Get?
There is no absolute answer.
I think I’ve gotten my DSC classroom and demo setup ready. Understand that this isn’t meant to be production-friendly - it doesn’t automate some stuff because I want to cover that stuff in class by walking through it. But, I thought I’d share.
I’ve basically made an ISO that I can carry into class, attach to a Win2012R2 VM and a Win81 VM, and run students through. The server VM is a DC in “company.pri” domain, and the client VM belongs to that domain.
In the root of the ISO are these scripts: ISO_Root (unzip that). Students basically just open PowerShell, set the execution policy to RemoteSigned or Unrestricted, and then run SetupLab -DVD D:, replacing “D:” with the drive letter of the VM’s optical drive. The script isn’t super-intelligent since I demo it at the same time; it needs the colon after the drive letter.
In a folder called DSC_Modules, I add the following DSC modules (unzipped): xActiveDirectory, xComputerManagement, xDscDiagnostics, xDscResourceDesigner, xNetworking, xPSDesiredStateConfiguration_1.1, xSmbShare, xSqlPs, xWebAdministration.
In a folder called DSC_Pull_Examples, I include these scripts: DSC_Pull_Examples (unzip that).
In a folder called eBooks, I include these files: eBooks (unzip that). Those get used in a lot of the demos I do, so I have the lab setup scripts copy over some script modules.
In a folder called Help, I have a file called Help.zip. This contains everything downloaded by the Save-Help command in PowerShell. The Setup script unzips this into the VM and then runs Update-Help against it, so the VM doesn’t need to be Internet-connected.
In a folder called Hotfix, I have the Windows8.1-KB2883200-x64.msu hot fix installer. I include the 32-bit version also, just in case, but my script doesn’t use it.
In a folder called Installers, I have installers for PrimalScript, PowerShell Studio, and SQL Server Express with Advanced Services. Again, those get used a lot in my classes, but the setup script doesn’t rely on them.
Finally, in a folder called sxs, I have the contents of the Windows 8.1 installation media’s \Sources\sxs folder. Some of the things my setup script does - like adding .NET Framework 3.5 so SQL Server 2012 will work - rely on features that aren’t in a Win8.1 VM, normally. Because I don’t want to rely on the Internet, I include this source so I can install new features from it.
This is all pretty specific to the way I run classes, but if there’s any use you can make of it, feel free.
Now that we’ve suitably rested, let’s get back to working with Desired State Configuration. Now, there are some basic features to work with that ship by default and the PowerShell team has been blogging some additional resources, but in order to do some really interesting thing with DSC, we’ll need to create our own resources.
The High Points
The DSC Resource Structure
DSC resources are (at their most basic) a PowerShell module. These modules are augmented by a schema.mof file (we’ll get into that more in a minute or two). These modules expose three main functions, Get-TargetResource, Set-TargetResource, and Test-TargetResource. All three functions should share the same set of parameters.
Some lovely conversation on DSC over on Reddit… with some I wanted to perhaps offer an opinion on. From what I’ve seen, these are very common sentiments, and they definitely deserve… not argument or disagreement, but perhaps an alternate viewpoint. I’m not suggesting the commenters are wrong - but that maybe they’re not considering the entire picture.
Certainly if you work with a superset of MS OSs (i.e. you do Linux also), then Puppet or something like it seems like a no brainer. In fact, that is what we’re doing now. Puppet has powershell modules you can install for instance. Personally, I still feel like Powershell is overrated except for small snippets of that’s how something is exposed. Puppet can run powershell commands. AutoIT can run powershell commands… I just don’t see value in Powershell today.
Told you this would eventually start happening ;). Matt Sullivan of Strategic Staffing contacted me with the following job posting; if you’re interested, reply to him directly at 781-347-5220.
…
My name is Matt Sullivan and I am a member of the Strategic Staffing Division at NTT DATA Inc., the sixth largest global IT integrator. We have more than 75,000 employees worldwide, offices in 40 different countires, and we are owned by Nippon Telegraph and Telephone, the largest telecommunications company in the world.
I am currently seeking a Scripting Engineer - PowerShell to join our team in Burlington, VT. The job description can be found below for your review. Please note that your resume will not be submitted to the client until we have discussed your background.
Title: PowerShell Scripter
Location: Burlington, VT
Duration: 1 year
Our Client has a number of projects in flight that require scripting (PowerShell) as part of their automation solution in our Windows environment. This position would require that the contractor meet with other project members, to gather requirements, build, test and document the scripts. He/she will then hand this work off to another vendor to be implemented on the scheduling platform (BMC’s Control-M, a SaaS hosted by Client).
As a second priority, the contractor will work with various departments, to examine an existing body of scripts/jobs which also in our Windows environment. These jobs, having been prioritized by the client, will be converted, if necessary, to PowerShell, tested and documented before being turned over to Client. This body of work is not expected to be completed in the time allotted as it is very large. Our goal is to address as many as possible working from the highest priority down.
PowerShell is the scripting language of choice. A few years at a minimum is required including experience with .NET remoting.
Expert level in Powershell
3+ years experience
Powershell V2 and/or V3
Solid understanding of Powershell Remoting
Business Analyst skills
Experience in requirements gathering
Testing methodologies, test plan development
Strong documentation skills
We are dedicated to working with a wide range of IT consultants, as an example corp to corp and W-2 hourly contractors; and we offer competitive benefits for candidates applying as W-2 contractors.
Benefits available for W-2 contractors only:
Medical
Dental
Vision
Caremark Prescription
401(k)
W-2 Employee Assistance Program
Accident Insurance- Workers’ Compensation Insurance and Business Travel Insurance
COBRA
Healthcare Reimbursement Account Programs
Credit Union
Corporate Mortgage Program
Desired State Configuration offers a number of immediate opportunities for independent software vendors (ISVs) who are smart enough to jump on board _now. _DSC currently suffers from a marked lack of tooling. That’s partially deliberate; MS obviously needs to deliver the functionality, and they may well rely on third parties or the System Center team to build tools on top of that functionality. But let’s explore some of the immediate opportunities.
Change Control and Versioning. This should be pretty easy. We basically need a way to “check in” a new DSC configuration, possibly have it go through an approvals workflow, and then deploy it. In more detail, I’d want to be able to submit a configuration script to this tool. It would run the config, generate a MOF, and deploy it to a “lab” pull server location. I could then verify its functionality, and “approve” it to deploy the MOF to a production pull server. Deployment would include creating the necessary checksum file. Obviously, rollback capability to a previous version would be nice.**
**
**Configuration Consolidation. **Natively, DSC requires me to specify the nodes I want to push a configuration too. I’d like to see a tool that lets me create server lists somewhat graphically, organizing things so that a single server might appear in a “domain controllers” list, a “New York servers” list, and a “Win2012R2” list. I could target configurations at each list, and the tool would combine those configurations to create the appropriate one for each node based on its “folder memberships.” That might be done through composite resources. This makes DSC work a bit like GPO, with this tool doing the work of combining configurations into a single one per node.
**DSC Studio. **Using the underlying DSC Resource Kit and Resource Designer for functionality, give me an IDE that lets me graphically design a resource (specify properties) and then spit out the schema MOF and skeleton PSM1 file. This could probably be a very simple PowerShell ISE add-on, in fact.
**Node management. **In a pull server environment, give me a tool that lets me group servers. The tool should modify the LCM on each group, so that each member of the group has the same DSC configuration ID. That way, they’re all pulling the correct MOF from the pull server. Otherwise, managing GUIDs gets out of hand pretty quickly - I can see a lot of Excel spreadsheets.
Resources. There are obviously a ton of resources to be written. This might be a bit of a bad call for an ISV, as you never know what MS is going to release resources for. Now that MS has built so many PowerShell cmdlets, building resources on top of them gets pretty straightforward. They’ve pumped out two waves of resources pretty fast already.
In short, I think there’s a big opportunity for a smart company. It’s a matter of seeing the “holes” in the technology, which currently focus mainly on management, and filling them in.
Sorry but we have to cancel the User group meeting this month in Charlotte on 3/6/14 we will meet again on April 3, 2014.
This Thursday, Feb 27, 2014 join us with guest, Nick Howell, (@that1guynick) from NetApp as the discussion will be software defined datacenter. See you at 9:30PM EST
This post comes to us from Julie Andreacola, one of the members of team Kitton Mittons, who won The Scripting Games - Winter 2014. You’re welcome to submit your thoughts about the Games as well!__
The 2014 Scripting Games are over and once again, it was a terrific experience. This was my third scripting games and I was blown away with all that I learned.
The team approach was very appealing to me as I have been the PowerShell expert at my workplace so I was hoping to find a team where someone knew more than I did as I’m only intermediate in PowerShell skills. I struggled to put a team together from our local PowerShell user group for the practice event, but it just didn’t work out due to the timing and workload of potential team members. I took to Twitter to find a team that had an open spot and found the Kitton_Mittons.
The team was just what I needed. We had no expectations to win and we acknowledged that some weeks, people would not be able to participate. All of the team, but myself was located in Northern Virginia, so we arranged for a Google Hangout each evening around 7 p.m. We also had a shared repository on GitHub. Both of these tools were new for us, but were invaluable for our team collaboration. I think we only had one night with everyone in attendance. The sessions varied from discussion of elements of the script, screen sharing (nice Google Hangout feature), and general geek conversation. Two of the team traveled to Charlotte NC to join me in PowerShell Saturday 007 where we met and gained another team member for the final few events.
The learning benefits happened immediately. The first week I learned more about parameters and using them to validate inputs. I immediately began implementing them in my scripts at work, making them more robust and easier to hand off to others as I was transitioning to a new job. A couple days later, our team made our first module. I knew it was easy, but had never done it and now my script at work had a module. One of our team members made an install script that put the files and modules in the correct places. I realized the advantage of this especially when turning scripts over to users unfamiliar with PowerShell. I was able to take the same installer script and quickly customize for use in my workplace. The following weeks included getting more experience with efficiencies of script blocks and better error checking. Although many of my evenings were being taken up with PowerShell, I found the nightly sessions invaluable as our team leader, Jason Morgan, took the time to teach and explain the more complex aspects of the scripts.
The 2014 Scripting Games exceeded my expectations and truly advanced my skills. I also have a new network of System Center IT Pros. I’m starting a new job this week and I know what I learned and gained over the last 4 weeks will help me to excel in this new position. A big thank you to my team mates, coaches, judges, and the PowerShell community. Learning can be fun!
