What do you do when the boss tasks you with a large piece of grunt work? You know what I mean — some thankless, time consuming project that is so primitive that you want to hire an intern to hire another intern to manage it. So what do you do? If you’re like me and you like your job (or are at least willing to keep it), you do it — willingly, if not necessarily happily.
But when that same error-prone bit of bone-wearying drudgery comes around a second time, you will — if you are like a lot of IT administrators — start wondering if there’s an easier way out. There is. PowerShell version 2.0 presents a remarkable opportunity for IT staff people to simplify and automate the tedious, repetitive tasks that consume such a large part of a typical day. One of PowerShell’s greatest strengths lies in its ability to describe everyday tasks in simple command statements that any IT person can readily produce. Let’s take an example.
The boss says, “Hate to do this to you, but I want to know which clients in our department are using System Restore. I want a report listing each of those clients and the time of the last restore point each one has taken. Here’s a list of the computers that need to be checked.”
Yikes. Sounds like hours of wandering around looking for users who aren’t busy so I can get at their computer for a minute. It seems I’m doomed to pointing and clicking endlessly through the Windows UI looking for the needed data and notating it on my clipboard. Then I get the fun of manually creating the document to send to the boss. Hours of productive time down the drain — maybe days.
There’s got to be an easier way to do this, right? Right.
Maybe PowerShell can give us a hand. Can I get PowerShell to tell me if a Restore Point has been taken on a computer? Perhaps.
Is there a command that lets me see PowerShell commands? Yup.
The asterisks around ‘restore’ provide wildcard functionality. This command gives me anything that contains the word “restore”. Get-ComputerRestorePoint looks promising. Most of the Get- commands will allow you to run them with no input, retrieving all possible values. Let’s give it a shot.
Yep — that’s what we’re looking for, all right. How about we focus on just the last one.
And finally, let’s zero in on just the time it happened — that’s what the boss is asking for.
Now wait JUST ONE MINUTE… What is THAT? What happened to the nice date formatting we were seeing all along? PowerShell’s built-in formatting functionality just led us into a trap.
It turns out that PowerShell has a default formatter already configured to support the objects generated by Get-ComputerRestorePoint. But when we used Select-Object to extract just one property, we no longer had the same kind of object, and so the default formatter no longer applies. Instead, we get that date in its native format. Behold the glory of the WMI UTC date format! So now what do we do with it?
Fortunately, there’s a .NET class for dealing with exactly this kind of date format. And that class has a handy formatting method we can call to get back to the nice safe world of the PowerShell DateTime type. I can reference the .NET class by wrapping it in [square brackets], and invoke its method by using two colons. Then all I need to do is feed the CreationTime property to it. How about if we do it this way:
Now that’s more like it. That’s something I can show the boss. In part 2 of this blog post, I’ll clean up the output a little, and get ready to perform this task on multiple computers.