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.
Continue reading this article:
Source : cmswire[dot]com
No comments:
Post a Comment