SharePoint Governance PowerShell Disappointment

I’m a big fan of scripting and automating administration—in fact I wrote a book that was all about practical uses of VBScript to administer Windows enterprises (Windows Administration Resource Kit ). So when I learned that Windows PowerShell was going to be the primary command-line interface for SharePoint 2010, cmdlets and all, I was very excited!

I imagined all kinds of uses for PowerShell. Site collection owners could use it to provision sites for their customers. Group owners could use it to manage group membership, or keep a SharePoint group in sync with Active Directory (AD). Content owners could have little scripts that used business logic to create or update content in SharePoint.

Then governance kicked in and that all-important part of governance—security—which trumps all. Sadly, there’s bad news for anyone who had big visions for using PowerShell to automate “anything” in SharePoint, and all we’re left with is a very capable, but perhaps not “Power”, shell. Sorry to rain on your parade.

Earlier this month, I wrote about how to delegate PowerShell access by using the Add-SPAdmin cmdlet. First, let me add one note that I failed to include in that article: The article focused on how you grant permissions (the SharePoint_Shell_Access role) to the SQL content databse. There’s one other requirement on the SharePoint side: users must be a Site Collection Administrator in order to use PowerShell. Not just an owner, member, visitor, or even a user with full control of a site—the Site Collection Administrator.

You might already be able to see where all of this is going. A “normal” user who happens to need to update content automatically, or manage group membership, or do anything else really, cannot use PowerShell without being a Site Collection Administrator. That is a lot of power, and probably more than you’d want to give most users.

But there’s more. The SharePoint_Shell_Access role is nested into the db_owner role on the SQL side. That’s right: In order to use PowerShell to do anything with SharePoint, you need to be a db_owner, which gives you the ability to read, modify, and destroy the database—for good or for evil, intentionally or accidentally.

There’s no delegation of specific rights or privileges, and PowerShell doesn’t “security trim” your capabilities.

I was assuming that PowerShell, since it uses the SharePoint object model, would simply expose what I can do with SharePoint as a user—what I have permission to do.

Instead, I need to be handed the keys to the shop in order to use PowerShell to do anything. That’s an enormous disappointment to me, because I’m not going to split my infrastructure into more site collections, let alone assign more site collection administrators, to use PowerShell to automate “anything” in SharePoint.

Just to be clear, PowerShell is extremely well suited to perform actions that a db_owner and Site Collection Administrator would perform. But even at that level, you’re going to have to consider PowerShell delegation as you decide what site collections go in which content databases, which is part of designing governance.

If I put Site Collection A and Site Collection B in the same content database, and give Owner A the ability to use PowerShell for their site collection, Owner A is now a db_owner of Site Collection B’s database, too!

I do hope this changes over time, with future releases of SharePoint 2010+. But for now, governance and security models proved to be the Kryptonite to my PowerShell dreams.