One of the major investments made by Microsoft during the development of SharePoint 2010 was in support for Windows PowerShell. Even if you've not used PowerShell before, you'll find that the cmdlets (pronounced command-lets) and structure of PowerShell makes it easy to learn.
In future newsletters and issues of SharePointPro Connections magazine, we'll be tackling common administrative tasks with PowerShell. But first, you need to be given permissions to use PowerShell against the SharePoint farm, so let's talk about the required delegation.
In order to use PowerShell, an administrator must be assigned the SharePoint_Shell_Access role on any databases against which PowerShell will be used. For example, to perform tasks that read or manipulate data in the configuration database, an administrator must have the SharePoint_Shell_Access role for the configuration database. Likewise, to work with a specific site collection, the admin must have the SharePoint_Shell_Access role for the appropriate content database.
Additionally, the administrator's account must be a member of the WSS_ADMIN_WPG local group on all servers in the farm.
To assign these two roles, you can use the Add-SPAdmin cmdlet. The syntax is pretty straightforward:
1. Open the SharePoint 2010 Management Console.
2. Set a variable reference to the content database. For example, to refer to the content database named WSS_Content_Intranet:
$spcdb = Get-SPContentDatabase WSS_Content_Intranet
3. Invoke the Add-SPAdmin cmdlet to grant a user, for example for CONTOSO\Dan_Admin, the ability to use PowerShell against that database:
Add-SPShellAdmin -username CONTOSO\ Dan_Admin -database $spcdb
So with just two commands, you've given the user the SharePoint_Shell_Access role on the database and added the user to the WSS_ADMIN_WPG local group on each server in the farm. If the user is currently logged on, the user will, of course, have to log off and log back on for the new local group membership to take effect.
In order to perform this delegation, you must have the Security_Admin server role for the SQL instance and the db_owner role for the database, and you must be in the Administrators group of each server in the farm.
In other words, you're a "super admin." Practically speaking, you'll likely be administrator of the SQL Server server and of each server in the farm, though technically speaking you don't need quite that much power.
Details can be found in this article on TechNet: "SharePoint 2010 Products administration by using Windows PowerShell."
The good news? If you're an administrator of your SharePoint environment, you can easily grant other admins the ability to use Windows PowerShell to administer and automate SharePoint.
The bad news? First, if you're an administrator of your SharePoint environment, you can't use PowerShell until you've delegated yourself the ability to do so. This will actually be a bit tricky for larger, least privilege environments in which the SQL Server farm and the SharePoint farm are administered by separate teams. There's going to have to be some cross-pollination of privileges in order to make this all work.
Remember that in order to perform the delegation, you require pretty significant privileges both on the SQL Server side (Security_Admin) and on the SharePoint side (local Administrators group). I know a few enterprises are going to have to breathe deep and "get over" that.
The second bit of bad news? Tune in next week.
