PowerShell is a very powerful tool to handle many aspects of a SharePoint farm. On the one hand there is the set of commands typically used by the administrators of the infrastructure. These people are most likely box admins and have full permissions to run PowerShell to do their daily work.
On the other hand there are many GUI tasks that can be automated by PowerShell, for example create sites, lists, manage groups and users. Some aspects of SharePoint can only be handled with PowerShell, as I learned when I searched for an answer for one of my questions.
A developer using a separate DEV environment will have complete control over that development farm and can use PowerShell to its full extent. They develop solutions, package them up and deliver them to the production farm to be deployed.
In a production farm, things will look a bit different, though. The SQL databases live on a different server, have their own SQL admin team, which is not the same group as the Server team who manage the SharePoint infrastructure. Permissions need to be set up so the Farm Admins can even run a Get-SPSite command without an error messsage, but these teams normally work closely together and will quickly establish the required procedures.
Then there is the ever growing group of Power Users, who have been skilled up and are now entrusted with Site Collection Administrator privileges. These people build sites with OOB tools, using SPD and InfoPath.
When SharePoint 2010 first came out, there was much hype about the prospect of ditching stsadm in favour of PowerShell. But it turns out that issues around governance and permissions put a spanner in the wheel.
Dan Holme put this into words in his blog post in March 2010.
Since then, many third party tools have been created to address shortcomings of SP2010.
I am interested in approaches that others are using that do not involve 3rd party products.
It is easy enough to create a repository with building blocks to put together PowerShell scripts that do things like
- create a site in a site collection, using a custom template
- repairing the document libraries that were broken during that process (see here)
- create groups and populate them with users
- add content types to lists
- configure list settings
- etc.
But then what? The Server team who have permissions to run these scripts don't want the added workload. The Site Collection Admin does not want the administrative overhead to file a request and then wait a week for it to be completed, because it is a low priority for the Server team. Ideally, a trained (!) Site Collection administrator who "creates" these scripts by filling in a list form should have a means of also running these scripts when they need to.
So they either need to be able to log onto the SharePoint server, or remoting needs to be set up, which carries all other kinds of implications.
That's how I understand the situation so far.
The farm I work with is a fairly small setup. We don't do custom development, at least not much, and there is a strict division between Server team, SQL team, and the "Citizen Developers"/Site Collection Administrators. I imagine that other setups, especially larger ones, have similar issues.
If you do not use 3rd party tools, how do you handle PowerShell access for the trained (!) Site Collection Admin?
What are lessons you learned? What approaches can you recommend? Which warnings would you give? Do you have a case study for a successful implementation? A horror story of a setup that went wrong?
Mind you, I'm not looking for a perfect answer. This is meant to be a community wiki, to collect ideas and approaches.