Managing SharePoint 2010 Access Request Settings Via PowerShell

SharePoint has a built-in mechanism to manage access requests. Users can request access to sites and documents when they are denied access, or they can request additional privileges to update content if they only have read access.

The requests go to one or more email addresses which are defined at the site level. The definitions follow inheritance, meaning that if a child site inherits its parent’s permissions, the child site will inherit the access request settings as well. The property to check if a site is inheriting permissions is named HasUniqueRoleDefinitions.

There are two properties which control the access request configuration, first is RequestAccessEnabled, a Boolean flag which turns on or off the access request feature for the site. The second property defines one or more email addresses where requests will be sent to. It is named RequestAccessEmail. To specify multiple email addresses, separate each with a semicolon. The image below illustrates the GUI for modifying these two properties. It is accessed on the site permissions page, on the far right of the ribbon.

Today I will share some sample code which walks through every site collection and site within a given web application, and writes to the screen the relevant access request settings.

Add-PSSnapin Microsoft.SharePoint.Powershell
$webapp = Get-SPWebApplication "Portal Home"
foreach($spsite in $webapp.Sites)
   foreach($web in $spsite.AllWebs)
      Write-Host "On Web" $web.Title ", URL" $web.URL
      if (!$web.HasUniqueRoleDefinitions) {
         Write-Host "`tAccess request settings inherited from parent."
      if ($web.RequestAccessEnabled) {
         Write-Host "`tAccess requests go to :" $web.RequestAccessEmail
      else {
         Write-Host "`tAccess requests are disabled."

Search for Commands Using Command Line Tools

Command line management on SharePoint 2007 is handled by STSADM.EXE, and on 2010 by PowerShell commandlets. There are so many options it is hard to keep track.

Using the command line on 2007, the first step to easy access to these commands is to add the path to the executable (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN) into your environment path variable.

Now you can open a command prompt and type stsadm <Enter>. When run without any parameters, it will display help information. The problem is there are so many pages of information it zooms by very quickly. If your buffer is large enough, you can scroll back through the output. Alternately, you can pipe the output into more, and view it one page at a time.

But typically you are looking for a particular operation (-o). Say for example, that you are looking for the operations relating to solutions. In this case, pipe the output to the find command, filtering on the string you are looking for.

stsadm | find “solution”

Then to see the syntax for the operation you want, run it without any parameters, and if additional parameters are required, the syntax will be displayed.

stsadm -o addsolution

In SharePoint 2010, stsadm is still available, and the technique above works the same, but I highly recommend switching to PowerShell. In PowerShell, SharePoint operations are provided via Cmdlets which are loaded automatically in the SharePoint 2010 Management Shell.

If you open Windows PowerShell, you can load the SharePoint Cmdlets with this command:

Add-PSSnapin Microsoft.SharePoint.Powershell

To see a list of all Cmdlets offered, use:

Get-Command -module Microsoft.SharePoint.Powershell

To filter the results, pipe the output to Where-Object:

Get-Command -module Microsoft.SharePoint.Powershell | Where-Object {$_.Name -like “*solution*”}

Obviously this is much more complicated than stsadm and find. When I come across an easier method I will update the post. Feel free to leave a comment with your suggestion.

To see the help information on a particular Cmdlet, use the Get-Help Cmdlet, or the -? parameter:

Get-Help Add-SPSolution


Add-SPSolution -?

Update 6/21/11

Get-Command accepts wildcards in it’s default parameter, and shows Cmdlets from all loaded modules. To simplify my example above, it is not necessary to specify the -module parameter, and the filter specified as so:

> Get-Command *solution

Much simpler, yes?!?