PowerShell for SharePoint Admins – The REAL primer PART I

I’m not a developer.  I am a straight up ITPro/Admin/Infrastructure guy.  Oh, I can code.  I just don’t like it and only do it when I absolutely HAVE TO.  I find no pleasure in creating “cool apps” that do “cool stuff”.  Opening up Visual Studio doesn’t make me want to vomit or even make my eyes roll into the back of my head, but it *does* make me sigh heavily saying under my breath, “Is this absolutely necessary? “  If so, then so be it.  Mostly my development experience is looking at a Dev’s code and figuring out what he/she wrote that broke SharePoint. 

So why, say some ITPros, are you blogging about PowerShell?  ITPros are very reticent about anything that resembles having to “code”.  Writing scripts is about as far as most are willing to go.  Most ITPros (the traditional administrator) feel most comfortable at the command prompt somewhere between traversing directories, to writing batch files to carry out unattended installation operations.  Some even feel comfortable at writing more complex operations using some scripting engine such as JScript, WScript, CScript or VBScript.  Some have written WMI scripts to manage their network environments.

What’s the Deal?

Most ITPros (myself mostly as well) say, “Why write code to do what I can do from the GUI even faster?”  For example, look at this:

strComputer = "DC01"

Set wbemServices = GetObject("winmgmts:\\" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_LogicalMemoryConfiguration")

For Each wbemObject In wbemObjectSet
    WScript.Echo "Total Physical Memory (kb): " & wbemObject.TotalPhysicalMemory
Next

A typical old school ITPro admin (OSITA) would say “PFFT…just hit Ctrl-Alt-Del !” (Well…an old school admin may not know what the script does, but you get the picture).  But what happens when I need to do something that, if I did it via GUI, would take F-O-R-E-V-E-R?  Here’s a scenario:

You are the administrator of Contoso Inc.  Your company has merged with another company, NWTraders and you need to import their users into your Active Directory database.  Their AD will be decommissioned.  They are explicit in their desire to simply created new users with new sIDs in Contoso’s AD.  NWTraders had 10,000 users.  A typical old school ITPro/admin (OSITA) would probably do one of two things:  a) Get a third party tool to do it, or b) find a script online that will do it.  Let’s modify the scenario and say Contoso will not pay for the third party tool. 

Now you’re stuck,  Mr./Ms Hard Core Old School ITPro/Admin.  What are you going to do?  What script will you use?  How do you know that it will work?  Here is a hint:  Learn how to script; fast.  As Shane Young and Todd Klindt have said in their traveling minstrel shows: It’s not that bad. (and neither are their sessions)  ;)

If you are like me, the quintessential ITPro, you have attempted to try to be a Dev once.  ONCE.  You took a few programming classes and at the end wondered why you wasted all that time trying to figure out how the new terms all fit together in any sort of coherent meaning.  Object, Class, Argument, pass, etc…WHAT?? 

My first official class in object-oriented programming was Visual Basic 3.  It was a 5-day course with the “Introduction” to VB being 2 days, the “Intermediate” being 2 days and “Advanced” being the last day.  Ha!  I held my own the first day, but struggled the second day.  I was totally lost the third day and playing solitaire by the fourth day.  I don’t even know why I even showed up on Friday.  I didn’t try my hand again until about three years later when I took VB6.  I was much better that time around and about four years after that I took ASP.NET.  #FAIL!

I was fine looking at code and knowing what it was intending to do, but to actually *write* something was just too….hard.  When SharePoint came around I knew I would have to pick it back up again, so I did.  I got a C# book and just hacked my way through it.  Not too hard, not my cup of tea—but meh…I did it.  When PowerShell came out, I said…hmmm…this isn’t so bad.  It’s like…batch scripting; almost—just more wordier.

The What

This brings us to “What is PowerShell”.  You’ve probably heard of PowerShell and if you are a hard-core, old school ITPro admin (OSITA)—you’ve been putting off learning it because you think, well, it’s almost like writing code.  Sigh…GET A GRIP!  You learned learned how to use DIR, COPY, MD, RD, and maybe even CHOICE—so learning a few more things won’t hurt…much.  I promise. And YES, it is important and YES you will need to know it because SharePoint 2010 administration will rely heavily upon it.

I understand your reluctance.  I do.  What I will attempt here is to walk you through a Pain-Free tutorial/primer in PowerShell for SharePoint. Powershell Primer for Serious Non-devs.  You know what they say: No Pain, No Gain—well, I am about No Pain, No Pain.

Again, most old-school ITPro admins (OSITA) were all about the “How”.  “Just show me how to do it so I can get on with more important things.”  I get that.  There is some value in knowing the “Why”.  This is where the OSITAs get tripped up.  The explaining in why this works.  While I promise not to go into the workings, I will explain in layman’s terms what is happening.  It’s important to know these things, because it helps in the long run when it comes time to build upon knowledge already garnered by previous experience.  For example, if I wanted to order a directory listing alphabetically and only a page at a time, I would type DIR /O /P.  I would know this only if I knew three things:  a)that DIR was the command for a directory listing, b) that there were parameters that I could type with DIR and c) How to find out what the parameters were  Same thing in PowerShell.  I will teach you something extremely simple, where to use it, what (if any) parameters you can use with the cmdlet, and finally how to find out if there parameters you can use with it.

The How

OK, so now for what the OSITAs have been waiting for—”Just show me the goods”.  Right. There are a few assumptions I will make:

a) I am going to assume you know NOTHING. Absolutely NOTHING. If you are a Dev here trolling for something…you are put on notice—this will bore you.

b) I am going to assume you have a Windows 7 workstation or a Windows Server 2008 machine to type from. Don’t gripe if it works differently in Windows XP, Vista or Windows Server 2003.

The first thing you need to know is how to get to the PowerShell command prompt. First, go to a command prompt and type ‘powershell’ (without quotes) as shown:

That will bring you to the PowerShell prompt.  How ‘bout that?

This is where you will finally see that things aren't so bad.  Most of the commands you are familiar with are available here; type DIR and see what happens.  Here’s one:  let’s create a directory for us to put our scripts into.  Remember how to create a sub-directory?  MKDIR or MD.  Call it scripts.  Your output should look like this:

Now change to the scripts directory.  Do you remember that command?  CD. 

So, right now you should be feeling pretty good and comfortable.  Nothing new so far.  So let’s show you something new.  Go back a directory and do a directory listings.  That would be typing ‘CD..’ and then typing ‘DIR’ like this:

Now for the new stuff.  In PowerShell, the command that does the same thing as DIR is ‘Get-ChildItem’.  Type ‘Get-ChildItem’ (without quotes).

Wow! You get the same thing!  So now you are thinking—“Why type all of that when DIR will suffice?”  Well, good question.  The point is to understand syntax so that building upon this knowledge will help you in the future.  So don’t just type dir anymore…use Get-ChildItem from now on. 

The Why

Get-ChildItem is a PowerShell cmdlet (yeah, I slipped that new term in) that does the same thing as DIR.   The way Powershell syntax works is a [Verb]-[Noun] pair.  In the previous demo, we told it what to do (verb) with GET, and then we told it what we wanted (noun) with ChildItem.  Let’s say we wanted to know the date.  We would tell the system what do with a verb (in this case GET) and what we wanted with a noun (in this case DATE).  Type Get-Date.

In PowerShell, syntax is very important.  Just know that when you want to use it, go at it with Verb-Noun and add any parameters you may need.  But what parameters are available?  Remember HELP ? In PowerShell, HELP is awesome!  But it doesn’t just stop at HELP.  Let’s say that I needed help on Get-Date.  Let me type help Get-Date and see what I get.  Notice what I point out in the help:

Yeah, you can actually get *examples* of how to use the cmdlet.  Let’s do this; type help Get-Date –examples >>get-date-example.txt  Why?  Because it will take what would normally print out on the screen and create a text file called get-date-example.txt and put that file in our scripts directory.  Using the >> sign will “pipe” screen output to a file.  More on “Piping” later.

After typing in the command you will get a text file with examples of how to use the Get-Date cmdlet.  Cool, huh?  What’s that you say?  Too many cmdlets to remember? Not a problem, here’s a new one: NEW-ALIAS.  This particular cmdlet is for us “memory challenged” admins.  Why type Get-Date when all I might be able to type is ‘gd’?  How does it work?  Let me show you:

That’s it!  Now instead of typing Get-Date, you can type gd and it will give you the current date.  Now for the bad news:  It’s only good for this PowerShell session; so as soon as you type EXIT or close the command prompt, your new alias of ‘gd’ will get forgotten.  Don’t worry, I’ll teach how to make it persistent in Part II of this Primer.

Coming Up Next

In Part II I will show you how to make aliases you create persistent as well as going a little deeper into what you can do with Aliases.  I will also start showing you the specific cmdlets used in SharePoint administration.