This marks the first post in a new series on using Windows PowerShell with SharePoint 2010 (possibly the best marriage of concepts since Hewlett and Packard—a befitting reference given all of the mention of WebOS in the news this week).
In order to take advantage of the true power of PowerShell (no pun intended), you need to have at least a little bit of background on how to get started. While we will be using the SharePoint 2010 object model with PowerShell, you don’t need to be a true developer to take advantage of (some of) the powerful capabilities contained within the beast. As we progress toward the path of writing our own cmdlets and such, the discussion will inevitably turn more dev-focused, but for now let’s focus on the basics.
PowerShell as a Technology
Windows PowerShell is just that, a “Windows” product. In fact, it’s the native Windows management shell, not a technology that’s unique to SharePoint. The nice thing about this is that we can use PowerShell to interact with Windows components, such as services and operating system configuration, in addition to Active Directory, SQL, and other products (including SharePoint).
PowerShell vs. SharePoint Management Shell
If you’ve been poking around on your SharePoint server, you may have noticed that you have two separate shell’s on your system—PowerShell itself, and the SharePoint Management Shell . Aesthetically, the only difference between the two is that the SharePoint Management Shell is black (which gives it more of a command prompt look), and the PowerShell console is actually blue. Both consoles are technically PowerShell, and I’ve got no idea why the SharePoint one is black—unless it was simply to ease the transition from STSADM to PowerShell.
You can open the SharePoint Management Shell from the “Microsoft SharePoint 2010 Products” folder in the start menu. Native Windows PowerShell can be opened either via the PowerShell icon on the task bar, or by navigating to “Accessories” -> “Windows PowerShell” from the start menu.
Functionally, there are a few differences under the covers. When you load the SharePoint Management Shell, it will automatically load the necessary SharePoint components without you having to do any additional steps. In short, you can open it up and fire away. The native PowerShell console won’t (by default) load the SharePoint components, so if I were to open PowerShell and execute something like a simple Get-SPSite command, I’d be greeted with a big red error message saying that it doesn’t know what the Get-SPSite cmdlet is.
So what are these “components” that are being loaded? PowerShell components are broken into two categories: Snapins and Modules. Snapins can be easily loaded by executing Add-PSSnapin and Modules can be loaded by using Import-Module. You can load a snapin anytime you need to, or you can build a custom profile for PowerShell that’ll automatically execute every time you load the console—loading the snapins and modules you frequently use (such as the SharePoint snapin).