Pythian Group

Most people think Windows administrators make a living with their right-hand—you know, right-clicking and left-clicking the user interface to get things done. While anybody can do that in Windows, the real value comes in when you no longer need to rely so much on the user interface but instead write scripts. Lower total cost of ownership is achieved when the administrative costs are kept low, and this is where Windows PowerShell comes in.

I’ve spent a fair amount of time writing VBScript scripts to administer Windows servers and workstations and automating repetitive tasks. One reason for me moving into Windows PowerShell is its roots in the Microsoft .NET Framework, as I have done a fair amount of .NET programming. But what is Windows PowerShell anyway?

Windows PowerShell is an extensible command-line shell and an associated scripting language built on top of the .NET Framework v2.0. It was released in 2006 and is currently available for Windows XP SP2/SP3, Windows Server 2003, Windows Vista, and is included in Windows Server 2008.

PowerShell will be included as a common engineering criteria (CEC) in future releases of Microsoft server products, making it a must-learn for Microsoft server administrators.

Administrators (DBAs included) have been using scripting to automate administrative tasks with scripting languages like DOS batch, VBScript, Perl, and a few third-party tools like KiXtart and WinScript. Windows PowerShell complements the administrators’ existing scripting toolkit to easily manage and administer Windows workstations and servers and other Microsoft server products as THEY are being built using the .NET Framework.

Although it is designed for operating systems, Windows PowerShell can be used to administer SQL Server 2005 instances and higher, as Server Management Objects—the object model used to manage SQL Server 2005—are built using the .NET Framework, thus exposing the object model in PowerShell. And since SMO is compatible with SQL Server 2000, you can administer SQL Server 2000 instances using Windows PowerShell. SQL Server 2008 even ships with its own PowerShell snap-in.

No wonder it makes sense to learn a thing or two about Windows PowerShell. Besides, I’ve seen Windows administrators being “forced” to do SQL Server DBA tasks even without knowing what T-SQL is. Windows PowerShell makes it a level playing field.

I will be posting a series of blog posts on getting started with Windows PowerShell, and how any Windows administrator can use it for their day-to-day tasks. In the process, I’ll also cover how to use Windows PowerShell for administering SQL Server instances.

Imagine yourself, happily computing (or whatever it is that you do with your computer). It’s a fine, sunny day, narry a cloud in the sky, and you’re happily typing along when all of a sudden you hear a rather alien sound eminating from your hard drive. Something that sounds, perhaps, like some combination of a roofer banging in a nail, and a miner’s pick as he works on releasing a stubborn piece of ore from a cave wall. 

Certainly not a good sound to hear coming from the general region of your hard drive on a nice, sunny day. Especially when you have not taken a backup in over two years…

Now consider your options. You could…

1. Turn off your computer immediately, Google “data recovery”, and call one of the multitude of companies that pops up. They will charge you in the neighborhood of $500 to get your data safely off of your damaged disk.
2. Immediately stop working, grab an external USB drive, and transfer all of your valuable data onto the external drive. Order a new internal hard disk, and keep working, confident in the knowledge that your disk is going to die soon, but you’ve already salvaged the valuable data and a new disk is on the way.
3. Try to get clever. Think to yourself “maybe if I run ‘chkdsk’ it will go through the bad areas of the disk, mark the sectors as unusable, and I can keep using this disk.”

Such was the scene at my desk last Friday. And you have probably already figured out where this is going. Yes, I ran ‘chkdsk’. The first three (of five) checks completed without error, and I thought everything was going to be fine. Then, during the fourth phase, after about an hour of intense clicking and banging noises, a message appeared on the screen, which I can only paraphrase at this point:

Not enough space is available on the disk to fix the bad sectors.

This was a concerning message, given that the disk was much less than half full.  But only a minute or two later my concerns were answered by another rather vague message:

Unspecified error has occurred. Aborting.

An unspecified error during a ‘chkdsk’ run is never a good thing. And so I rebooted, only to discover that my hard disk was no longer recognized by my system as a hard disk. I did what I should have done in the first place — called a couple of the friendly data recovery companies — and after listening to my story and, nicely enough, not laughing at me outright, they told me that my chances of data recovery were near zero percent. You see, when your disk is banging away like that, it’s the sound of the heads hitting the platters. And they’re not supposed to do that. When I ran ‘chkdsk’, I forced the heads to touch every surface of the platters, thereby scratching them into oblivion.

A quick trip to my neighborhood computer store, a new hard drive, and I’m more or less back in business, minus two years worth of documents, most of which I never bothered to back up. A bad way to start the weekend, but I actually can’t think of anything especially valuable or irreplacable that was lost.  This is more of an extreme annoyance.

So please, learn from my mistake, and next time you hear an odd clicking sound, don’t try to outsmart your already-broken hardware. Listen to your computer. It’s sending you a very clear (albiet perhaps Morse-coded) message. And back up your data now and again! I work hard to tell my customers about all of the great reasons they should back up their enterprise data; but like most people, I never think about applying those same behaviors to my personal machines.

As an aside, when I reinstalled Vista on the new drive I accidentally used the 32-bit rather than 64-bit media. After I realized my error I decided to stay on the 32-bit version for now and see how it performs. I was not happy with memory consumption before, and I suspect that the 32-bit version will be a bit leaner. Since I only have 2 GB of RAM in this machine, there is no great reason for me to run 64-bit anyway. I’ll post again in a while about my thoughts on 32-bit vs. 64-bit Vista once I’ve had a chance to work with it a bit more intensely.