I was applying some CUs to SharePoint 2013 and running the configuration wizard was failing. You may or may not know this, but the configuration wizard will write a log file to the SharePoint hive as well as an error log. This error log is the one you want to look at.
In my case, I was receiving
The database principal owns a schema in the database, and cannot be dropped. User, group, or role ‘SPDataAccess’ already exists in the current database.
When looking at the error log, it was apparent this had something to do with the SPDataAccess principal within the SP15_UsageAndHealth database.
01/09/2015 15:39:43.99 OWSTIMER (0x359C) 0x2838 SharePoint Foundation Upgrade SPUpgradeSession ajxnm INFO SPUsageDatabase Name=SP15_UsageAndHealth 012dde9c-16ee-b0ba-8634-adb34afb8eb1
01/09/2015 15:39:43.99 OWSTIMER (0x359C) 0x2838 SharePoint Foundation Upgrade SPUpgradeSession ajxnm ERROR Upgrade [SPUsageDatabase Name=SP15_UsageAndHealth] failed. 012dde9c-16ee-b0ba-8634-adb34afb8eb1
01/09/2015 15:39:44.01 OWSTIMER (0x359C) 0x2838 SharePoint Foundation Upgrade SPUpgradeSession ajxnm INFO SPUsageDatabase Name=SP15_UsageAndHealth 012dde9c-16ee-b0ba-8634-adb34afb8eb1
01/09/2015 15:39:44.01 OWSTIMER (0x359C) 0x2838 SharePoint Foundation Upgrade SPUpgradeSession ajxnm ERROR Exception: The database principal owns a schema in the database, and cannot be dropped. User, group, or role ‘SPDataAccess’ already exists in the current database. 012dde9c-16ee-b0ba-8634-adb34afb8eb1
SharePointgotchas (https://sharepointgotchas.wordpress.com/2014/04/17/postsetupconfigurationtaskexception-was-thrown-when-installing-sp1/) gave me the hint I needed and Pinal Dave (http://blog.sqlauthority.com/2011/12/26/sql-server-fix-error-15138-the-database-principal-owns-a-schema-in-the-database-and-cannot-be-dropped/) had some more details about this issue.
If you look at SQL Server Management Studio and navigate to the offending database, you can navigate to the Schemas node and investigate who owns each of the schemas by looking at each Schama’s properties.
In my case, the schema owner was set to SPDataAccess. I’m not sure how it got this way, but upon further inspection, this was also true for SP15Farm and SP15MyAppPool.
For each of them, I set the schema owner to be the same as the schema name.
Now, running the configuration wizard was successful! All is well in SharePoint land again.
Are you a user? 
0 Responses to ““The database principal owns a schema in the database, and cannot be dropped” Error Running the SharePoint Configuration Wizard”