Microsoft Office Tutorials and References
In Depth Information
With PowerShell, things are different. Maybe because the tool is so new or maybe because it has
been more the focus of developers than administrators, PowerShell requires the accounts that use
it to be very powerful, possibly insecurely powerful. For an account to use PowerShell, it must be
a local administrator of the SharePoint server. Then it must have ownership rights to the farm’s
configuration database, as well as be a farm administrator (meaning that the account will be added
to the WSS_Admin_WPG group on the SharePoint server). If that account also has to do any work
in a specific web application (site collection, and so on), it must also be an owner of the content
database in SQL related to the web application (or site collection). So, for a farm administrator to
be able to work on anything the farm needs, the account needs to own (have the owner permission
in SQL of) all content databases and the configuration database of the farm.
There is a PowerShell cmdlet (otherwise known simply as a command ) that is used to give accounts
PowerShell admin rights, add-spshelladmin. This command has to be run by an account with
the rights to do so in order to apply the correct permissions to the added account so it too can use
This causes a chicken-and-egg scenario: you need to give shell admin rights to accounts to work
in PowerShell, but there is no account available to run the command to give the rights to other
accounts...except for the farm account.
The farm account should never, ever, ever be logged in and used as a normal account. This account,
if made (very temporarily) a local administrator of a SharePoint server, could open the SharePoint
Management shell (Start menu All Programs Microsoft SharePoint 2010 Products SharePoint
2010 Management Shell) and be used to give shell admin rights to the accounts or AD security
group that need it. Then, when you are done using it, log the account out, log back in as a normal
administrator, and remove the farm account from the local administrators group (SharePoint hates
it when the farm account is a local admin, and there may be an error saying so, if it notices what
you’ve done).
When an account is added as a shell admin account, it is added to the configuration database in
SQL with the owner role and a SharePoint-specific role called SharePoint_Shell_Access. If you want
to have an account also be able to manage a content database of a web application via PowerShell,
they need to be added as a shell admin specifically to that database (or databases). In doing so, the
comdlet adds the SharePoint_Shell_Access role to the database and then gives the account rights
to it. Conceivably, you can have different shell admins with rights only to make changes to the
configuration database (by owning it) and to only a certain content database that you have
specified. Usually I use an account that is added as a shell admin to all databases for the farm. I consider
it my PowerShell super-admin account.
Keep in mind that site collection administrators should not be given PowerShell capabilities if you
only want them to be capable of managing their own site collection. PowerShell admins are able to
manage everything in a web application they are given rights to (which contains site collections, so
they’d manage all of them) or nothing. Site collection administrators will still have to use STSADM
for their command-line work.
There is an entire chapter dedicated to getting you up to speed with PowerShell (Chapter 14,
“STSADM and PowerShell”), but I wanted to give you some advanced warning when planning for
SharePoint, that there may be the need to give a few accounts a lot of power to do damage, not just
to every database related to SharePoint but potentially to SQL as well (since every account will
need a login role).
Search JabSto ::

Custom Search