On September 8th, I found myself on the road again, far from my home in the Seattle area, participating as a speaker at the annual SharePoint Saturday Cape Town (#SPSCPT) event in South Africa.
This was my second visit to the country this year, joining an all-star cast including well-known regional experts Alistair Pugin and Bradley Geldenhuys, SharePoint MVP Veronique Palmer, and international experts such as Paul Swider, Michael Noel, JB Howard, Mark Miller, and Joel Oleson, among others.
While the topics I present tend to center more around power-user and business analyst topics, I do try to attend a wide variety of sessions to expand my understanding of different aspects of the SharePoint platform. One of the sessions I attended in Cape Town was a presentation by Seb Matthews (@sebmatthews) entitled "PowerShell for the SharePoint IT Pro, Beyond the SnapIn" (slides available here) in which he introduced the history of PowerShell, and the value it provides to the SharePoint audience.
The History of PowerShell
At a high level, PowerShell gives SharePoint administrators more power and control over their environments. While it is often viewed as a way to avoid using Central Admin, it's not so much about avoidance of the user interface as it is a way to streamline and automate otherwise manual and tedious efforts to navigate through the UI.
According to Seb, PowerShell is not outdated, old technology, and it is certainly not just for developers -- it is command line scripting, offering a Swiss army knife-like solution to quickly get to the heart of an issue, get data, solve a problem.
Some of the features of PowerShell were modeled after Unix and Linux to help attract people with backgrounds in those environments -- in fact, Seb pointed out that in many cases, you can use Unix and Linux syntax inside of PowerShell. It is definitely a tool for the technical members of your team, to give your admins predictability and repeatability, and going far beyond what is available through the UI and Central Admin.
Several times during his presentation, Seb referred to PowerShell users as "reluctant developers," with admins using the scripting tools to give them more control and capability -- without the time and effort it takes to become a full blown developer. He also added that it was a "myth" that admins still need to use stsadm command line tool, as much of what you need to do is hidden away inside of PowerShell.
Understanding the Construct
While it takes minutes to learn the basics of PowerShell, Seb admitted that it can take a lifetime to master. The basic constructs of PowerShell include Snapins (combined collections of cmdlets), modules (anyone can build scripts and scriptlets, save off into a bundled file as a module), cmdlets ("this is the thing that I am actually typing," includes Pascal casing -- which means every line starts with a capital letter), objects (the lifeblood of developers. Something you can do something with) and pipelines (sequential actions).
PowerShell has a very simple construct: there is the Shell, or the window in which you will work; there are Blocks, a region or section in which you are focusing; there are Scripts, which consists of the things you build and save; and the Functions, which are modular scripts that be reused -- compiled script that you can call up or even pre-load.
The core principles include the Verb-noun -- we "get" something, we "set" something, we "start." Comparing a "get" to a more readily understood "read," Seb explained, is that a "get" opens up the file and takes action with it. You're inside the file, taking action on its content. On the other hand, a "read" opens the file and let's you view its contents, but you are limited on what you can do to that content.
Another principle is Loops -- For Each, Do While. This is one of the attributes that makes PowerShell ideal for SharePoint -- loops allow for automation of tedious tasks in Central Admin. And finally, Dot sourcing -- which allows you to load a function, and then load it over and over. In other words, this principle makes the action persist in that session.
Hopefully this quick overview can shed some light on what may have seemed like a foreign topic to the non-dev audience. There's a reason why PowerShell is appealing to most administrators -- it gives them the information and their control they need over SharePoint. It allows them to test for errors, scanning through their systems quickly and efficiently to identify anomalies -- and then to take action against those anomalies. But as Seb points out, there are some rules to remember:
- Do one thing at a time. Use multiple scripts rather than building complex scripts. This makes it easier to test, and promotes reuse.
- Don’t vary variables -- give variables names that mean something so that people can understand what you're doing, and so that your scripts can be used/read by others.
- Stick with the naming conventions. Again -- build your scripts in a way that make sense over time, and to other people.
- Comment your code. Another way to leave bread crumbs behind for posterity, sharing your thinking process in what you build.
- Test often.
Editor's Note: Christian writes regularly for CMSWire about all things SharePoint. To read more: