Articles from 2016 on PowerShell.org - Welcome Automaters!

UPDATE / Tug: The Open-Source DSC Pull Server

Mon, 19 Dec 2016 17:25:49 +0000

If you haven’t taken a look atTug, 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.

Tug is nominally cross-platform. Basically, it’s n ASP.NET Core application that can run under any Web server that supports ASP.NET Core, which includes Windows, Windows Nano Server, and even Linux. Tug knows the DSC protocol, so it receives requests from Local Configuration Managers (LCMs) on DSC target nodes.
Tug has no “brains” to deal with those request, though. Instead, it implements a provider layer, and calls upon a provider to deal with requests. A very simple provider is currently implemented, which runs PowerShell commands in response to LCM requests. So, short story, if you can write a PowerShell advance function, you can make your pull server behave in whatever way you want. Store data in SQL Server, if you like, for example.
Because of some hitches in .NET Core 1.0, that run-PowerShell-commands trick doesn’t work well. so to do that you really have to target full .NET, which limits you to running Pull server on Windows Server or Windows Server Core. That should be fine for most folks.
But you can also write Tug providers in full .NET - meaning you can use (say) EF Framework to manipulate target node data.
Presently, Tug doesn’t implement the Report Server functionality - it’s stubbed out, and that’s coming next. And if you’re thinking, “will Tug be able to ____,” the answer is, “yes - if you write a provider layer that lets it do ____, which can include writing PowerShell commands (functions) that do ____.” Tug isn’t intended to lock you into one operational mode. Do you want to store client data in SQL Server, and assemble MOFs on-the-fly? You can program Tug to do that. Do you want to store everything in XML files? You an program Tug to do that. Want to use client certificate authentication for nodes? You can program Tug to do that. Because everyone wants something a little different from their Pull server, Tug’s designed to let you code up whatever model you prefer.
Tug’s an open-source project on GitHub, licensed under MIT, which means you can use it for whatever you want. We’ve got abrainstorming document with ideas, and if you’d like to contribute, that’s a place to start. **And please, contribute. **If you can’t, but you follow someone in the community who might be able to, please draw their attention to the project.

]]>

The Key to Understanding PowerShell – on Windows or Linux

Thu, 15 Dec 2016 15:22:12 +0000

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 _does not exist to automate administrative tasks. _Re-read that a few times until it really sinks in. You see, you start going at the Linux guys with this “automation” argument, and they’re all like, “yeah, man, we’ve had that for always.” The existence of PowerShell on Linux makes no sense if the point of PowerShell is simply automation. In fact, PowerShell as an automation mechanism also _makes no sense on Windows. _Keep in mind that all PowerShell does is built on WMI/CIM and .NET Framework; there was nothing stopping you from using those things in the first place. You didn’t need PowerShell.
The point of PowerShell is that .NET Framework is a terrible surface for systems administrators. Getting anything done correctly in .NET requires you to write an application of some size, compile it, and run it. .NET wasn’t designed with ad-hoc, system-level “scripting” in mind; it’s an application development framework. An empty .NET project starts with dozens of lines of code and configuration; that’s the bare minimum to even start writing code. For admins, it’s too much. Heck, it’s sometimes too much for _developers, _which is why some of them like PowerShell as a “.NET immediate window” so much - they can just bang out a one-liner, hit Enter, and get results.
I’ll argue that all operating systems rely on APIs for command-and-control. If you want to tell Windows to shut down, you need an API to do it. In modern times, that API comes via WMI/CIM or .NET, for the most part. In Linux, if you want to configure Apache to listen to a different port, you need an API. That API comes in the form of a text file. I’ll also argue that, from a systems administration perspective, all APIs suck. In Windows, you’re forced to learn this vast and complex .NET Framework, which is only marginally consistent within itself, and which requires a (relative) ton of code to make do anything. In Linux, you’re forced to learn regular expressions and text parsing, along with a bunch of poorly-interconnected command-line tools that have improbable names invented by Dungeons & Dragons geeks in the 1960s and 1970s. “Grep,” as an API for systems administration, was never a good idea - it’s just what got the job done when your main configuration surface was a bunch of text files.
The entire point of PowerShell is nothing more, nor less, than to wrap a more-consistent, administrator-friendly API around those other sucky APIs. PowerShell is an abstraction layer, and that’s it. Do you know how to conquer up a ServiceController reference in .NET, and ask it to restart a surface? Me neither, nor do I care to learn - I’ll just run Restart-Service, which does all that under the hood. Do you know how to pull a daemon list on Linux, retrieve just the httpd daemon, and restart it? You might, but I don’t, and I don’t care to learn that either - I’ll run Restart-Daemon (which will exist someday, I swear it).
On Windows, PowerShell doesn’t replace .NET. We all know that. It makes .NET easier for an admin to use in the context of administration. On Linux, PowerShell doesn’t replace grepsedawk and all the text files - it simply makes them easier, and more consistent, to use for administration. The point of PowerShell is that it allows us to deal in deterministic data structures (objects) without having to be text-parsing experts. It wraps poorly designed underlying APIs into something with a consistent, admin-focused surface. That’s it.
PowerShell does not posit that, on Linux, grepsedawk is a bad idea. PowerShell simply suggests that those tools, and their friends, are a lot harder to learn and use than they should be. PowerShell’s value-add is not automation - you can do that without PowerShell. PowerShell’s value-add is _better productivity as you automate, _and that’s something anyone should be able to wrap their minds around.

]]>

PowerShell Gotchas

Mon, 05 Dec 2016 00:28:59 +0000

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

Tue, 01 Nov 2016 16:59:01 +0000

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.

First, let’s just quickly review our oldest kind of “container,” the virtual machine. I’m going to generalize a bit here, so that what I’m writing is true for any kind of VM. Essentially, a virtual machine is a very rigidly scoped process. The host computer, via software known as a hypervisor, emulates all of the services that a real, physical computer would provide. The hypervisor pretends to be a network card, a BIOS, a CPU, RAM, and so on. Upon that virtual hardware runs a normal off-the-shelf operating system, which in turn runs whatever software you want. Now, that description is true of an old-time virtualization situation. In reality, modern hypervisors take a variety of approaches to help improve the performance of that situation. For example, CPUs are rarely _emulated, _per se; instead, the hypervisor manages thread scheduling on the physical CPUs, and more or less exposes them directly to the VM. Kinda; I’m simplifying a bit. Hyper-V also uses synthetic hardware versus emulated hardware for many devices, which again reduces overhead and improves performance.
Now let’s move on to containers, which - for the purposes of a simple explanation - can be a Linux container or a Windows Server container. Notice that I’m not using the word “Docker,” here, because Docker is a container management solution, really, and can manage both Linux containers and Windows containers. A container is not a virtual machine, in any way, shape, or form. There’s no emulated or synthesized hardware. Instead, a container is just a normal application running as a normal process. In the operating system’s process list, this application is essentially marked “this is a container.” That special “marker” causes some bits of the operating system to behave a little differently. For example, when the application asks the OS to write to a file on disk, or (on Windows) to a registry key, the OS “intercepts” that call and instead writes the data to an area that belongs just to that application. Any read requests first check that private area, so the application gets the data it expects. Read requests that can’t be fulfilled by the private area are directed back to the “main” file system (or registry, or whatever), so the application “believes” it is running all by itself on a full computer. The practical upshot of this is that the application can’t change anything in the “common” OS, although the application doesn’t realize that. Deleting the container removes everything the application has done. Honestly, this technique - in the form of read/write filters - has been around _forever. _Virtuozzo has been doing this in hosted environments for years, Windows Embedded had similar filtering functionality, and even Microsoft App-V works on largely similar principles. The difference with containers is that the filtering happens at the kernel level of the OS, so it’s much more efficient and managed.
But it isn’t foolproof. Containers do not represent an impenetrable barrier between processes, meaning it’s possible for one application to access another’s data, potentially hog processing resources, etc. So in cases where you’re dealing with super-sensitive data (for example), containers might not be acceptable.
Thus, Microsoft’s “Hyper-V Container,” which sits somewhere between a full VM and a zero-VM container. Basically a Hyper-V Container is a virtual machine, just like the Hyper-V VMs you know and love. The difference is that, when you ask Windows to spin up one of these containers, it inserts a trimmed-down version of the Windows OS and kernel. Many of the API calls within the container are handled instead by the host OS. The result is a “lighter” VM that imposes a bit less overhead, especially given Hyper-Vs use of synthesized hardware. But data remains _within _the VM, imposing the rigid boundary around the VM that we’re used to. One VM cannot access the contents of another (except via well-defined channels like file sharing or other port-based communications), and so you get a more managed security barrier. You also get faster spin-up time - not as fast as a “normal” container, but faster than a “normal” VM.
It’s worth understanding all of these different execution models. None of them are always right or wrong; they’re all tools in an increasingly varied tool belt, allowing us to right-size our execution environment to the task at hand.

]]>

Registration is now open

Tue, 01 Nov 2016 11:30:36 +0000

Registration for the 2017 PowerShell and DevOps Global Summit is now open. Click on Summit and follow the links to register

]]>

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/

Recap of DuPSUG PowerShell Saturday 2016

Tue, 27 Sep 2016 07:28:04 +0000

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

Thu, 22 Sep 2016 15:27:46 +0000

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

Thu, 22 Sep 2016 14:47:30 +0000

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!

PowerShell + DevOps Global Summit 2017 Preview

Mon, 19 Sep 2016 19:55:14 +0000

As a quick reminder, ourCall 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.