PhillyPoSH 03/06/2014 meeting summary and presentation materials

Fri, 14 Mar 2014 01:57:16 +0000

Bartek Bielawski gave a presentation entitled “OMI : PowerShell Everywhere”. During his talk Bartek discussed and gave examples of how to CIM cmdlets and CDXML commands to manage everything in your datacenter. A copy of his presentation materials are available on our GitHub Repository.
- We then had a script club where various members presented scripts they were working on
- A recording of this meeting has been posted to our YouTube channel; please note that there are some audio issues near the end of the recording.

The DSC Conversation Continues

Wed, 05 Mar 2014 18:58:37 +0000

Somelovely 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.

The point is that, until PowerShell, there were no PowerShell commands. Microsoft was incredibly inconsistent about providing automation-friendly commands of any kind. They could have gone down the path of building command-line tools for Cmd.exe; they didn’t. The point of PowerShell is that Microsoft forced themselves to build commands. Now, if you run those from AutoIt, or Puppet, or whatever else - that’s cool. PowerShell is an API, not a tool. Whatever tool you use to access that API is just dandy. Without the API, the tools are useless.

As to DSC - I’m really confused. Why is this separate from Group Policy again? Why is it better? Or is MS giving up on Group Policy as needing a total re-write?

The advantage of Group Policy over DSC, today, is that GP has richer ability to target computers based on OU membership, WMI criteria, etc. Today, DSC targeting isn’t that flexible. On the other hand, GP is extremely difficult to extend, since client extensions are native code. GP was built to manage the registry, although it’s been extended to do more. DSC is built to do whatever PowerShell (and, via CIM, native code) can touch. My opinion? Yeah, DSC will obviate GP over time. Not instantly.

Specifically, as I’ve been rolling out Puppet across Windows and Linux, I see that in some ways, it brings the computer GPO aspect to Linux, and duplicates it a bit on Windows.
Anyway, I won’t be surprised to see someone start writing DSC modules in Puppet, because you’ll want your config management to work across your platforms. And MS is kind of late to the game here - many many people have lots of knowledge already in Puppet, Chef etc…

The guys on the PowerShell team love Chef and Puppet. I think you’re confusing “api” and “tool.” There are two pieces to DSC: Piece one is the ability of PowerShell to read a configuration script and produce a MOF. Piece two is the ability of a Windows computer to receive that MOF and reconfigure itself accordingly. Any tool can do piece one. Use Puppet to produce the MOF. Use Puppet to control which MOFs get sent where. That’s the _intent. _But Microsoft takes a big burden off the Puppet developers by having Windows _know what to do with the MOF. _Yeah, MS is late to the game. No question. But they’re joining the game, not reinventing it. What they’re doing works with what everyone else is already doing.

I would personally carry the sentiment even further and say that investing the bulk of your effort in DSC over something like Puppet would be needlessly tying your own hands. Why focus on something that’s platform specific when there is a good cross-platform alternative. Don’t put all your eggs in one basket as it were.

Wrong. It isn’t an either-or thing. DSC’s introduction at TechEd 2013 included a demo of Puppet (or was it Chef?) being used to send configurations to Windows - much more easily, because with DSC, Windows natively knew what to do with them. If you’vegot tooling like Puppet, _use it. _DSC is just making Windows work better with it. The whole point of DSC is that it plays the cross-platform game everyone else has already been playing. _
Purely on the Windows side, the need to focus on DSC is more about developing the DSC resources you need, so that you can send a MOF (from Puppet, say) to a Windows computer, and that Windows computer will know how to configure everything you need configured. Microsoft will continue to produce resources for core OS and server application stuff; any LOB stuff is what you’d be focusing on.
Heck, even in a pure-Windows environment, with cross-platform off the table, Puppet provides tooling _that DSC does not. You’re going to need those tools, whether it’s Puppet, some future System Center thing, or whatever. DSC is a mid-level API, not a tool.

Configuration managment does seem to be the future – I just don’t agree completely with the author’s point of a view that it will have to be DSC.

On Windows, DSC will be the underlying API that your configuration management tool talks to. DSC isn’t a configuration management tool. DSC bridges the gap between a text-based MOF and the bajillion proprietary protocols MS uses internally in their products. Remember, on Linux, it’s easier - everything already lives in a text file of some kind, right (oversimplifying, I know, but still)? In Windows, config information lives everyplace; DSC’s main job is to bridge the gap. DSC doesn’t provide management of what configuration goes where; it just provides the implementation mechanism. In PowerShell, there’s a primitive ability to write configurations, because MS has to give you something, but yeah… I think most organizations would benefit from good tooling atop that.
I think this entire discussion is why more people need to startlearning (not necessarily using) DSC if you have Windows in your environment. Find out what it is, what it isn’t, and how it’ll play into the other efforts you’ve got underway. There’s a ton of misconception about what it is and where it’s meant to fit in. When I say, “if you’re not learning DSC, you’re screwed,” I don’t mean, “if you’re not using DSC.” I mean _learning. _Because if you’re not _learning _it, you’re going to be subject to the same misconceptions about it. You end up spending a lot of time reinventing what it’s willing to do - and what it’s willing to do in conjunction with your existing tools.

]]>

Jobs: PowerShell Scripter Wanted

Wed, 05 Mar 2014 14:47:19 +0000

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

The DSC Opportunity for ISVs

Tue, 04 Mar 2014 23:45:02 +0000

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.

Charlotte PowerShell User Group Meeting cancelled this week 3/6/14

Tue, 04 Mar 2014 04:00:28 +0000

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.

]]>

Articles from March 2014 on PowerShell.org - Welcome Automaters!

April 3, 2014 Virtual PowerShell User Group meeting

Code from this week's Oslo class

We Want Your DSC Resource Wish List!

Going Deeper on DSC Resources

How Granular Should I Get?

My DSC Demo-Class Setup Routine

Building Desired State Configuration Custom Resources

The High Points

PhillyPoSH 03/06/2014 meeting summary and presentation materials

The DSC Conversation Continues

Jobs: PowerShell Scripter Wanted

The DSC Opportunity for ISVs

Charlotte PowerShell User Group Meeting cancelled this week 3/6/14

Articles from March 2014 on PowerShell.org - Welcome Automaters!

April 3, 2014 Virtual PowerShell User Group meeting

Code from this week's Oslo class

We Want Your DSC Resource Wish List!

Going Deeper on DSC Resources

How Granular Should I Get?

Very, Very Granular

Unless…

My Recommendation

What Should I Validate?

What should I return?

What’s left?