I’ve been doing a lot of work with the new SharePoint 2013 App Model in the last few months. Specifically, I’ve been working on a free tool (for Idera) that will be going into the SharePoint App Marketplace sometime soon. The tool itself is not too terribly complicated – just a SharePoint-hosted app that will allow users to analyze library properties, compare library configuration settings, etc.
The development environment that I was using to put the new application together had been humming along just fine … until today. It seems that I tempted fate today by applying a handful of RTM patches to my environment.
What Happened?
I’d heard that some patches for SharePoint 2013 RTM had been released, so I pulled them down and applied them to my development environment. Those patches were:
After all binaries had been installed and a reboot was performed, I ran the SharePoint 2013 Products Configuration Wizard. The wizard ran and completed without issue, Central Administration popped-up afterwards, and life seemed to be going pretty well.
I went back to working on my SharePoint-hosted app, and that’s when things went south. When I tried to deploy the application to my development site collection from Visual Studio 2012, it failed with the following error message:
Error occurred in deployment step ‘Install app for SharePoint’: We’re sorry, we weren’t able to complete the operation, please try again in a few minutes. If you see this message repeatedly, contact your administrator.
Okay, I thought, that’s odd. Let’s give it a second.
Three failed redeploys later, I rebooted the VM to see if that might fix things. No luck.
Troubleshooting
My development wasn’t moving forward until I figured out what was going on, so I did a quick hunt online to see if anyone had encountered this problem. The few entries I found indicated that I should verify my App settings in Central Administration, so I tried that. Strangely, I couldn’t even get those settings to come up – just error pages.
All of this was puzzling. Remember: my farm was doing just fine with the entire app infrastructure just a day earlier, and all of a sudden things were dead in the water. Something had to have happened as a result of the patches that were applied.
Not finding any help on the Internet, I fired-up ULSViewer to see what was happening as I attempted to access the farm App settings from Central Administration. These were the errors I was seeing:
Insufficient SQL database permissions for user ‘Name: SPDC\svcSpServices SID: S-1-5-21-1522874658-601840234-4276112424-1115 ImpersonationLevel: None’ in database ‘SP2013_AppManagement’ on SQL Server instance ‘SpSqlAlias’. Additional error information from SQL Server is included below. The EXECUTE permission was denied on the object ‘proc_GetDataRange’, database ‘SP2013_AppManagement’, schema ‘dbo’.
Seeing that my service account (SPDC\svcSpServices) didn’t have the access it needed to run the proc_GetDataRange stored procedure left me scratching my head. I didn’t know what sort of permissions the service account actually required or how they were specifically granted. So, I hopped over to my SQL Server to see if anything struck me as odd or out-of-place.
Looking at the SP2013_AppManagement database, I saw that members in the SPDataAccess role had rights to execute the proc_GetDataRange stored procedure. SPDC\svcSPServices didn’t appear to be a direct member of that group (that I could tell), so I added it. Bazinga! Adding the account to the role permitted me to once again review the App settings in Central Administration.
Unfortunately, I still couldn’t deploy my Apps from Visual Studio. Going back to the ULS logs, I found the following:
Insufficient SQL database permissions for user ‘Name: NT AUTHORITY\IUSR SID: S-1-5-17 ImpersonationLevel: Impersonation’ in database ‘SP2013_AppManagement’ on SQL Server instance ‘SpSqlAlias’. Additional error information from SQL Server is included below. The EXECUTE permission was denied on the object ‘proc_AM_PutAppPrincipal’, database ‘SP2013_AppManagement’, schema ‘dbo’.
It was obvious to me that more than just a single account was out of whack since the proc_AM_PutAppPrincipal stored procedure was now in-play. Rather than try to manually correct all possible permission issues, I decided to try and get SharePoint to do the heavy lifting for me.
Resolution
Knowing that the problem was tied to the Application Management Service, I figured that one (possible) easy way to resolve the problem was to simply have SharePoint reprovision the Application Management Service service application. To do this, I carried out the following:
- Deleted my App Management Service Application instance (which I happened to call “Application Management Service”) in Central Administration. I checked the box for Delete data associated with the Service Applications when it appeared to ensure that I got a new app management database.
- Once the service application was deleted, I created a new App Management Service service application. I named it the same thing I had called it before (“Application Management Service”) and re-used the same database name I had been using (“SP2013_AppManagement”). I re-used the shared services application pool I had been using previously, too.
After completing these steps, I was able to successfully deploy my application to the development site collection through Visual Studio. I no longer saw the stored procedure access errors appearing in the ULS logs.
What Happened?
I don’t know what happened exactly, but what I observed seems to suggest that one of the patches I applied messed with the App Management service application database. Specifically, rights and permissions that one or more accounts possessed were somehow revoked by removing those accounts from the SPDataAccess role. Additional role and/or permission changes could have been made, as well – I just don’t know.
Once everything was running again, I went back into my SQL Server and had a look at the (new) SP2013_AppManagement database. Examining the role membership for SPDC\svcSpServices (which was one of the accounts that was blocked from accessing stored procedures earlier), I saw that the account had been put (back) into the SPDataAccess role. This seemed to confirm my observation that somehow things became “unwired” during the patching and/or configuration wizard run process.
References and Resources
- MSDN: Apps for SharePoint overview
- Company: Idera
- Microsoft: SharePoint App Marketplace
- MSDN: How to: Create a basic SharePoint-hosted app
- SharePoint 2013 Update: KB2737983
- SharePoint 2013 Update: KB2752001
- SharePoint 2013 Update: KB2752058
- SharePoint 2013 Update: KB2760355
- MSDN: ULSViewer
There seem to be a number of issues with 2013 and that pesky SPDataAccess role. I’ve run in to role access problems with least-privileged deployments as well (http://psconfig.com/post/35039264266/my-sites-and-the-spdataaccess-sql-role).
I just read your post, Scott – interesting stuff. I’m doubly baffled why my SPDataAccess role assignments are going wonky *now*, though. This farm was configured to least privileges, so if role membership were an issue, I thought I would have already seen it.
I’m also scared that I may have other issues that just haven’t surfaced yet. If you see me complaining about something else being broken, remind me to check this ;-)
Hello,
Just for information
I had the same problem :
Error occurred in deployment step ‘Install app for SharePoint’: We’re sorry, we weren’t able to complete the operation, please try again in a few minutes. If you see this message repeatedly, contact your administrator.
I solved this with adding the developper account as db_owner to the Application Service DataBase.
Flav,
I’m glad to hear that you found a solution that worked for you. Personally, I’m not comfortable doing manual permission grants to SQL Databases to work around this sort of gap in SharePoint. My thinking is that although it may solve the *current* problem, I don’t know that it’s addressing the underlying root cause that caused the problem. I tend to worry that I might be creating additional maintenance nightmares somewhere down the road.
Nevertheless, thanks for sharing the feedback and your solution!
Just ran into the same issue, except it was for the Central Admin Site’s content database and the farm services service account (and it was causing problems for several service applications). This does not give me a warm fuzzy…
Thanks for the feedback, John. I wonder if we might see a fix for this somewhere down the road; seems like a number of people have run into it …
One more “same here”…tried the fix of recreating the service app with the same DB name, but that didn’t work. I ended up adding the developer account to the SP_DataAccess role instead of DBO to that database. But I agree with Sean, this is a band-aid to get my dev able to deploy, but not the fix if we have the same problem in production!
Thanks for sharing your experience, Steve. Recreating the service app didn’t do it for you? Yikes. This whole SP_DataAccess role item is frustrating. I do hope we see this fixed sooner rather than later.
Steve, what service application did it happen to for you?
Sean, on a related note, Enrique wondered if the March CU might resolve this issue, something I haven’t had a chance to even remotely try to prove out yet… No idea if it does or not, but it’s worth mentioning…
Thanks for mentioning that, John. I’d actually already taken the March 2013 PU and slipstreamed it into my AutoSPInstaller build folder; hopefully it’ll do the trick – won’t know until my next build-out. Microsoft stated that the March PU will be a baseline requirement for future CUs and updates, I believe, so I imagine we’ll all be doing the same thing :-)