Articles from October 2016 on PowerShell.org - Welcome Automaters!

PowerShell & DevOps Global Summit 2017 agenda

Tue, 25 Oct 2016 10:00:07 +0000

The agenda for next year’s Summit is almost complete - we’ve notified all speakers as to whether their sessions have been accepted or not. If you haven’t received your notification please check your spam/junk mail.
We have a small number of sessions yet to publish - mainly around possible focus groups on the Wednesday afternoon.
To view the agenda go to the Summit event site - from https://powershell.org/summit/ click on the Brochure and registration link.
Registration opens 1 November 2016.

Re-Subscribe to New Forums Topic Notifications

Thu, 20 Oct 2016 23:00:43 +0000

Hello, PowerShellers!
During our migration and some of the inevitable database resets involved, many of you who were receiving notifications for new forums topics no longer are. You’ll need to re-subscribe.
To do so, simply visit the Forums page, click through to the forum(s) of your choice, and poke the “Subscribe” link that’s towards the upper-left-ish of the page. If all you see is an “Unsubscribe” link, then you’re already good to go.
Thanks again for everyone who routinely jumps in to offer friendly, helpful advice in the forums!!!

Pitfalls of the Pipeline

Tue, 18 Oct 2016 21:43:10 +0000

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.

PowerShell + DevOps Global Summit 2017: Session Acceptance

Tue, 18 Oct 2016 17:53:20 +0000

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!

Fri, 14 Oct 2016 22:14:54 +0000

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.

Our budget is $200/mo. We take about 150k-200k visitors per month, and WordPress is a reasonably demanding piece of software. We have about 500MB in files and about 300MB (currently) in data, and we grow about 75-ish MB a year.
We would ideally like the data backups to be distinct from the site itself. That is, if we could simply kill an old server and deploy a new one, and then drop the data onto it (all automatically), that’d be ideal. This is distinct from simply backing up an entire VM image, since the OS, files, and data would all be one chunk.
It’d be lovely if, instead of having to patch and upgrade the OS, we can just kill the current server, deploy a new one with all the new hotness in versions, and drop the data on it.
The more of this that lives in Azure (e.g., Backups), the more likely - we feel - we’ll be able to automate this entire kill-and-deploy process in OMS or something.

Staying on Linux is fine. It also isn’t a pre-req. WordPress (and MySQL, since WordPress doesn’t play well with much else) are the main requirements. We’d like to be on a modern (6+) version of PHP, as well.
**Update: **So, let me outline the kind of thing we’re thinking. So far we’ve gotten a lot of suggestions on which OS to use, or which DB to use, and that wasn’t really the question so much as the architecture. For example:

Run a small, on-demand staging instance where patches (WordPress and plugins) are applied to the site. The site’s folder is under Git, and after applying updates and testing, we push to a private (because configs contain passwords) GitHub repo. This instance isn’t backed up - the important bits are in GitHub.
Use ____ to deploy the actual instance(s) that people will use. This deployment is a la Elastic Beanstalk, where you just push a base OS image and it sucks down your GitHub repo to populate the files of the site. Again, not backed up - GitHub is the backup.
Except for the WordPress Uploads folder, which you redirect to another, simpler instance that serves these as static files. This is a bit complex, because WordPress needs file-based access to this for uploading, while it also needs to be exposed as a web server for downloading. Simple backups to ensure we have copies of the files handy, and we don’t need to retain a backup history because there’s no code that could break and need to be rolled back.
Data lives on a distinct hosted RDBMS. That’s probably MySQL, as it’s what’s supported with WordPress. We’re aware of Namiproject, but unless that’s moving in lockstep with the base WP releases and is 100% guaranteed to work with all the plugins we need…. The RDBMS is backed up separately.

A concern with #4 in Azure is that they only offer this (for MySQL) through ClearDb, and I’ve seen latency and persistency problems. I’m ideally wanting everything hosted in one datacenter/region to reduce that problem. And I’m aware of Namiproject, but we have something a bit more complex than a stock WP install, so someone’s going to have to convince me that SQL Server’s a safe choice.
So… any suggestions for a full-stack? Please, be serious and complete - if your suggestion is, “just run VMs,” that’s not helpful and it’ll likely be deleted. But if you’ve got ideas for a mix of services that you think will do the job - by all means, please, speak up!

]]>

Apologies for the delay

Thu, 13 Oct 2016 12:35:22 +0000

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

Wed, 12 Oct 2016 00:18:44 +0000

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

Tue, 11 Oct 2016 21:01:59 +0000

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

Tue, 04 Oct 2016 00:49:59 +0000

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 thisblog post.

Topics Covered

-match operator
-match operator with regular expression metacharacters
-notmatch with where-object
-replace operator
-split operator
Select-String
Switch Statements
Regex Object

]]>

Call for topics – Summit closed but European conference open

Mon, 03 Oct 2016 08:57:49 +0000

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/