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.