My Sites and The SPDataAccess SQL Role
You’ve been busy spinning up your RTM SharePoint 2013 farms haven’t you? And of course, you’ve been deploying under the least-privileged security model like any good IT Pro. After you have everything configured, you open the event viewer and what to your wondering eyes should appear? An error of course!
The error and why
So, why is my content Application Pool attempting to access My Sites? Well, if we read Account permissions and security settings in SharePoint 2013 (go ahead, I’ll still be here when you finish) under the SharePoint service application accounts section (specifically My Sites application pool account) there’s a little follow-section titled Other application pool accounts. Let’s take a look at the permissions our “Other” pool accounts should be granted automatically:
| Configuration Item | Works as advertised |
|---|---|
| This account is assigned to the SP_DATA_ACCESS role for the content databases. | No* |
| This account is assigned to the SP_DATA_ACCESS role for search database that is associated with the web application | No** |
| This account must have read and write access to the associated service application database. | Yes |
| This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role that is associated with the farm configuration database. | Yes |
| This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role that is associated with the SharePoint_Admin content database. | Yes |
* The account is not automatically added to the My Sites content database(s). If it was, we wouldn’t be here.
** The search databases don’t have the SPDataAccess role.
Fixing the error
To alleviate the error (and make your servers happy again!), we’ll be heading off to SQL and executing a quick query on each content databases associated with your My Sites web application:
