The title of this article also happens to be the title of my PowerShell book. For a long tiem I’ve been wanting to go and write a non-technical article explaining how I envision the future of traditional IT shops with the rapid growth of PowerShell in the industry. When I first started working with SharePoint 2003 back in 2006, my role was to develop several webparts and application pages for my company. The environment I was maintaining had over 1,500 site collections with about 150 sites each. Whenever I created a new webpart, I had to go back and add it retro-actively to all sites (150 * 1,500 = 225,000 sites). Off course there was not way in hell I was going to do this manually. Instead, I started creating new console applications from within Visual Studio (VS 2005 at the time), and had to my application loop through all site collections, through all sites, and add the webpart to the main page of each one using the SharePoint Object Model and some C# code. Then my application was packaged as an .exe (a.k.a. total black box), and this executable file was sent off to the servers’ administrators for them to execute directly on the SharePoint servers (starting with the dev environment off course). I can just imagine being in their shoes, where some crazy developer just gave me a piece of executable, that I need to trust does
what the developers says it does, and then simply have to execute it on the server and wait for hours for it to complete. I used to be known as the “Dev cow-boy” back then due to my total lack of risk adversion 🙂 Depending on the timeframes I had, I would even threat the administrators with some verbose logging of what was really happening in the background…..if I had the time. Otherwise, they would be starting at a good old black MS-DOS style dialog for quite a while.
That is how I use to do it back in the days. The dev guys were doing the work, and then the admins had to trust them entirely, and only be invovled at the very end of the process, whenever the code was all finalized. They had no say really in the code’s logic, and had no exposure to the SharePoint object model. This very often initiated very interesting discussions between the dev teams and the administrators. “You need to activate the feature at the SPSite level!”……”Say what???”. On one end you had developers spending their times in C# and the SharePoint object model, and on the other end, you had the administrators trying to do everything using batch files and STSAdm.ex
e. Looking back at it, I think the worst part was that developers used to improvised them as being adminsitrators. I remember my team creating such a .exe console app to automate the creation of Shared Service Providers (SSPs), the ancestors of the SharePoint 2010 Service Application architecture. This is some scary stuff, since the devs at total control over components that could directly have a huge negative impact on the overall stability of the environment (god knows that th SSPs were shaky at best). Back then, the gap between IT Pros and the developers was incredibly hard to bridge.
Then towards the end of life of SharePoint 2007 (beginning of year 2009), a new technology emerged at Microsoft: PowerShell. This technology opened up a lot of possibilities for both the developers and the IT Pros. First off, it was for most scenario, faster to accomplish a task than the STSAdm. Secondly, it now allowed developers, who were willing to learn the language, to provide their servers admins with a clear text .ps1 file that they could open and read instead of the scealed box that was the console applications my team used to write. Even if the IT Pros didn’t want to learn the object model and understand exactly what each line of code was doing, it was at least giving them the false feeling that it was not only a Dev thing anomore, and that they had some little more control as to what was being execued on their servers. One problem remained however, in order for one to write an efficient script, they had to learn and understand the SharePoint Object model. Back then, with SharePoint 2007, you didn’t have any PowerShell cmdlets to help you out. So for example, if you w
ished to acquired the number of items contained in a specific SharePoint list, say “Fruits”, your code would have looked like the following:
[Void][System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)
$site = New-Object Microsoft.SharePoint.SPSite(“http://portal”)
$web = $site.RootWeb
$list = $web.Lists[“Fruits”]
$count = $list.Items.Count
Therefore, even if there was some light at the end of the tunnel, there was still a huge gap in that in the eyes of IT Pros, the lines of code above are dev specific and most of them had no interest in learning how to become a programmer.
Then at the end of year 2009, Microsoft revealed what was to become SharePoint 2010, and everything changed. Microsoft introduced over 400 SharePoint specific PowerShell cmdlets. These “shortcut” methods made the code required to accomplish a set of very powerful actions against a SharePoint environment extremely simple, and most of all, human readable to both IT Pros and Devs. I think that this is where the true power of PowerShell resides. Both developers and IT Pros were now given the tools to write their own scripts. Off course IT Pros still had to learn a bit about the Object Model if they wished to interact with what I consider to be lower level objects (lists, items, views, pages, etc), and developers still had to understand some SharePoint architecture concepts if they wished to interact with higher level objects (Shared services applications, Web Applications, etc.), but all in all, the gap between devs and admins was being bridged! Based on my example above, with the venue of SharePoint specific PowerShell cmdlets, one could now achieve the same result with the following lines of code:
$web = Get-SPWeb http://localhost
$list = $web.Lists[“Fruits”]
$count = $list.Items.Count
3 lines instead of 6, and the code if much more readable.  PowerShell is just that great. It completely changed the story for SharePoint as far as I am concerned. You guys just stay tuned for what is coming up with SharePoint 2016 🙂 !
