Colecting Certificates form an Enterprise CA for use with DSC

In a domain environment auto enrollment can be used to get create unique certificates for each node that can be used with DSC.  The problem is getting the public cert to the machine that creates the DSC MOF files. I wrote a module last year to collect them directly form the Enterprise CA. If it interests you take a look https://blog.bladefirelight.com/nuggets/collecting-ca-certificates-for-dsc-configuration/

Do Anything in One Line of PowerShell

PowerShell provides a tremendous boon to productivity for computer professionals of all types. But, you have to admit: it can be a bit daunting to get up to speed! Indeed, as someone who has a fair amount of experience using it, I still find myself having to look up how to do things–frequently. So I started keeping track of the recipes I was using the most. And came up with a list of 400 or so, published in 4 parts.

DevOps: A Career Changer

Once upon a time, there was this woman at a TechMentor conference a few years ago, sitting in the front of the room during the “Don and Jason" show, a not-quite-scripted discussion on various “lightning” topics.

The topic at that moment was DevOps, and this woman was asking for advice on being an advocate for DevOps in her company.

Her company had just been acquired, she explained, which meant that the atmosphere was ripe for change, but the culture of the company they had been acquired from was very change-resistant.

Pester – Parameters and Hashtable Fun!

I have written a short excerpt on how to pass parameters from an object to a Pester test. I have turned this into a function: Invoke-POVTest.
The function is primarily for operational validation tests, where you might have a single operational test but you need to test multiple cases. (Sorry, I am not quite sure if I described it properly).
I’ll be interested in any feedback.

Link to blog post here.

UPDATE / Tug: The Open-Source DSC Pull Server

If you haven’t taken a look at Tug, now’s a great time. Eugene Bekker has been doing a ton of heavy lifting, taking my .NET Core proof-of-concept code and turning it into a formal ASP.NET MVC project.

The Key to Understanding PowerShell – on Windows or Linux

I’ve listened to a few of my Windows-friendly compatriots attempting to explain PowerShell to their Linux colleagues, and it hasn’t always gone well. The problem, I think, is that a lot of Windows folks don’t actually know why PowerShell exists in the first place. Let me explain.

PowerShell Gotchas

You can certainly find a number of articles around that present PowerShell pitfalls that can easily trip you up if you are not careful. I took a different approach in my three-part series, A Plethora of PowerShell Pitfalls.
The first two parts are presented in quiz format, together covering the top 10 “gotchas”. They will help you test your awareness to see if you even realized the danger and did not know you’ve been skirting those traps for awhile. After you’ve had an opportunity to consider the conundrums presented, I then go into detailed explanations for why they happen and how to fix them.
The third and final part is a compendium of all the common “gotchas” that I put together after reviewing all the other lists out there. The more than 35 entries in the list cover, I believe, a good 98% of the issues you would likely encounter. Yes, there are more esoteric pitfalls as well, but I ran out of web page… 🙂
Part 1: Pesky Parameter Problems
Part 2: A Portion of Potential Puzzles
Part 3: The Compendium

The Flavors of Windows Containers

I had a wonderful conversation with some team members around Windows Containers generally, and they had some very cool analogies that I don’t think have been publicized enough. There’s some good technical detail, too, which I think is worth understanding as we move into this brave new world of containerization.

Pitfalls of the Pipeline

Pipelining is an important concept in PowerShell. Though the idea did not originate with PowerShell (you can find it used decades earlier in Unix, for example), PowerShell does provide the unique advantage of being able to pipeline not just text, but first-class .NET objects.
Pipelining has several advantages:

• It helps to conserve memory resources. Say you want to modify text in a huge file. Without a pipeline you might read the huge file into memory, modify the appropriate lines, and write the file back out to disk. If it is large enough you might not even have enough memory to read the whole thing.
• It can substantially improve actual performance. Commands in a pipeline are run concurrently-even if you have only a single processor, because when one process blocks, for example, while reading a large chunk of your file, then another process in the pipeline can do a unit of work in the meantime.
• It can have a significant effect on your end-user experience, enhancing the perceived performance dramatically. If your end-user executes a sequence of commands that takes 60 seconds, then until 60 seconds has elapsed he/she would see nothing without pipelining, whereas output could start appearing almost immediately with pipelining.

PowerShell provides a variety of techniques for using pipelining but it is all to easy to do it wrong, so you think you are pipelining but in fact you are not. In my article Ins and Outs of the PowerShell Pipeline, I discuss the most common things that can trip you up with implementing pipelining and how to avoid them.

No "Easy" Button for Configuration Management

A discussion in one of my Slack channels caught my eye today around someone’s reflections in a github repo regarding DSC. The posted comment that introduced the link was titled “DSC from a newbie perspective”, and I thought “Oh? I’m a newbie too, I wonder if we’re thinking the same things.”
A little history is probably needed on my “newbie” status with DSC. I went to the Tech Mentor conference in March, where I spent most of my time in sessions learning DSC. I was hooked, but knew I needed much more in-depth training to make it something that would be useful to me in the real world. So I set a goal of learning DSC in depth about 4 months, so that I could attend DevOps Camp in August, and be able to converse intelligently about DSC, Configuration Management, and DevOps in general. And with some help from friend and mentor Jason Helmick along with blood, sweat, tears, and 10-15 extra hours a week spent on just DSC, I made it to DevOps Camp and managed to follow along and join in the discussions.
I’ve got about 6 months of DSC experience under my belt at this point, but I still consider myself a “newbie” in the grand scheme, so I fell hook, line, and sinker to go check out the comments here:
https://github.com/18F/azure-sandbox/blob/master/dsc/README-dsc.md
I’m not an expert in Chef, so I won’t comment on the comparisons between the two. But while two weeks may be long enough to do a quick comparison between a product you know something about (in his case, Chef) and a product you are vetting against it (DSC), it isn’t nearly enough time to come to a conclusion like “DSC is too immature to even consider as a stopgap”.
Reading on, the reasons for liking/hating DSC seem to be the reasons for hating/liking Chef. Not wanting others to need to deal with learning Ruby was mentioned as a plus for DSC.  But it also seems like the poster wanted or expected DSC to be easy so that folks didn’t have to learn Chef, and was disappointed that it wasn’t.
There’s no “easy” button - if there really were an easy button for automation and configuration management, we’d have all the resources ever wanted neatly packaged and consumable, but the building of the platform and the tooling surrounding the platform takes time, people, and effort. So build and submit a High Quality Resource Module, or fork and fix some of the “awful error tracking”.  Some of these comments and feedback are really quite legit – but the points that need to be made and worked on are lost under the lamenting that DSC doesn’t have an Easy button.