Summary: Guest blogger, Todd Klindt, reflects on his experience learning Windows PowerShell. Microsoft Scripting Guy, Ed Wilson, is here. One of the cool things about writing books for Microsoft Press is that I am brought into contact with people that I otherwise might not talk to. I asked Todd Klindt to write a sidebar about his experience learning Windows PowerShell. He took the task to heart, and ended up writing a great, although long article. It was too long for a side bar in my book, but it was great information, so I asked him if I could use it as a Weekend Scripter blog post—with the understanding that he would write a more concise version for the book. He readily agreed! Here is Todd’s bio from his website:

Todd has been a professional computer nerd for over 15 years, specializing in SharePoint for the last eight years. His love affair with SharePoint began one slow day at the office when he discovered SharePoint Team Services 1.0 on the Office XP CD that was holding up his coffee cup, and he decided to install it. The rest is history. In 2006 he was honored to be awarded the MVP award from Microsoft for Windows SharePoint Services.

He has had the pleasure of working with SharePoint farms both large small. He has written several books and magazine articles about SharePoint. Todd has presented sessions about SharePoint at many major conferences in the United States, Europe, and Asia. He speaks on the user group circuit, at SharePoint Saturday events, and the occasional children’s birthday party. He chronicles his SharePoint adventures at Welcome to Todd Klindt’s official web site.

His latest book, Professional SharePoint 2013 Administration, published by Wrox, is now available at fine booksellers everywhere. You can buy it from Amazon, or buy a signed copy directly from Todd. It’s a page turner—it’s got action, intrigue, romance, and Windows PowerShell.

He is currently working his dream job as a SharePoint consultant at Rackspace where he spends his days fixing broken SharePoint environments and bringing new SharePoint environments into the world.

If you’re bored, you can follow him on Twitter @toddklindt. If you’re looking for Todd’s latest SharePoint netcast, go his Netcast Homepage. So without further ado, here is Todd Klindt… I’m a SharePoint guy by trade. I live and breathe SharePoint. If I had to pick my second favorite technology, it just might be Windows PowerShell. But, that wasn’t always the case. In this post, I’ll tell you the tale of how I did everything I could to avoid Windows PowerShell, and how it eventually wormed its way into my heart and won me over. The year was 2002. I was young and impressionable when I got my first exposure to the technology that would dominate my career for the next decade: SharePoint. I started with SharePoint Team Services 2001, and then continued with Windows SharePoint Services 2.0 and Microsoft Office SharePoint Server (MOSS) 2007. By the time my company got to MOSS 2007, we had 1000 site collections and over 10,000 websites. The only way to keep that kind environment under control is with a lot of sweat and automation, and I was all over it. SharePoint Team Services 2001 had a command-line tool (owsadm.exe) that hard-core administrators like myself could use to automate common tasks. That was my first foray into taming SharePoint with automation. With the move to Windows SharePoint Services 2.0, owsadm.exe was replaced with stsadm.exe, and that’s when the magic really started to happen. Like owsadm, stsadm was written by the SharePoint team exclusively for SharePoint, and its audience was only SharePoint professionals. This made stsadm very narrow in its focus, which was good and bad. It was good because it was built to do common SharePoint tasks, and it integrated very easily with SharePoint. It was bad because it wasn’t easily extensible by non-developers. If you wanted to add or change functionality with stsadm, you needed to break out Visual Studio—and we all know nothing good ever comes from that. For SharePoint administrators, though, it was easy to use. It used only strings for parameters and its output was also only strings. These output strings were in a very predictable form because you couldn’t customize stsadm or its output. Some of us more enterprising SharePoint administrators would write VBScript scripts that took the string output from stsadm and parsed through it to do tasks on individual objects. For instance, I used a 40-line VBScript script that would take the output of “stsadm -o enumsites” and perform a site collection backup of each one. It wasn’t pretty, but it was easy, predictable, and focused exactly on SharePoint. On a less technical note, my experience with stsadm had been good to my career. My first magazine article about SharePoint was about stsadm. The first book chapter I wrote about SharePoint was about stsadm. The first big speaking gig I did was TechEd 2007 on, you guessed it, stsadm. We even named our cat Stsadm. OK, not quite, but stsadm had been very good to me. And then SharePoint 2010 came along. There were a lot of great improvements in SharePoint 2010—a lot of things I should have been excited about. But the biggest, scariest, news overshadowed it all: stsadm was being deprecated and being replaced by Windows PowerShell. Windows PowerShell? That crazy technology that used to be called Monad? Wasn’t that something developers used? I’m not smart enough for Windows  PowerShell! And Windows PowerShell, is much, much too complicated for the tasks we SharePoint administrators need to do. Sure, stsadm had its limitations, but it was easy to use, and it only did SharePoint. I was in Redmond on the Microsoft campus when I first heard that horrible news. My first reaction was shock. I thought maybe I had misheard. I hoped I had misheard. But I hadn’t misheard. After it sunk in that they were serious about this, I got mad. Why were they making the job of the already overworked and underloved SharePoint administrator more complicated? It felt completely unnecessary. Stsadm could be extended, why didn’t they just extend that to handle all the new SharePoint 2010 functionality? That way, we could continue to leverage our existing skills instead of having to learn this new technology. I wasn’t too excited about all this. After the session was over, I quietly and politely approached the SharePoint product team member that had broken the bad news to us all. I respectfully and methodically voiced my concerns, hoping that I could talk them out of this wild course of action. In reality, I probably alternated between yelling and crying.  At the end of the conversation, it was very clear that they weren’t going to listen to reason, and this PowerShell thing was here to stay. I needed a quart of Ben & Jerry’s Chunky Monkey ice cream to drown my sorrows. After a week of binging on some tasty frozen treats, I was ready to buy some larger pants, then dig in and start learning Windows PowerShell. I went to Amazon and bought the most popular book about Windows PowerShell and dug in. That lasted about three minutes. The book was great, but it was boring. It was teaching me how to do things like add numbers or concatenate strings. Important tasks, for sure, but not really what I needed to get me fired up. My excitement was fading. I decided that I needed to rethink my Windows PowerShell strategy. Instead of learning Windows PowerShell by book, I decided to force myself to start using it. I took every-day activities, like creating a site collection…activities that took me 30 seconds in central admin, and I forced myself to figure it out in Windows PowerShell. I’m ashamed at how long those simple tasks took me initially. The learning curve was pretty steep. Things that would take me a couple of minutes with my usual means could take me an hour with Windows PowerShell. The SharePoint PowerShell cmdlets had cryptic names and confusing parameters. Also trying to work through the Windows PowerShell syntax was painful for someone used to a simple tool like stsadm. I figured out simple cmdlets like Get-SPSite pretty quickly, but knowing what to do with the output was a completely different story. Stsadm was easy. You couldn’t do anything with the output without going to a lot of effort—like the 40-line VBScript script that I mentioned earlier. Because of that, the stsadm operations tried to be all encompassing. Without any extra effort, Get-SPSite only outputs the site collection’s URL, and in SharePoint 2013, its compatibility level. That’s it. Without knowing about piping and Select-Object, it’s impossible to get any other information. By contrast, “stsadm -o enumsites” returns a whole screen full of information about each site collection, without any extra work. Discovering how to coax more information out of Get-SPSite is tough for a Windows PowerShell newbie. I had to learn what an object was. That was knowledge I hadn’t been burdened with in the years that I was using stsadm. But I powered through it—hard fought victory after hard fought victory. And I slowly started getting the hang of this Windows PowerShell thing. Finally! I spent the next few months accidentally learning Windows PowerShell while I was relearning how to automate tasks in SharePoint. After I learned a few key cmdlets like Get-Command, Get-Help, Get-Member, and Get-Alias, Windows PowerShell got a lot less frustrating and lot more fun. After a while, I felt like I had tackled most of the common SharePoint tasks that I was used to performing. I could create webs, site collections, and web applications even without having to pull up Bing. Sometimes I could get it without the aid of Get-Help. Once, I even did it blindfolded, but I was just showing off that time. As any of you who have used Windows PowerShell know, it inspires you. I wasn’t content simply doing my regular SharePoint tasks anymore. I found myself going over other SharePoint tasks to see if I could do them with Windows PowerShell. Turns out I could. That 40-line VBScript script I’d been using to back up individual site collections was one of my first conquests. What took stsadm and VBScript 40 lines took one line in Windows PowerShell. Although I was a long way from Windows PowerShell mastery, I had overcome my initial dislike and fear of Windows PowerShell. It was fun now. I found myself looking for ways to use Windows PowerShell. I found myself trolling through the SharePoint object looking for ideas to write Windows PowerShell scripts. It became a joke with my coworkers. One of my coworkers was looking for a way to do something in SharePoint. Another coworker replied, “Do what I do. Tell Todd it can’t be done in Windows PowerShell. Then sit back and relax and wait for the Windows PowerShell script he sends you.” So although Windows PowerShell might seem intimidating at first, it’s not. It’s a big cuddly bunny just begging to help you automate all those boring tasks you have to perform. The learning curve might be steep, but just roll up your sleeves and dig in. Before you know it, you won’t be dreading your time with Windows PowerShell. Instead, you could find yourself loving Windows PowerShell and wishing you had embraced it sooner…like I did. ~Todd I want to thank Todd for taking the time to share with us today. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson, Microsoft Scripting Guy