PowerShell + DevOps Global Summit 2017: Session Acceptance

We’re in the process of emailing speaker invitations to those whose sessions were accepted for the 2017 agenda. **Please check your email and promptly follow the instructions to complete registration. **
In the event that a speaker is unable to confirm their invitation in time, we will move on to other speakers and sessions - that’s why, if you haven’t presently received an invitation, you still might. Once we’ve confirmed everyone, we’ll send out notices to any speakers who were not selected, so that you’re in the loop. We do appreciate your patience as we work through this process.
Registration will open November 1st, and a draft brochure is available at http://PowerShellSummit.org. This brochure does include session highlights that may not have been confirmed, so they’re still subject to change. The Registration link at PowerShellSummit.org will show you the current confirmed agenda.
For speakers who were regretfully declined, you’ll be able to register on November 1st. In the event we have a late speaker dropout - which happens - we may contact you about jumping in as a speaker after all, at which time we’ll sort out the finances if you’ve paid for your registration, typically offering a full refund of your registration fee.
You’ll notice that Summit has become a full 4-day event - we’re unsure, at this point, if 3-day passes will be offered or not. We won’t make that decision until February 2017, assuming any space remains by that point. So we hope you’ll consider joining us for the full 4-day event, including new hands-on experiences on Sunday, a wider variety of deep-dive half-day sessions on Sunday, attendee-driven “Side Sessions” on Tuesday and Wednesday, and an amazing lineup for Monday.

Be an Azure Consultant for PowerShell.org!

So, after our nearly-2-day outage, which was due to a still-not-fully-explained Apache fail, we’re looking to make some changes. We need to migrate PowerShell.org to a different Azure subscription anyway, so this is a good time to change the kind of service we’re using.
First, using Azure is non-negotiable. If your expert opinion is to use something else, please just don’t ;). **Update: **This might be changing. AWS could be an option.
Second, our current environment is a classic VM running CentOS 6 (yeah, it’s old), WordPress, and MySQL. WordPress and MySQL are also non-negotiable, this isn’t about switching CMSs or anything. We use VaultPress for to-the-minute backups, but their restore process is a beast and has never been easy or reliable.
What we WANT is the ability to more or less push a button and re-deploy the entire site from backup, ideally automated through some OMS trigger that senses when the site has crashed.
Now, some caveats.

Apologies for the delay

Due to unforeseen circumstances we’re a bit late getting out notifications of the sessions accepted for the 2017 Summit.
Apologies to everyone who submitted sessions.
We hope to have the notifications out in the next few days

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.

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

Call for topics – Summit closed but European conference open

The deadline for the submission of proposals for the 2017 has passed. We are NOT taking any new submissions. if you’ve been in communication regarding a submission thats fine its still under consideration and I’ll be in touch.

On the positive side the call for speakers for the European PowerShell conference has opened - http://www.powertheshell.com/psconfeu/

Recap of DuPSUG PowerShell Saturday 2016

Last weekend we hosted our second PowerShell Saturday, this time the event was hosted by IPsoft in Amsterdam. During this event members of the Dutch PowerShell User Group gathered together to view a number of presentations and to engage in lively discussions on the various new developments in the PowerShell world.
For more information about PowerShell Saturday, the Dutch PowerShell User Group or the slides and code used in the presentations please head over to the recap blog post here:
Recap of Dutch PowerShell Saturday September 2016

PowerShell Happenings at Ignite 2016

With Ignite fast-approaching, here’s what’s up - and this is intended to be a “community post,” meaning I’d love it if you could add your own PowerShell At Ignite notes in the comments, including sessions you’re looking forward to!
On **Sunday evening, **while not officially a PowerShell event, a lot of PowerShell glitterati will be at The Krewe’s annual gathering from 8pm.
On **Monday evening, **the Atlanta PowerShell User Group is kindly hosting a meet-and-greet with myself, Jeff Hicks, and Jason Helmick. We promise to be educational; registration required (but free).
Tuesday evening is the PowerShell Community Happy Hour (from 4-7; tickets required), including many of the in-attendance team members, most of the PowerShell.org Board, and a bunch of super Shell enthusiasts. We’ll have PowerShell.org and The DevOps Collective laptop stickers!
**Wednesday, **I’m looking forward to PowerShell Unplugged with Jeffrey Snover and I, from 9 to 9:45am. This is nearly always hilarious and fun. Then, from 10-10:30, Jeffrey, Jason Helmick, and I will be signing books and handing out laptop stickers at the Ignite Bookstore. Finally, from 11-11:30, I’ll be signing FREE! books at the Conversational Geek booth (#571) (who have some amazing scavenger hunt prizes).
And of course, please stop by the Pluralsight booth to say hi, pick up some swag, register your company for a free pilot subscription, and whatnot.
So… what’re YOU looking forward to next week?

Changing of the Guard at PowerShell.org

It’s a bit of a sad day at The DevOps Collective, which is the nonprofit that runs PowerShell.org. One of our Board of Directors members, Dave Wyatt, will be stepping down from his Director position this week. He wants to focus on his personal life a bit more, although he’s still going to be responsible for our public Build Service, and he’s going to continue contributing to the Pester project, so the community isn’t losing him entirely. Dave’s been a huge help, and a huge inspiration, at PowerShell.org, and he’ll be greatly missed.
But our sadness is balanced by some happy news, too, as PowerShell.org Webmaster Will Anderson has agreed to fill Dave’s seat. Will has brought a great enthusiasm to our team of volunteers, is also a PowerShell MVP, and also resides in Canada. Will’s responsible for most of the photography you’ll see in the upcoming PowerShell + DevOps Global Summit 2017 brochure, and he’s been a great help in keeping PowerShell.org’s website up and running.
So please join me in wishing our outgoing Director all the best, and in welcoming Will to the Board!