Decorating PowerShell Objects

Mon, 22 Jun 2015 12:44:21 +0000

Ever wonder how PowerShell seems to know how to format objects? When you run

Get-ChildItem or

Get-WmiObject , you only see a few key properties, but a wealth of other information is available through commands like

Select-Object and

Get-Member .

Have you ever written a PowerShell function that you nearly always pipe to

Format-Table ? Wouldn’t it be nice to specify some default properties and force them into a table?

Stop by for a quick hit on how to decorate your PowerShell objects with type names and formatting, including a re-usable tool to abstract out some of the details.

Walkthrough: An example of how I write PowerShell functions

Fri, 19 Jun 2015 14:59:15 +0000

A couple of days ago I posted a blog article titled “PowerShell function:Test-ConsoleColor provides a visual demonstration of the foreach scripting construct” and today I thought I would walk you through that function step by step since it’s what I consider to be a well written PowerShell function.

It starts out by using the#Requires statement to require at least PowerShell version 3 or it won’t run. It also requires that thePowerShell Community Extensions module be installed since it uses a function from that module and continuing without it only leads to errors:

#Requires -Version 3.0 -Modules PscxThe function is then declared using aPascal case name that uses anapproved verb along with asingular noun.Comment based help is provided just inside the function declaration. This isn’t the only location where comment based help can be specified at, but it’s my preferred location for it.

Click here to be redirected to the original post of this article on the author’s blog site where you can read the remainder of the article.

]]>

Philadelphia PowerShell User Group Meeting – July 7th 2015

Wed, 17 Jun 2015 01:30:48 +0000

Join us Tuesday, July 7th when PhillyPosh members John Mello and TJ Turner will be presenting. John will be giving a presentation on the new ConvertFrom-String cmdlet in the PowerShell V5 preview. Afterwards TJ Turner will be giving a presentation entitled “What’s in your toolbox?”.

Please register if you plan to attend in person or online. The meeting URL to join us remotely will be included in your Eventbrite registration confirmation.

Why Remoting vs. SSH Isn't Even a Thing

Tue, 09 Jun 2015 21:13:04 +0000

As you’ve probably read, Microsoftrecently announced that they’re getting on board withSSH, and that they’ve plans to, in some future-and-unspecified version of Windows, include a default SSH server and client. Some folks have taken to the Twittersphere rejoicing this decision, even though I suspect they’ve no idea why Microsoft is doing it. Others have suggested that this is the downfall of Remoting (management viaWS-MAN), because who would want that when you’ve got SSH?

And so now I have to write this.

First of all, let’s speculate - with some objectivity - why Microsoft is getting involved with SSH at all. My personal belief is that an SSH client is simply massively overdue. Literally every other business-grade operating system on the entire planet comes with a decent command-line SSH client, so for pity’s sake, let’s get Windows one, too. Being able to reach out to Linux boxes, routers, switches, and all manner of other devices isn’t a convenience, it’s a necessity.

The SSH server piece is a little more interesting. My suspicion is that Microsoft wants to further enable management systems that are primarily built for Linux to log into Windows and manage Windows boxes. If you’ve got Ansible or Salt, for example, then you know that they revolve in part around using SSH to log into nodes and run commands. Fine - Microsoft can enable that on Windows if it’ll help.

But.

Let’s be clear on why making a decision between Remoting and SSH isn’t actually a decision.

SSH is, basically, Telnet*. You send characters to the remote computer, and it sends characters back. It’s built entirely around stdin and stdout. On a Unix system, this works beautifully, because at the end of the day everything on Unix is a process, a file, or a folder. It’s all text, all the way down to the turtles. SSH is great at accessing text. Now, _text itself _isn’t necessarily a wonderful management API, because it requires administrators to become experts at string manipulation and slicing, but in the Unix world that’s a de facto skill. In other words, _for the type of management API that Unix uses, SSH is a wonderful data transport mechanism. _

(*yes, I know that SSH has evolved tremendously beyond Telnet - but for the purpose of discussing how SSH moves data back and forth, Telnet is a useful analogy. I know SSH does a lot more than just the Telnet-y bits. That’s less relevant to my discussion, but thanks to the SSH fans who’ve pointed it out. I’m simplifying so I can get to the point - I don’t regard SSH as bad or weak.)

Windows, on the other hand, is entirely different. It is based on APIs. Data doesn’t move between bits of software as a text stream; it moves as a data structure called an _object. _Windows APIs all assume that you’re passing objects back and forth, and text parsing-and-slicing isn’t part of the deal. When an API gets input, it expects the computer name to be in the ComputerName property of an input object, not hiding in columns 26 to 46 of a text block. SSH, therefore, is not a good mechanism for transmitting the data structures that Windows uses for management.

Remoting, on the other hand, is a good mechanism. It has built-in code for serializing objects into XML, and then deserializing them back into objects on the other end. Like SSH, Remoting natively supports encryption. Unlike SSH, which is really just a remote console, Remoting wasn’t built with synchronous operations in mind. Remoting is perfectly happy to fire off a command and then wait until the data comes back some time later. Remoting’s underlying protocol, WS-Management, as implemented by the WinRM service, is capable of connecting to far more than just PowerShell, too. CIM and OMI, for example, communicate using WS-MAN. So, unlike SSH, Remoting (well, its underlying infrastructure) connects software endpoints for manageability. That’s important in Windows, because those endpoints are where we call the APIs we need to get stuff done.

SSH and Remoting (and WS-MAN) solve different problems. The fact that both solutions involve transmitting encrypted bits across the wire is literally the only thing they have in common. Yes, when you use Enter-PSSession to interactively connect to a remote machine, it looks and feels a lot like SSH in how it works. It isn’t. It’s entirely and completely different, and if you don’t know why, you should learn.

(Briefly, Enter-PSSession doesn’t send one character out, and then receive that same character echo back. Your typing occurs entirely inside your local console, where you can have rich tools like PSReadLine running. When you hit Enter, what you’ve typed is transmitted all at once to the remote box. It runs your commands, serializes the results into XML, and sends ’em. Your console deserializes the XML into objects, and your local formatting system takes over to display those objects. SSH assumes a dumb client; Remoting and Enter-PSSession require a smarter client.)

Remoting and SSH enable different functionality. Neither is better than the other, any more than cars are better than hot tubs. Both have their place, and both have strengths and weaknesses that devolve primarily from the operating system environments in which they were born. Microsoft is not implementing an SSH server because they believe it’s the best way to administer Windows; they’re doing it to enable some customer scenarios that, previously, were unnecessarily difficult. Rich management of Windows will always be easier to accomplish using Remoting, but if your management solution can only do SSH, at least you’ll be able to do what that can do.

Keep in mind that Microsoft’s also provided a reference implementation for WS-MAN running on Linux, because if your solution supports WS-MAN - as Microsoft’s do - then it’s nice to be able to use that cross-platform.

Now, another argument is, “my security people won’t approve Remoting, but they already approve SSH, so we should just use that.” First, your “security” people (and they’re clearly anything but secure or people) have also probably allowed RDP for managing servers, which is just dumb. Choosing to use an inappropriate tool just because the organization won’t grouse about it suggests that you have H.R. problems. Either someone in “security” should be fired, or you should be applying for new jobs at companies that aren’t stupid. SSH wasn’t always approved; someone had to understand it, what it did, how it worked, and become comfortable with it. They’re going to need to do that with WS-MAN whether they like it or not, because it’s _what Microsoft is going to fixate on, exclusively, for proper management of their operating system. _You’re not going to be able to properly manage Windows via SSH, trust me. Microsoft investing some time in OpenSSH is not the same as Microsoft investing time to re-architect their entire operating system around Telnet as a management communications protocol. If you don’t believe me on that, then you’re just being obstinate. Which is fine, but time will prove me right on this. So, if your organization doesn’t “like” Remoting, fix your organization.

And SSH will be another tool in our toolbox. Hopefully, you’ll use it when it’s the very best thing to do, and use other tools when they offer the best way to accomplish a particular task.

]]>

Trust, but Verify

Tue, 09 Jun 2015 00:12:33 +0000

The PowerShell code you write can turn up in interesting places. Production services might rely on it. Your co-workers might take a peak and borrow ideas from it. You might decide to share it online. Someone might see your code online and use it in their own solutions.

Hit the link for a quick bit on how we can help create more reliable, consistent, and secure solutions. Simplified to one line: always ask yourself “what could go wrong?”

What do you think? Is this over the top? Do you have any funny or awe-inspiring-train-wreck stories that resulted from assumptions around PowerShell or other code?

I’ve been lucky so far. My scariest moment? A while back, I was testing some code against a test server or two withInvoke-Parallel. Oops! The code to pull test systems hit a bug, and pulled all computer accounts. A number of domain controllers were hit before I could press ctrl+c. After recovering from a minor heart attack, I realized the code was benign, quickly fixed the bug, and broke the bad habit of running with a high-privilege account.

Cheers!

]]>

PowerShell.org: Where We've Been, Our New Look, Where We're Going

Mon, 08 Jun 2015 18:29:11 +0000

PowerShell.org has come a long way, both spiritually and physically, since our inception in September of 2012. Let’s look at some screen grabs from theInternet Archive, and take a stroll through our history.

Articles from June 2015 on PowerShell.org - Welcome Automaters!

I need YOUR PowerShell Stories

PowerShell.org, Inc. 2015 Shareholder Meeting Roundup

The Scripting Games: Here's What's Happening

The Background

Decorating PowerShell Objects

Walkthrough: An example of how I write PowerShell functions

Philadelphia PowerShell User Group Meeting – July 7th 2015

Why Remoting vs. SSH Isn't Even a Thing

Trust, but Verify

PowerShell.org: Where We've Been, Our New Look, Where We're Going

Before PowerShell.org

Mississippi PowerShell User Group Virtual Meeting – June 9th 2015

DON'T Start Learning PowerShell?!?!?

Creating a small footprint, base image Part 4 | Bringing it all together with automation

Automating with Jenkins and PowerShell on Windows

NYC Powershell Usergroup meets on June 8th

VERIFIED EFFECTIVE Self-Assessment

Major Changes to DSC Pull Server Configuration IDs

Articles from June 2015 on PowerShell.org - Welcome Automaters!

I need YOUR PowerShell Stories

PowerShell.org, Inc. 2015 Shareholder Meeting Roundup

The Scripting Games: Here's What's Happening

The Background

What We Thought About Trying

Here’s What We’re Doing, Part 1

Here’s What Else We’re Doing, Part 2

A User Group CALL TO ACTION

Here’s Something YOU Can Do To Help

Here’s Something Else YOU Can Do

In the Meantime