Skip to main content
SharePoint

Return to Revisions

2 of 2
added 985 characters in body
BonesTune
BonesTune
  • 61
  • 3

Weird error when creating a site collection from a Claims authentication WCF service

I'm having trouble adding a new site collection, from a service hosted in a claims enabled SharePoint web application. The authentication works just fine (I can confirm the identity of the user while stepping through the site collection creation).

For some reason, I get the below error message. The only thing that seems to resolve it is to add the client user to the local administrator group. I've tried changing web app security policies, adding all kinds of users as database sysadmin and so forth, but that doesn't help at all.

Another thing I find weird is the fact that the error stems from SetSiteQuota. According to the ULS logs, the site collection appears to be created, then some subsequent operation fails. The stack trace supports this.

Any clues would be most welcome.

0#.w|domain\testuser caused exception trying to create a site with owner domain\client.   ExceptionType: 'ThreadAbortException'   ExceptionMessage: 'Thread was being aborted.'   StackTrace: '  
 at System.Threading.Thread.AbortInternal()      
 at System.Threading.Thread.Abort(Object stateInfo)      
 at System.Web.HttpResponse.End()      
 at Microsoft.SharePoint.Utilities.SPUtilityInternal.SendResponse(HttpContext context, Int32 code, String strBody)      
 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(HttpContext context)      
 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex)      
 at Microsoft.SharePoint.Library.SPRequest.SetSiteQuota(String bstrUrl, UInt16 quotaId, Int64 diskQuota, Int64 diskWarning, Int32 userQuota, Double resourceUsageMaximum, Double resourceUsageWarning, Boolean bForSSC)      
 at Microsoft.SharePoint.Administration.SPQuota.Update()      
 at Microsoft.SharePoint.SPSite.set_Quota(SPQuota value)      
 at Microsoft.SharePoint.Administration.SPSiteCollection.Add(SPContentDatabase database, SPSiteSubscription siteSubscription, String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String secondaryContactLogin, String secondaryContactName, String secondaryContactEmail, String quotaTemplate, String sscRootWebUrl, Boolean useHostHeaderAsSiteName)      
 at Microsoft.SharePoint.Administration.SPSiteCollection.Add(SPSiteSubscription siteSubscription, String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String secondaryContactLogin, String secondaryContactName, String secondaryContactEmail, Boolean useHostHeaderAsSiteName)      
 at Microsoft.SharePoint.Administration.SPSiteCollection.Add(String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail)

Update:

I found a somewhat related post on MSDN, at http://social.technet.microsoft.com/Forums/en-CA/sharepoint2010programming/thread/51ad553a-ec7b-46b6-873c-d49b2544c55f. At the end of this post, Microsoft confirms an issue with SPSiteCollection.Add().

While some aspects do apply to my case (Claims, SPSecurity.RunWithElevatedPrivileges), the custom auth handler doesn't. What makes it all utterly weird is that RunWithElev() should cause the site collection creation to be run by the SharePoint system account (which would have privileges to do whatever). Yet the problem goes away entirely if the account calling the Claims service is added to the server's administrators group.

My point: it looks as though part of SharePoint's internal site collection creation process runs as the current thread's identity, even when the creation is spawned from RunWithElevatedPrivileges. At the end of the day, this brings me no closer to a conclusion or solution, as it's completely out of the question to add users to the server's administrators group.

BonesTune
  • 61
  • 3