DSC ConfigurationData Blocks in a World of Cattle

As you may know, Jeffrey Snover and I have, for some time, been on a “servers are cattle, not pets” kick. Meaning, servers shouldn’t be special, individualized snowflakes. They should be, in many regards, appliances. One dies, you eat it and make another. They don’t have names - that you know of. They don’t have IP addresses - that you know of. Oh, I mean, they have them, but you don’t know them and don’t care.
Anyway, one thing that came up in a recent conversation related to DSC’s ConfigurationData blocks. Have a look at the MSDN documentation and tell me what you see.
Go on, I’ll wait.
You see **NodeName. **But damnit, if servers are cattle and cattle don’t have (known) names, what the dude is NodeName all about?
Well, for one, it was a poor choice on the team’s part. I’d have called it - and this is giving away the punchline - **NodeRole. **Imagine that your “NodeName” was “SalesAppWebServerRole.” When you run your configuration script, you get a MOF named SalesAppWebServerRole.mof, right? Which you then checksum and load onto a pull server. And when you’re spinning up a new server to host that role, you tell its LCM to grab the ConfigurationName “SalesAppWebServerRole.”
The server, when spinning up, makes up a name for itself. Charming, right? Cows think they have names. Sweet. Don’t care. It gets an IP address for itself, partially from DHCP of course, and partially by making up the other necessary IPv6 stuff (oh, and IPv6 is a thing now, so get on board).
Then, presumably, it runs to the pull server, grabs the MOF, and starts a consistency check. During which, presumably, _it registers some known name with DNS or load balancer or something. _Now you know it’s “name!” Or the name you want to call it by, at least. Also presumably, your load balancer knows to remove or suspend the entry if the host stops responding, and to periodically scavenge stale records (remember, the node’s own LCM will make sure its entry gets put back, on the next consistency check run). So if the node dies and you spin up a new one, the rest of the affected infrastructure - DNS, load balancers, what have you - clean themselves up automatically (and DSC could be involved in that process, too).
Anyway… the point is that ConfigurationData blocks can absolutely be used for cattle farms, not just for pet shops. “NodeName” is a misleading setting, but if you think of it as a role, which could be applied to multiple actual machines, then it makes a lot more sense that way.

A Practical Guide for Using Regex in PowerShell

Regular Expressions is often referred to as wizardry or magic and for that reason I stayed away from it for most of my career. I used it only when I had to and most of the time just reused examples that I found online. There’s nothing wrong with that of course, but I never took the time to learn it. I thought it was reserved for the elite. Turns out that it’s not that complicated and that I had been using it for years without knowing it.
In an effort to shorten the learning curve for others and to show you the value of learning regular expression I’ve written a blog post titled A Practical Guide for Using Regex in PowerShell. It will walk you through how to use regular expression in PowerShell and gives you a glimpse into how powerful regular expression is.
Below is an example of how to use regular expression to extract a user’s name from their distinguished name in Active Directory. To learn more check out this blog post.

Topics Covered

PowerShell + DevOps Global Summit 2017 Preview

As a quick reminder, our Call for Topics is still open for a few more days! Summ. Summit is very much intended to be a kind of mega-user group, not a “conference,” so don’t assume all the “professional” speakers have taken up all the speaking slots. We want you to participate!
In the meantime, while we’re waiting on the content committee to select topics and before registration opens in early November, I wanted to offer a peek at what we’re planning.

Nearing Last Call for PowerShell Summit Topic Proposals (+ Topic Ideas!)

Remember that our Call for Topics is still open until the end of September, if you’d like to submit. And, from our Summit Alumni Slack channel, here are a few things people said they’d like to see…

• I would love to see a session on what it takes to build a PKI infrastructure in support of PowerShell operations ( stuff liked passing creds with DSC ) - this is something glossed over all the time as if it is not a big deal but I think it can be quite challenging for a lot of people to implement.
• Writing for Performance: Tips and Tricks to Write Faster Code
• Compiled cmdlets - how to create them and why you might want to (this got a lot of thumbs-up)
• Open source PowerShell hackathon.  Either one multi-hour (2, 3, 4?) window where people can break into groups and work on some open source PowerShell extension, or two sessions, one at the beginning of the event and one at the end.  The one at the beginning the presenters/organizers provide a set of possible project ideas to work on, and people interested can sign up/vote for projects which creates groups.  The one at the end gives groups an opportunity to share/demo what they produced.  Having a room where people can gather to work on it would be cool.  These don’t have to be big projects.  They could be small things, like knocking off one or more issues for an open source project.  The end goal is to have a pull request submitted or a new project posted in GitHub or a new module submitted in the Gallery. _Now, to be clear, this isn’t a session - but you can definitely propose it. We have some longer time slots on Wednesday for panels, and this might be something you could do then. _
• examples of real world DSC usage - that was a comment I heard from a number of folks this year
• Practical Pipelines. ( Illustrate that release pipelines aren’t just for DevOps-practicing shops, or public-facing software )
• Build plans (and tools, like psake)
• Module design best practices (lots of thumbs-up on this one)
• Working with Open Source Projects (as a Contributor)
• Working with Open Source Projects (as a Maintainer)
• Applying Agile Software Development Methodologies to PowerShell
• Using for . (assumption: someone writes the equivalent of inspec wrapped around Pester)

And if you read the above carefully, you’ll notice that **we do also have some space for afternoon panels on Wednesday - so if there’s a group discussion you’d like to lead, propose it! **Just be clear in the description you submit that you’re proposing a panel. It’ll be up to you to recruit panel members, which you can do on-site. We’ll announce panels in need of panelists and direct them to you.

Unit Testing is “Pestering” the Hell Out Of Me

About a week or two before Devops Camp, the attendees were asked how much experience they had using Pester, because another attendee was preparing a discussion on Pester and wanted to gauge the other attendees’ comfort level. Learning Pester had been on my to-do list for a while, but I had procrastinated on it for far longer than I intended. I answered “Beginner” - although “complete and utter newbie” would have been more accurate - and I vowed to spend some quality time looking at Pester before arriving at camp.
There are some really great resources out there devoted to Pester, from beginner to intermediate to way-over-my-head. I read articles and watched videos. And I understood, in a conceptual kind of way, how to use Pester. Describe, Context, It, Mock, Assert-MockCalled – I understood what these things were used for. The examples made sense. I was ready to move on to trying it myself. But here is where I stumbled and recovered, and I would like your feedback and opinions on my discoveries.
I took a piece of code I was currently working on and decided that a small function in that code was the perfect function to attempt my first unit test on. I mean, it was the tiniest little function - 7 lines of code! What could possibly be easier? Right?
Boy, was I wrong. The struggle IS real.
In a nutshell, my function really is 7 lines – an If/Else statement and a For-loop – and inside each is an external call to an Active Directory cmdlet. Those would definitely need to be mocked. After all, we know or assume that Set-ADAccountControl and Set-ADObject do what they are supposed to. I was stumped at where to even start because after mocking these external calls – there isn’t actually anything left to the code!
Even after a wise person told me that “This probably isn’t a great example of a “Pester 101” example”, I was still determined to figure out how to write a Pester test to test this function, but I needed to set aside my thoughts of “I can’t figure out how to write a Pester test for this” and instead, start with “Figure out how to write a unit test for this.” My brain freeze wasn’t about Pester – it was about unit testing. What do I need to test? My next step was to do some reading up on general unit testing concepts.
I’m not opposed to buying a book on testing concepts, but I wanted some quick answers and not a research project just to get me started. I turned to “Dr. Google” and I found some useful definitions, both formal and informal, on what unit testing really is. But it wasn’t until I found a comment buried deep in a StackExchange forum post that I realized what my next steps were.

Here's Another Reason to Contribute

Jason Helmick and I were talking last night, and we got onto the topic of expertise and respect. Kind of, “once someone really gets to that expert level, and they surpass their teacher in knowledge, you really respect them.” I disagreed, and said, “no, I respect them the minute they start contributing to the world, and helping others.”
We all, at some stage, get “outsider syndrome,” where we think everyone else is so much smarter than us, that we’ve nothing of value to contribute. But that’s never true. First of all, there’s this thing called a “birth rate,” meaning there’s always new people coming into the field. Second, no matter what your level of expertise, you’re in it, right then. “Experts” too often forget what it was like to be a beginner; a beginner knows, and can often relate things that another beginner can understand more readily.
Take this wonderful post by Missy Januszco. Missy probably doesn’t consider herself an expert, although she certainly held her own at my recent DevOps Camp. And she certainly wasn’t the only one writing about open-source, cross-platform PowerShell Core that week. But she did it from a unique perspective, one that a lot of her readers can probably take a lot from. And she did it - instead of just talking vaguely about giving back someday, she just did, and did it well.
PowerShell.org isn’t a curated newsfeed for a select few; its yours. So if you don’t have your own place to publish and share, email webmaster@ and let us set you up to write. Whenever you solve some problem, conquer some gotcha, or have a perspective on the latest PowerShell news, share. You definitely have something to offer.

Microsoft did WHAT?

Unless you’ve been living under a rock for the last couple of days, you already know that Microsoft announced last Thursday that the shell/scripting language formerly known as “Windows Powershell” is now supported on Linux and MacOS and that Powershell has been open-sourced. And for days, thoughts of “how can I use this?” or “I wonder if ‘x’ will be supported” have been flying through the minds of every system architect as we internally grapple with the possibilities of what could be, while at the same time trying to understand Microsoft’s motivation for this radical change.
Only the change isn’t so surprising if you think about the changes that Microsoft has been making leading up to this announcement. Separating Powershell Desktop Edition and Core Edition in WMF 5.1. Announcing SQL Server on Linux – after all, IT professionals are going to need a way to administer that SQL instance and it isn’t going to be through a GUI. Supporting Powershell on Linux seemed like a logical next step.
But it is likely just a step along the road to heterogeneous system management. Microsoft Technical Fellow and Powershell inventor Jeffrey Snover isn’t at all secretive over the fact that the vision is built upon Microsoft’s Operations Management Suite (OMS), a suite of automation and management tools that needs to be able to configure, control, manage, monitor, and self-heal a workload that runs anywhere and on any operating system.
From the perspective of a system architect that isn’t typically on the bleeding edge of technology, I am still extremely excited over this announcement. Why? The possibilities seem endless. For one, applications that run on either Windows or Linux or a combination of the two can now be configured by the same language, or maybe even the same set of well-designed scripts. Second, the possibility of using Desired State Configuration (DSC), or third-party tooling such as Chef or Puppet in conjunction with DSC, means I can keep *all* servers in compliance with their configurations using the same tooling. Third, what Devops engineer wouldn’t love having spent a few years learning a scripting language like Powershell only to have its reach extended to other platforms? This change invariably makes us more valuable to the company by being able to take on additional management responsibilities by using the skills we already have. It can then lead to even more cross-platform learnings and opportunities. I definitely plan to learn more about Linux and how I can help build cross-platform tools. If you have similar interests, here are some great resources to get you started!
https://www.pluralsight.com/courses/essential-tools-red-hat-enterprise-linux
https://www.pluralsight.com/courses/linux-networking-advanced-lfce
I haven’t even scratched the surface of thinking about all of the ways I want to take advantage of Powershell on Linux, and I have lots of exploring to do to find out what can or can’t be done – but the energy of the entire Powershell community over these changes certainly carries over to me as well. I’m excited to find out what is possible, to build what may not have been possible, and to contribute back to the Powershell community. So kudos to you, “new Microsoft”, for energizing the entire community of Powershell enthusiasts. I can’t wait to see what’s next.

Why "Objects," Remoting, and Consistency are Such a Big Deal in PowerShell

As PowerShell begins to move into a cross-platform world, it’s important to really understand “why PowerShell.” What is it, exactly, that sets PowerShell apart? Notice that I do not mean, “what makes it better,” because “better” is something you’ll have to decide on your own. I just want to look at what makes it _different. _

Create Custom Monitors with PowerShell

Sometimes, as a developer, you want to be be able to keep track of free space on a drive, the size of a log, the load on your CPU, the number of users logged in, etc. With PowerShell, it is typically just a matter of finding the right cmdlet amidst the large (and rapidly growing) pool of cmdlets provided by Microsoft and by third parties. Then you just run Get-Foo to check details about the foo resource. And then you come back 5 minutes later and run it again because you want to see how it changes over time.
But wouldn’t it be nice if you could just have it run automatically at regular intervals in a separate window that you could just keep in the corner of your screen? Well, I found the barebones of just such a utility sometime ago (authored by Marc van Orsouw,  aka ‘thePowerShellGuy’). His original post is no longer available, but I expanded upon his code and, over time, added features, bug fixes, and enhancements, making it more useful and more user-friendly. Here are a few screenshots of the Monitor Factory in action.
Monitor the size of a database

Why PowerShell on Linux is Such an Accomplishment

Yesterday, Microsoft announced that Windows PowerShell - which I suppose we’ll just call “PowerShell,” now - has been open-sourced, with PowerShell Core builds being made available for various Linux distros as well as macOS.
This is a big deal, but not exactly for the reasons you might think.