Sometimes one way to do something is less effective than another — sometimes in subtle ways. The wrong choice might add a few extra seconds to a job that takes a few minutes and many minutes to a job that might take hours. Those small changes add up over time. Which question do you want your boss to ask: “How does she manage to get everything done with time to spare?” or “Why is he always running behind schedule?”

One of PowerShell’s most valuable features is pipelining. Borrowed from UNIX, pipelining allows manipulation of vast amounts of data with elegantly short statements. In one programming statement, data can be retrieved, filtered, sorted, acted upon, reported on, and sent to your inbox. But that great strength masks one of its greatest vulnerabilities. Great quantities of information can be processed quickly. But is it as quickly as it could be?

Consider the following piece of PowerShell code.

Get-WMIObject Win32_Service | Where-Object {$_.Name –eq “Spooler”} | Start-Service

It’s a straightforward piece of code that starts the Print Spooler service. It processes in a fifth of a second — that’s quick! Get the service and start it… simple, right?

Not so fast. Think carefully about what happens in this code. The first segment, before the first pipe, does not retrieve one service — it retrieves all the services. Now, I’ve got 167 services currently present on my laptop (running Windows 8 Consumer Preview, by the way). 167 objects gurgle down the pipeline into Where-Object. That cmdlet takes those 167 objects and produces an output of a grand total of…

…one object — which gets started by Start-Service.

I’m reminded of a quote attributed to the sculptor Michelangelo.

“In every block of marble I see a statue; see it as plainly as though it stood before me, shaped and perfect in attitude and action. I have only to hew away the rough walls that imprison the lovely apparition to reveal it to other eyes, as mine see it.”

My call to Get-WMIObject serves up a big ol’ block o’ marble. 167 services are described by a lot of data. The Where-Object filter starts ‘hewing away’ pieces from that Statue-of-David-sized block of marble until it gets down to the size of a small figurine, which it puts on the pipeline. What happens to the rest of that unused marble? Jacopo I’Indaco (one of Michelangelo’s underappreciated assistants) sweeps it into a dustpan while sobbing quietly to himself.

Is there a better way? There certainly is. Get-WMIObject has a –filter parameter, which allows us to pass a description of what we are interested in to the WMI service. WMI tries to act like a big database of information about a Windows system that you can query — but in reality it isn’t. WMI passes your request to a piece of software called a provider. That’s important because WMI providers — the components that extract the data we need — are specialists in retrieving data from their areas of expertise. They can retrieve data in a fast, targeted way. Here’s a piece of code with identical output, but with a processing time of 120 milliseconds.

Get-WMIObject –filter “Name = ‘Spooler’” | Start-Service

What’s the difference? Consider visiting a library. I live in the Chicago area, and the biggest library in the area in the Harold Washington Library Center in downtown Chicago. This massive, ten-story facility circulated 77,000 books in January of this year alone. Imagine visiting the HWLC with a burning need to read a particular book. Unfortunately, you are too shy to ask for help finding it. The good news is that it is still very possible to find your book. All that’s necessary is to check each book, on each shelf, in each stack of shelves, in each row of stacks, on each floor until you find it — or worse, until you get to the top floor and find it isn’t there at all. It’s beyond obvious that you would have saved time by asking a librarian, who with a quick check of an index could have pointed you immediately to the correct floor, stack, and shelf — or else told you not to bother, because the library doesn’t have the title.

The librarian is the WMI –filter parameter. The underlying provider code that retrieves my list of services has expert knowledge about those services. It can intelligently target the data that I need. That’s handy when finding my one service in a list of 167. It’s an even more valuable when targeting hundreds or even thousands of objects.

By contrast, Where-Object is the wallflower on the sixth floor of the library still searching for the latest Tom Clancy novel in the horticulture section. While blindfolded. Yeah — he’ll be a while.

Maybe you’re thinking, “big deal, Mike — you saved 80 milliseconds. Don’t spend it all in one place.” But consider the percentage improvement in the speed of that data retrieval (calculated with the very handy Measure-Command cmdlet, incidentally). Cutting a 200ms job down to 120ms is a savings of 40%! How’d you like to take an hour-long task and cut it down to 36 minutes? Or take something that runs all day and shave off 3 hours? Perhaps more dramatically, isn’t it important to you to make sure that jobs that you hope to complete in 36 minutes don’t take an hour? Here’s how: look for opportunities to filter objects without having to resort to Where-Object.

I like to think that if Michelangelo were a PowerShell programmer, he’d have said this: “I see a statue in my mind, and… then I buy a statue just like it that somebody else carved. Then I show it to everybody and say that it’s mine. Because that leaves me more time to do things I really care about.”

Microsoft has capitalized on that desire to compete in a perennial competition called the Scripting Games. Begun in 2006, the Microsoft Scripting Games presents scripters with a series of challenges calling for PowerShell script solutions (the 2006 competition sported a VBScript division, as well.) Competitors have a week to submit a solution to the challenge, posting it to www.PoshCode.org, which hosts the competition again this year. Each entry is then evaluated by a panel of judges. Prizes are awarded for the top-scoring scripters in a beginner and advanced division, and additional prizes are awarded randomly to participants, with an increased chance of winning as you participate in greater numbers of challenge events.

Points are awarded not only for the basic functionality of the script but for real-world criteria such as reusability, documentation, and adherence to good coding practices. Maybe there are people out there who like writing documentation — I’m not among them. But would I do it to win a shot at an e-book from O’Reilly or a full version of PowerGUI? You bet. Last year’s grand prize winner got a free admission to TechEd and a personal phone call from the inventor of PowerShell, Mr. Jeffrey Snover. Not everybody gets to say, “Here’s what I told Jeffrey Snover that I want to see in PowerShell 3.0…” you know?

The Games officially begin on April 2, and details are available at the All Links On One Page document posted here. The Games are managed once again by Ed Wilson, who holds the official title of Microsoft Scripting Guy. He posts PowerShell tips and tricks daily (!) to the Hey, Scripting Guy blog. It’s via this blog that the Scripting Games challenges will be announced, so that’s another great reason to subscribe to that blog. The Scripting Guy has somehow convinced his bride to participate in the games again this year, so you’ll see her on the leaderboard as ScriptingWife. The Scripting Wife has her own blog, focused on those who are new to PowerShell-based scripting.

The spirit of competition brings out the best in good competitors; join the fun in the 2012 Microsoft Scripting Games, and I’ll race you to the top!  ¡Vámanos!

Grab this badge here!

I flew to Atlanta a few months back and made my way to the taxi stand. Settling into my seat, I half-heard something from the front seat that I presumed was equivalent to, “Where to, Mac?” I named my hotel and the street. The driver started to pull away from the curb, but in seconds pulled back over to the curb and stopped. He visibly thought about something and then, wordlessly, he grabbed and handed to me… his GPS receiver. It was up to me to key in the location I wanted to go.

Maybe I’m all alone in this, but I find this terribly strange. I would think that one of the first things they teach you in cabbie school is where all the hotels are and how to get to them — right after the part about collecting money from the customer, and maybe right before the bit about being polite and friendly.  I always presumed that one of the things that a cab driver brings to the table in any transaction is knowledge of the local area, you know?

Maybe I’m just showing my age.

What does all this have to do with PowerShell? Glad you asked. Microsoft just released the second CTP (that’s Community Technology Previews) of the forthcoming PowerShell 3.0. The version that comes on your Windows 7 clients and your Windows Server 2008 R2 servers is the 2.0 release, so Microsoft is giving the PowerShell community an opportunity to kick the tires on the new version before it goes prime-time. There are some great new features in there, but some of them make me worry that I may soon need to turn in a job application at AAA A1 Taxi Company.

Automatic Module Imports

Historically, PowerShell required its users to manually direct the shell to add new modules of functionality. Import-Module is part of the PowerShell core cmdlets for precisely that purpose. This allows PowerShell (for performance reasons) to start up with the minimally necessary set of features to be useful while allowing the user to add the modules that contain the functionality needed for specialized tasks.

PowerShell 3.0 is going to remove that requirement. You will now be able to invoke any cmdlets, and, if the corresponding module isn’t imported, PowerShell will import it on your behalf! To activate this feature requires the use of the PSModuleAutoLoadingPreference variable — so it is possible to turn it off or require the intended user of a module to name the module and the cmdlet in order to invoke the cmdlet.

Tab-completed Enumerations

Another nice feature is an extension to PowerShell’s tab-completion capabilities. PowerShell already supports the ability to press the Tab key to ask PowerShell to fill in the remainder of a lengthy cmdlet name or the name of a parameter. PowerShell users have long been able, for example, to type Get-ADFin<tab> and see the cmdlet name completed to Get-ADFineGrainedPasswordPolicy or to type Write-Host –Fore<tab> and see the parameter expand to –ForegroundColor. PowerShell 3.0 will go beyond that to incorporate tab completion on Enumerations.

Enumerations are sets of values available to PowerShell that are managed in a collection. Specifically, enumerations are a listing of constant values, each referenced by a name. You’ve used enumerations, perhaps without knowing it, when using certain parameters that require you to supply one of a constrained list of values. Consider calling Set-ExecutionPolicy, which can take parameters like Restricted, Unrestricted, RemoteSigned, and others. Or consider the ForegroundColor parameter to Write-Host that I just mentioned, which takes parameters of Red, Green, Cyan (but not Blue). Both of these parameters can accept only a particular set of predefined values. And, thanks to PowerShell 3.0, I can fill them in with tab completion! Under PowerShell 3.0, I can type Set-ExecutionPolicy Un<tab> and see it fill in Unrestricted. I can type Write-H<tab>  –F<tab> M<tab> and see it expand that text out to Write-Host –ForegroundColor Magenta. That’s a savings of about twenty keystrokes!

Not that I’ll be using magenta for any of my text, of course — maybe a nice, responsible DarkCyan. But I can save some keystrokes when doing either and still create nice readable code!

Getting Your PowerShell Hack License

Be careful with these new tools. Remember that with great PowerShell comes great responsibility! Remember that just because you have the ability to name a cmdlet and see PowerShell launch it for you doesn’t mean that you shouldn’t be busily studying your lists of modules and which cmdlets are provided by each. Just as I fear for the day when I need a cab and solar flares have knocked out the GPS system, I worry that my dear readers may find themselves needing a key cmdlet on a computer that has not been upgraded to PowerShell 3.0 and find themselves as lost as that one Atlanta cab driver. Stay familiar with your local terrain. Know how to find your way around even when these clever shortcuts fail you. Don’t let these handy features blunt your knowledge of how PowerShell actually works, or perhaps it’ll be your voice I hear calling “Where to, Mac” from the front seat of my cab!

1. Many cmdlets accept pipeline input ‘ByValue’, meaning that they can consume whole objects of a given type. You can look at the datatype associated with the -InputObject parameter of a cmdlet to figure out which type of object is ‘eaten’ by that cmdlet (the ‘INPUTS’ section of the –full version of a cmdlet’s help file gives you an even better idea).
2. Most cmdlets also have other parameters that accept pipeline input but with a twist: these parameters aren’t looking for specific types of objects, but instead they expect to find incoming objects which contain a property that has the same name as that parameter. So the –name parameter of the Get-Process cmdlet hopes incoming objects have a name property.

These abilities provide rich pipelining functionality. I can pipe many kinds of cmdlet output to many other cmdlets and have a very good intuition that the pipelining will work the way I expect. Until, of course, the time when it doesn’t (cue ominous music here…)

So what happens when I have output from one cmdlet that I want to feed to a second cmdlet, and neither of the above scenarios is applicable? For example, Get-Foo produces objects of type System.GKTrainingRocks.Foo, and Set-Bar expects input objects to be of type System.GKTrainingRocks.Bar (those are all imaginary, by the way — I’ve been hanging around UNIX users too much). Worse, what if none of the names of the properties of the output match the names of the parameters on the next cmdlet in the pipeline? Crazy talk? Actually, no.

Just imagine: while you busily plan your company’s upgrade to SQL Server codename “Denali”, your boss drops by your desk and wants a list of all the services running on all the corporate print servers. The PowerShell portion of your brain wakes up and starts spinning its wheels: “Hmm, listing services — there’s Get-Service for that — okay — how about getting a list of computers — I could query Active Directory for those — Get-ADComputer sounds about right — maybe I can hook those two cmdlets together…”

So you try to make it work with something like this: Get-ADComputer –filter {Name –like “PrintServer*”} | Get-Service

Eagerly anticipating success, your mouth drops open when you see a list of errors:

Get-Service : Cannot validate argument on parameter ‘ComputerName’.  The argument is null, empty, or an element of the argument collection contains a null value.  Supply a collection that does not.….

NOOOOOOOOOOOOOOOOOOOOOO!

What went wrong? Let’s take each of our main pipelining scenarios one at a time.

What kind of object does Get-ADComputer generate? Check the help file (or simply retrieve a computer object using the cmdlet and pipe it to Get-Member). Here’s the help-file snippet (using Get-Help Get-ADComputer –full).

It produces Microsoft.ActiveDirectory.Management.ADUser objects. So far so good. Next question: what kind of objects does Get-Service accept as input on the pipeline?

Aha! Get-Service expects System.ServiceProcess.ServiceController objects. It has no clue what to do with a Microsoft.ActiveDirectory.Management.ADUser.

No need to panic yet — it’s time to try plan B. Does Get-Service allow pipeline interaction with objects using parameters that have names I can find on my incoming ADUser objects? Remarkably enough, yes it does! There’s a Name property on my ADUser object — that’s the name of the computer I got from AD. And there’s a –name parameter on Get-Service and it…

Uh oh. That’s not good. The –name parameter for Get-Service wants the name of the service about which I want to retrieve data — not the name of the computer from which I want to get it. What does Get-Service use to identify the target computer? There it is — it’s the –computername parameter. That creates a challenge. I can’t use the Name property of my object because it doesn’t mean the same thing as the –name property of the cmdlet. I can’t use the –computername parameter of the cmdlet because I don’t have a matching ComputerName property  on my ADUser object. I’ve got a square peg and a round hole. Now what do I do?

Our essential problem is the name mismatch. If there was a way to take an incoming ADUser object with its underloved Name property and rename it to have the name ComputerName instead, we could do well. It turns out there’s a way to do that, and the help comes from an unlikely place — the humble Select-Object cmdlet.

A little noticed part of the help file for Select-Object reads like this:

–Property <Object[]>

Specifies the properties to select. Wildcards are permitted.

The value of the Property parameter can be a new calculated property. To create a calculated property, use a hash table. Valid keys are:

– Name (or Label) <string>

– Expression <string> or <script block>

What does this mean to us? In short, it means we can relabel a property of an object with a new name. The technique requires a hashtable, an unordered list of pairs of values. This particular hash table identifies the Label on our new property, as well as an Expression that describes the value that the new property is to have. So:

Select-Object –Property @{Label=”ComputerName”;Expression=”$_.Name”}

This piece of code can receive an object with a Name property and emit an object that has a ComputerName property instead! If we squeeze that in between a Get-ADComputer and a Get-Service, we should be all set! Our finished square-peg/round-hole solution looks like this:

Get-ADComputer –filter {Name –like “PrintServer*”} | Select-Object –Property @{Label=”ComputerName”;Expression=”$_.Name”} | Get-Service

PowerShell is optimized to allow many predictable, common-sense cmdlet interactions to happen automatically. A great many day-to-day tasks are accounted for in the design of PowerShell’s constellation of cmdlets. It’s comforting to know that even when the default behavior of our favorite cmdlets doesn’t allow for our desired results, we can add just a little bit of code to assemble the pieces into a satisfying solution.

Imagine I wrote a PowerShell function that produces objects of my own design. My objects are of type PSObject (which is to say, they are generic). My objects represent students in my classroom, and they have the following properties: Name, StudentID, and EyeColor. If I invoke that function (let’s call it Get-Student), it will generate a list of student objects and put them on the pipeline. Left unattended, those will travel down the pipeline, find nothing else to do, and get written out to the screen. But what if I pipe those objects somewhere? What if I said, for example, Get-Student | Restart-Service? Sounds ridiculous, and, yeah — you’re right about that. Just go with me for a minute…

What happens when those student objects hit Restart-Service? The –InputObject parameter looks up to see if what’s coming is a System.ServiceProcess.ServiceController. It’s not, and that parameter goes back to sleep. Then the –Name parameter wakes up, and looks to see if the incoming object has a Name property. It does, and so this parameter binds to the value in the name property. Restart-Service will try to restart a service that has the same name as one of my students. It’s not likely to work (unless I’ve got a student whose name is Browser or FontCache), but nonetheless, the pipeline is assuming that I know what I’m doing.

What does this mean? It means I can write code that produces objects that have properties that match the names of parameters of cmdlets that I want to work with. I can then pass those objects to cmdlets that expect objects with that matching set of properties. So maybe this isn’t an example of a square peg in a square hole, but of an octagonal peg in an octagonal hole.

So now what? Well, one logical thing to do might be to restart that service (perhaps to fix a stuck print queue).

There’s a cmdlet for that, called Restart-Service. The principle of pipelining says that I should be able to just feed the Print Spooler service object to the Restart-Service cmdlet.

It turns out that works. I can simply do this:

Note the use of the –force; this service has dependent services, so PowerShell wants to know that you are REALLY sure of what you are doing.

So how did that work? How did Restart-Service know what to do with the incoming Print Spooler service? It helps to take a close look at the help file for Restart-Service.  Have a look:

Take a close look at the data type named for the –InputObject parameter of Restart-Service. It’s looking for objects of the “ServiceController” type. That should ring a bell for you — that’s the same type of object that I get from my call to Get-Service. So far, so good, but how does PowerShell know to associate an incoming ServiceController object with the –InputObject parameter? Take another look at the help file (using the –full switch) for Restart-Service:

Note that the –InputObject parameter is designed to accept pipeline input — it WANTS to find data on the pipeline that it can work with. Specifically, –InputObject accepts pipeline input “ByValue” or, in other words, it consumes the entire incoming object whole. This is the mechanism by which PowerShell feeds the incoming service from the call to Get-Service (Print Spooler in my example) as an input to Restart-Service.

The pipeline is not a new idea. Douglas McIlroy is a mathematician and programmer who noticed, back in the 70s, that the output of one command in Unix often became the input for the next. He put forward the idea of a “pipe” to send the output of one program directly to the input of another, skipping the step of saving that output in a file of some sort. A few years later in 1973, Unix co-creator Ken Thompson added the feature to Unix.

Pipeline Limits = Tool Development

One key limitation of the Unix pipeline (and of the CMD.EXE pipeline that eventually followed in DOS and Windows) was that it was only passing text from one command to the other. In other words, it wasn’t much more sophisticated than writing all the output to a file and reading it back in to give it to the next application. What the receiving program received was a tsunami of text. This led to the development of tools like grep, awk, sed, and Perl as ways to manipulate that big block of text to produce meaningful output to feed to that next program. This has been a workable approach for Unix users for generations now. Microsoft has taken a totally different approach with PowerShell, however. PowerShell’s pipeline isn’t passing plain text, it’s passing Objects.

Objects and You

Objects, in programmer-speak, are a software representation of a real-world thing. Real objects have properties: my pen has a certain quantity of ink in it; my computer has a screen with a certain number of inches in diagonal size. Real objects also usually support tasks we can perform on them: my car has a GoFaster and TurnLeft method (hey, I could be a NASCAR driver!). Programming objects represent a real-world thing using a set of properties and a set of methods that replicate the information and tasks that are relevant to using that thing in the real world. Applying that to computer technology, consider the idea of a Windows service. It’s a piece of software that runs in the background and allows your computer to perform some sort of functionality. What kinds of information do you want to know about a service? Things like the name of the service, the name of the executable it’s running, whether it’s stopped or started… things like that. What kinds of tasks do I need to perform to administer services? Well, I’d need to stop and start services, mostly. I might need to change the start mode from Automatic to Manual.

PowerShell represents the idea of a Windows service using an object. When I call on the Get-Service cmdlet to give me a list of services, what I get is actually a list of objects that represent those services. How do I know what kind of objects? I can pipe those objects to Get-Member and it will tell me all about it, like so: (and don’t forget, you can click on these images to see them at full size!)

So a service is an instance of a System.ServiceProcess.ServiceController object. What’s that? Remember that PowerShell is built on top of the .Net Framework, a large base of code for Windows application developers. .Net provides a vast list of types of objects that can be used to assemble programs, and they all have lengthy names like that one. Long story short, “ServiceController”  objects are .Net’s way (and therefore PowerShell’s way) of describing services.

An old Internet joke from way back involves the so-called Amish Virus. ‘Infection’ by the Amish Virus can be diagnosed when you open an email and see this:

Thou hast just received the Amish Virus.
As we haveth no technology nor programming experience, this virus worketh on the honour system. Please delete all the files from thy hard drive and manually forward this virus to all on thy mailing list.
We thank thee for thy cooperation.
— The Amish Computer Engineering Dept.

The subtle humor of this long-standing joke lies in the fact that the author of the ‘virus’ is so technology averse that you have to damage yourself and others with it manually — the virus is not going to automate any of that for you. Of course, few recipients of such an email would go through the effort of doing something so obviously destructive. Common sense quickly argues against deleting valuable files or taking deliberate steps to infect friends with a damaging virus.

What does all this have to do with PowerShell? Interestingly, PowerShell defends against a few kinds of actual security threats using some of the same philosophy that protects us from the ravages of the dreaded Amish Virus.

For contrast, let me remind you about a little virus called ILoveYou. Launched in May of 2000, this simple little piece of code scanned infected computers for graphics and audio files, replaced the contents of those file with a copy of itself, and then propagated itself via email. Unsuspecting targets of the virus found an attachment seemingly named Love-Letter-For-You.txt attached to an email that appeared to be from a trusted source. A text file — what could go wrong? Double-clicking it (you could do that in Outlook back in those days) revealed the truth. The file wasn’t Love-Letter-For-You.txt — it was Love-Letter-For-You.txt.vbs. A VBScript-based application had just been launched in the system, and quite probably, without its user’s awareness.

The impact was immediate and drastic. In a week and a half, 50 million computers had been infected, and upwards of 5 billion dollars of damage had been done. Major corporations, plus the CIA, the Pentagon, and the British Parliament all took their email servers offline in order to clean up the mess. Whoa.

You can imagine that when building PowerShell, Microsoft surely wanted to avoid the disaster produced by the freely-executable nature of VBScript and JavaScript on Windows systems. PowerShell was launched with some significant protections against this kind of mischief.

File Extension Association
Part of what made ILoveYou so nasty was that it didn’t need to ask the user if he wanted to run the VBScript-based executable — that functionality was built right into the operating system. You see, the .VBS extension is already associated with the WScript.exe program in Windows by default, so double-clicking a .vbs file (or a .vbs file masquerading as a .txt) is sufficient to trigger it. By contrast, .PS1 — the PowerShell script file extension, is associated with Notepad.exe. So if some thoughtless user double-clicks an attachment called DamagingVirus.PS1 — no worries — it opens in Notepad, and no harm is done.

Execution Policy
Additionally, PowerShell ships in a default state that prevents script execution. This behavior is called an execution policy, and it’s a reboot-persistent, group policy-configurable setting. It sets a computer-wide configuration for how much trust we need to have in a PowerShell script before we can run it. The default execution policy is called Restricted, and it prevents the execution of any PS1 files. That’s true even for those scripts created locally, or run by the Administrator.

Interestingly, the execution policy does not prevent execution of individual statements at the PowerShell command prompt. So it’s possible that one could attempt to run a PS1 script, fail to do so, and then copy and paste the text of the script into the PowerShell console, one line at a time. But in most cases, that activates our primary defense against the Amish Virus. Common sense should take over in the mind of the user, who realizes he is in danger of doing something foolish. We can imagine that our users would not respond cooperatively to an email that says this:

You have just received the PowerShell Virus.
Please open the attached PS1 file, and cut and paste the executable code into a running instance of PowerShell.exe. That, or run Set-ExecutionPolicy unrestricted at a PowerShell prompt, and then launch the attached script.

Trust me, it’s totally safe!

Well, at least we can hope.

Related Courses:
Take 2 Microsoft Courses for the price of 1
Automating Administration with Windows PowerShell 2.0

So the boss emails you a list of computers and wants you to check if each of them are available on the network. You could open a command prompt, type PING and the first name, wait for a response, PING the second, ad nauseum. If there’s two names on the list, fine. How many on this list? 183. Yuck! Sounds like a job for… PowerShell!

Get-Help

Okay — let’s find a PowerShell feature that lets me ping a computer. Get-Command is the usual way to go about that, but in this case, I’m not getting a lot of luck. I see the PING executable, and other stuff I don’t need, but nothing in PowerShell. Here’s a wild idea — let’s try using Get-Help and see what we find.

Interesting — there’s a Test-Connection cmdlet that claims to be able to send PINGs to one or more computers. Sounds perfect. Let’s take a close look at the help file for Test-Connection.

I like the idea of the –Quiet parameter for a simple TRUE/FALSE evaluation of whether the computer is on the network. Having an object to interrogate might be useful in a later script, but for now, I’ll leave that Win32_PINGSTATUS object alone. What I really want to do is get a list of which computers are not currently accessible. So strategically, I want to iterate through my list of computer names, and for each one of them, if it isn’t ping-able (is that a word? Is now) then I want to get a message that says so. So how about something like this (click on the screenshot for a larger image)?

It’s a good start. But I don’t know which of the computers from my file are the ones returning true and false. Also, let’s assume I only want to know which computers are offline. Time to pull out the trusty old ‘if’ statement.

Hmmm. Those pesky rebels are at it again, it seems.

I like the output of this little one-liner. It’s a little slow, though. I can tweak it a bit by adding the –Count 1 parameter to Test-Connection, which instead of launching 4 ICMP packets sends One Ping Only (now, why am I hearing Sean Connery’s voice in my head all of a sudden?)

And luckily, since this data is coming out of WMI, I can extract the name of the computer I’m running this on from the same object.

WMI helpfully supplies a ‘__Server’ property with its objects (note: that’s two underscore characters, not one).

So with a little finagling, we get this cute little one-liner (cutting out that awkward ForEach-Object).

The @{Name= … Expression=…} syntax is called a Calculated Property when I use it in Select-Object, and it’s a great little tactic for either renaming a property with an ugly name (like Mr. UnderscoreUnderscoreServer there) or for performing some operation on a piece of data before exposing it to the light of day (like running that date formatter function over the CreationTime property). Check out the Get-Help file for Select-Object, and look at the details of the –Property parameter (you’ll see you can also use the word ‘Label’ instead of ‘Name’.)

This looks great so far. The next trick is accomplishing this same task across a few hundred computers.

Does Get-ComputerRestorePoint have a –computername property we can use to connect to each computer in the boss’s list? Rats — nope. But maybe there’s another way. Take a look at what kind of object that cmdlet produces. Get-Member is the best way to accomplish that — it shows you the name of the .NET class and the list of each of the properties and methods of the objects you pass in to it on the pipeline.

Okay — so it’s a WMI object. Maybe we’re better off accessing the restore points directly through Get-WMIObject. That cmdlet DOES have a –computername property, so I can target it at different computers from a central point.

Alas, Get-ComputerRestorePoint has a built-in method for doing conversion of date information to the DateTime format. This is one of those times where we need to make a trade-off. With the large numbers of computers to inventory, I’ll take the clunkier format conversion to get the multiple computer support of Get-WMIObject. Alternatively, we could have tackled this using PowerShell Remoting, but let’s save that for another time. Let’s look for a WMI class that supports restore points.

Note that the first attempt to search for a restore-related class flopped. That’s because Get-WMIObject –list only searches WMI’s ‘root\cimv2’ namespace by default. In fairness, that’s where most of the good stuff lives, but in this case what we are looking for isn’t there. So where is it? The class type from the earlier call to Get-Member gives a clue. Look after the pound sign. The second attempt finds the class we need.

So now we can rebuild our query to directly attack the problem with Get-WMIObject – like so:

Yep — that’s got it. Now we just need to target this at our list of computers, and we’re home free. If we drop the list of computer names from the boss into a text file (ComputerNames.txt, for example), we can just do this:

And we’re done. I can take that output and throw it into a file with Out-File, or a CSV file with Export-CSV. Problem solved. Days of wasted time saved. The boss gets his data, and I go back to designing our cloud strategy!