Mystery of the missing SharePoint Alerts!

We’ve been working with a client for a few weeks on and off regarding an issue with their SharePoint instance following a migration project (not conducted by us) which had the effect of breaking the alerting function for SharePoint Issue Lists which they use heavily throughout their organisation.

A quick visual inspection on their server and some digging with PowerShell showed nothing out of the ordinary, in fact it mirrored my test environment identically apart from the fact alerts weren’t being sent.  I stepped through the excellent and comprehensive SharePoint Alert Troubleshooting Guide which on another day would probably have resolved the issue but not this time.

As you do when you get to the hopelessness stage of a SharePoint issue you sometimes find the problem fixes itself and this was (almost the case here).  In the advanced settings of a SharePoint Issue list there is a Yes/No option titled “Send e-mail when ownership is assigned?” which was set to “Yes” as it should have been.  I changed the value to “No”, clicked OK, changed the value back “Yes” and clicked OK again and suddenly alerts sprang back into life! Disbelief is only word I can use to describe how I felt about the whole issue!  Looks like somehow during the migration, the “Yes” value of this property got lost yet this wasn’t reflected in the SharePoint UI.

Anyway, as the client had over 50 issues lists I decided to automate the process as I didn’t fancy doing the task manually, so here’s a handy PowerShell script to “toggle” the list back into life!

$site = Get-SPSite "http://localhost"
foreach ($web in $site.AllWebs) 
{
  foreach ($lst in $web.lists | where-object {$_.BaseType -eq "Issue"}) 
  {
	$lst.EnableAssignedToEmail = $false
	$lst.Update()
        $lst.EnableAssignedToEmail = $true
	$lst.Update()
  }
}
$site.Dispose()

Solving SharePoint Site “Error: Access Denied”

I’ve been battling the dreaded “Error: Acces Denied” dialog when trying to access a subsite in a SharePoint site collection.  The oddity of the situation is that I can access the parent site no problem and the subsite is set to inherit permissions!

I went through all the usual suspects such as checking pages within the site are checked-in and published and also checking the master page and page layouts have been checked-in and approved.  Everything was fine as expected.

Having exhausted the obvious options, I noticed that the querystring for the access denied page contained more information than I expected, it referenced a particular list…

http://localhost/_layouts/AccessDenied.aspx?Source=[AnyUrl]&Type=list&name=%7B12151589%2D7A0B%2D40EE%2DBD92%2DADB851B3D78E%7D

Having never noticed this before, I ran with my hunch that this might be relevant and quickly cobbled together a powershell script to list all lists within that site I was trying to access…

$web = Get-SPWeb -Identity "http://localhost/subsite"
 
foreach($list in $web.Lists)
{
	Write-Host $list.ID " " $list.Title
}
 
$web.Dispose()

Low and behold the mystery GUID was listed as the ID of a document library within the site I couldn’t access. On further investigation the document library had a custom set of permissions of which my user had only been granted “Read” access to.  Quite why this results in this user not being able to access the site I’m not sure – I expect there will be some reason but I’m yet to find it.  My resolution is to temporarily increase this users permissions until I can find the exact cause.

Automated SharePoint Site creation using PowerShell

In a project I’ve been working on recently there was a requirement to create a large number of SharePoint sites based on different custom site templates.  Obviously there was no way I was going to create them all manually so I pulled together a handy little PowerShell script that reads the site name, url and template to be used from an Excel spreadsheet and then creates the sites using the New-SPWeb command.  The Script is below:

function New-SPWebFromExcel {
 
    # Read in list of sites from Excel
    $DataTable = New-Object “System.Data.DataTable”
    $OleDbAdapter = New-Object System.Data.OleDb.OleDbDataAdapter “Select * from
[Sheet1$],"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=$($args);Extended Properties=”"Excel 12.0 Xml;HDR=YES”";”
    $RowsReturned = $OleDbAdapter.Fill($DataTable)
 
    ForEach ($DataRec in $DataTable) {
        $SiteTitle = [string]$($DataRec.SiteName)
        $SiteUrl = [string]$($DataRec.SiteUrl)
        $WebTemplate = [string]$($DataRec.SiteTemplate)
        $LangId = "1033"
        Write-Host "Creating an SPWeb at $($SiteUrl)"
        New-SPWeb -Url $SiteUrl `
        -Language $LangId `
        -Template $WebTemplate `
        -Name $SiteTitle
    }
}

The Excel file is very simple, 3 columns called SiteName, SiteUrl and SiteTemplate.  Add all the sites you want created, with the URL’s being fully qualified (i.e. http://localhost/sitename) and the appropriate site template name specified.  All you then have to do is call the function from your PowerShell script like so:

New-SPWebFromExcel "C:\temp\SiteList.xlsx"

Painless SharePoint Site creation!

Note: to get the name of the site template you want to use, you can get a handy list of all site templates and their names by running this PowerShell command:

Get-SPWebTemplate | Sort-Object "Name"

Enabling ASP.NET Session State in SharePoint 2010

To enable ASP.NET session state:

  1. Enter the following PowerShell command in the SharePoint 2010 Management Shell window:
    Enable-SPSessionStateService –DefaultProvision
  2. On each web application for which you want to use session state, edit the web.config file and set the enableSessionState property of the pages element as follows:
    <pages enableSessionState="true">