SharePoint 2010–App Pool Account User Rights

This is a quick one: Had a new web application in a new farm – so it was the first time the app pool identity was put to use. The app pool would not start with SQL-sounding errors like ‘Unknown SQL Exception 1346 occurred...Either a required impersonation level was not provided, or the provided impersonation level is invalid’.

So after verifying all of the usual suspects, it was determined that adding the user to the local administrators group resolved the issue. Of course that is not a good solution, so I wanted to find out what the smallest set of user rights should be for that account. In the end (and working well so far), the user is a plain-Jane domain user with these rights:

• Log on as a batch job
• Generate security audits
• Impersonate a client after authentication

Cannot activate Document Sets feature in SharePoint 2010

A coworker attempted to activate the Document Sets feature within a SharePoint 2010 site collection. This action resulted in a blank page with the feature still inactive. Hmm… Permissions? But she is a site collection admin!

Having both site collection admin permissions and beyond, I tried it myself and got the same results. Diving into the log files (anyone else find that more informative in SP2010, or is that just me?) I found these lines:

• Feature Activation: Activating Feature 'DocumentSet'
• Calling 'FeatureActivated' method of SPFeatureReceiver for Feature 'DocumentSet'
• DocumentSet FeatureActivating: start
• DocumentSetTemplate ProvisionLists for 0x999990 on https://site : throws exception: Only a site collection administrator can add a work item.. Stacktrace:    at Microsoft.SharePoint.SPSite.AddWorkItem(Guid gWorkItemId, DateTime schdDateTime, Guid gWorkItemType, Guid gWebId, Guid gParentId, Int32 nItemId, Boolean fSetWebId, Guid gItemGuid, Guid gBatchId, Int32 nUserId, Byte[] rgbBinaryPayload, String strTextPayload, Guid gProcessingId, Boolean useExponentialRetryBackOff)     at Microsoft.SharePoint.SPSite.AddWorkItem(Guid gWorkItemId, DateTime schdDateTime, Guid gWorkItemType, Guid gWebId, Guid gParentId, Int32 nItemId, Boolean fSetWebId, Guid gItemGuid, Guid gBatchId, Int32 nUserId, Byte[] rgbBinaryPayload, String strTextPayload, Guid gProcessingId)     at Microsoft.O...   

Score one for the error handling – an error that was actually caught. But there was nothing really interesting about the information above, aside from the fact that it thought I was not a site collection admin – which I verified. Never know – someone else might have booted me from the group!

It was the next line of the log file, which continued the call stack output, that I found the answer:

• ...ffice.DocumentManagement.DocumentSets.DocumentSetTemplate.<ProvisionLists>b__0()     at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2()     at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)     at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)     at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)     at Microsoft.Office.DocumentManagement.DocumentSets.DocumentSetTemplate.ProvisionLists().

So the code that was failing was running in the context of the app pool user… interesting.

Resolution

Ensured the app pool identity account was a site collection admin. Document Sets feature then activated without a problem.

So my remaining questions are:

1. Is it necessary to have the app pool identity be a site collection admin? Is that a best practice? Had this been a production system, I probably would have elevated to site collection admin, activated the feature, then removed the account from the site collection admin group.
2. Why the heck is RunElevated needed in the activation code of a Site Collection feature?? Isn’t that a security risk – or at least a good extra validation that the current user has permissions to do what they are attempting to do?

SharePoint 2010 Quick Tip: Expose the Enterprise Wiki Template

Was looking to create a shiny new SP 2010 wiki site as a subsite. I could see the Enterprise Wiki template when creating a new site collection, but not when attempting to create a child site of an existing site collection. In MOSS 2007, I do not recall a situation where the “Wiki Site” template was not available, so I was surprised when I found that I was missing the option to create a new SP 2010 wiki site – aka Enterprise Wiki.

The answer is pretty easy – though may not be 100% obvious: Activate the SharePoint Server Publishing Infrastructure feature on the site collection:

Once that is active, when you attempt to create a new site in a site collection where the publishing infrastructure is activated, the Enterprise Wiki template will be an option.

I went back to check: Activating the publishing Infrastructure feature in MOSS 2007 is not a requirement for the Wiki Site template. With all the new bling that comes with the 2010 wiki, it is reasonable that it would have more dependencies on other SharePoint components.

SharePoint Saturday Virginia Beach

Had a few requests for the materials from my session at SharePoint SaturdayVB: jQuery – The 16th Piece of Flair for SharePoint.

There was actually way more interest than expected – thanks to you all for the compliments. My apologies to those of you who were expecting a less technical session – somehow I got billed as a designer session. There were some benefit to designers, but when it comes down to talking about jQuery, HttpModules, and functional programming in JavaScript, I know we left some of you designers in the dust. Sorry!

I had a great time attending and presenting at the event. Always more fun than I expect it to be. Also had the chance to catch up with some old comrades, as well as meet some new people. If you end up using this stuff and/or improving it, drop me a line! You never know, I you may catch me with some motivation(aka ‘time’)  to work with you on it.

Anyways, here is the good stuff:

The presentation slides:

The code: