SharePoint and PowerShell: Not for Users

My column last week ("SharePoint Governance PowerShell Disappointment") raised a number of questions that I wanted to answer and clarify.

The gist of the column was that the use of PowerShell is somewhat restricted by the facts that, to use PowerShell, you must have the SharePoint Shell Access role for the content database, and you must be a Site Administrator for the site collection. From a governance perspective, this means you effectively have (or can give yourself) full control for all content in every site and site collection in the content database, and/or can delete or otherwise foul up the content database, accidentally or intentionally. I have been referred to as “Mr. Least Privilege” and this design doesn’t begin to recognize least privilege.

Many of you wrote back with a similar theme: “I would never want users to use PowerShell.” In fact, I agree—to a point. I wouldn’t want to train or expect users to write PowerShell scripts. No, no, no!

However, scripts are more than just a bunch of commands. PowerShell can perform actions behind a form, so I could have a form that a user fills out when an employee joins their team. On clicking “submit” the script behind the form could add the user to the SharePoint team site, to the Active Directory group that has permission to the file share, and to the group mailbox on Exchange.

Another form might be used to log information. For example, I have a client that has their Windows laptops run a script once a week, as a logon script, at which point users select the office site where they are currently working. That information gets populated in a log database. It would be so great for that information to go to a SharePoint list. For another client, we ran computer startup scripts to collect asset management information without having to deploy a tool such as System Center Configuration manager. The script did everything behind the scenes, using the credentials of the computer’s Active Directory account. Again, I’d love to “push” that information to a SharePoint list where so much more can be done with the information without requiring code (workflows, versioning, etc.).

There are a number of business scenarios that fall into two categories:
•Provisioning: a multi-step, possibly multi-technology process
and
•Automated content generation

Both of these scenarios can be forms-driven or automated. Yes, there are other options (InfoPath can meet some of these requirements, for example, but not others), but PowerShell is now the preferred automation tool across all of the primary components of the Microsoft technology stack, and I find it unfortunate that in the case of SharePoint, PowerShell doesn’t simply leverage the identity of the user and the permissions that the user has been assigned within the SharePoint object model. It’s unfortunate that it’s “all or nothing” (db owner or nothing).

So I understand your cries of concern that I might be suggesting users write PowerShell scripts. Not at all! I simply want the option of providing scripts, perhaps scripts behind forms, or scripts running in automated fashion (logon, logoff, startup, shutdown, or scheduled) that can run under a user’s less-privileged identity.