Extending Objects in Windows PowerShell, Part 4

Over the last several articles, I’ve demonstrated how to extend an object in PowerShell and why you might want to do so. In this article, I’ll show you how to take these concepts and use them to manage servers from a PowerShell prompt.

Extending Objects in PowerShell Article Series:

One of the reasons I find this approach appealing is that it forces PowerShell users to start thinking about managing at scale. In the pre-PowerShell days, you probably managed one thing at a time. With PowerShell, I’m trying to get people to think about managing 10 or 100 things at a time. Don’t be in the mindset of managing one server at a time when you can manage 2, 20, or 200.

The premise for my management tool is to create an object for each server I want to manage. The object will have a few properties and methods for reporting and to at least serve as a proof of concept. The function I wrote is by no means complete. You could easily extend it to include additional properties and methods to meet your business needs. In some ways this is like a simpler, console-based version of System Center, except that you can completely customize it.

Here’s my New-ManagedComputer function.

To use the function, you’ll also need to update type data if you want a more user-friendly default display.

Although I’m talking about scale, you still might want to create a variable for each computer. This could be helpful in my test domain when it comes to troubleshooting a problem, where I can easily do something like this:

Because my server names have a hyphen, I can’t use the name as my variable name, so I have an extra step to split the name on the dash and take the last part, which I know will be unique. The end result is variable that looks like this:

And has these methods:

The script methods are the ones that I added. We’ll look at some of these in a moment.

The other approach is to create a single variable for all your managed computers.

And there’s no law that says you can’t do both. With this approach, you can use typical PowerShell commands for reporting purposes.

This example is using the custom property set. Or you can use any of the properties.

If you are running PowerShell 4.0 or later, you can also use the new Where method, which is often faster.

The results will be the same.

Another interesting technique is that you can run a method for all computers at once.

For a small number of computers, this might be too bad. Although you’ll probably want to do this instead:

But depending on your method, you might not need to do anything special.

I hope you are noticing that for the most part I’m getting complete objects. I probably should have done the same for disk information but I wanted to show you how you could get a single value.

I can easily manage information in aggregate:

Or individually:

And of course I have the computername property, which I can leverage with any cmdlet that takes pipeline binding by property name.

When you think about objects in the pipeline, you can accomplish a great deal with minimal effort. I recognize that many IT pros think about using PowerShell to script everything, but there is an equally amount of amazing work you can do from an interactive prompt. I hope these last few articles have helped prove that. Questions or comments? Throw ’em in the comments.

Related Topics:

  • PowerShell

    Don't have a login but want to join the conversation? Sign up for a Petri Account