SharePoint Search Service Application Restore Is Failing

Question

Issue:
When performing a Search Service restore with the CA UI, the restore is failing. The backup was generated from a Full level backup that is run nightly from the cmdlet Backup-SPFarm.  The Farm is running SharePoint 2013 SP1, Windows Server 2012 And SQL
Server 11.0.3128. Both Production and the test environment have the same topology.
The sprestore.log file shows the following error message:
[12/17/2014 12:37:51 PM] Verbose: [Search Service Application] The default endpoint id for this application is 'b8b92dc6-38b3-49bf-90bc-d9ea64dcf928'.
[12/17/2014 12:37:51 PM] Verbose: [Search Service Application] Re-parented endpoint 'b8b92dc6-38b3-49bf-90bc-d9ea64dcf928' to this application.
[12/17/2014 12:37:51 PM] Verbose: [Search Service Application] The default endpoint has been found and set.  NOTE: The id of the default endpoint will be different than specified in the logs if
the restore mode is not 'overwrite'.
[12/17/2014 12:37:51 PM] Verbose: [Search Service Application] Re-parented endpoint 'bb456994-47ac-4bad-9197-9a4d5b39bf5c' to this application.
[12/17/2014 12:37:55 PM] FatalError: Object Search Service Application failed in event OnPostRestore. For more information, see the spbackup.log or sprestore.log file located in the backup directory.
        SqlException: The database principal owns a database role and cannot be dropped.
User does not have permission to perform this action.
[12/17/2014 12:37:55 PM] Debug:    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj,
Boolean& dataReady)
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean
asyncWrite, SqlDataReader ds)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout,
Task& task, Boolean asyncWrite)
   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command)
   at Microsoft.Office.Server.Data.SqlDatabaseManager.GrantAccess(String user)
   at Microsoft.Office.Server.Search.Administration.SearchDatabase.GrantAccess(String username, String role)
   at Microsoft.Office.Server.Search.Administration.SearchDatabase.SynchronizeAccessRules(SearchServiceApplication searchApp)
   at Microsoft.Office.Server.Search.Administration.SearchServiceApplication.SynchronizeDatabases()
   at Microsoft.Office.Server.Search.Administration.SearchServiceApplication.Provision()
   at Microsoft.SharePoint.Administration.SPIisWebServiceApplication.Microsoft.SharePoint.Administration.Backup.IBackupRestore.OnPostRestore(Object sender, SPRestoreInformation info)
A SQL Profile was run beginning at 12/18/2014 11:11.
A SQL exception can be found at 11:20:03 with the error:
               The database principal owns a database role and cannot be dropped.
The issue has to do with the SQL statement just prior to the exception:
declare @p4 int
set @p4=NULL
declare @p5 int
set @p5=NULL
exec sp_executesql N'declare @db_user_name sysname
select @db_user_name = name from dbo.sysusers where sid = SUSER_SID(@user_name) and hasdbaccess = 1
if (@db_user_name is null)
begin
if exists(select * from dbo.sysusers where name = @user_name)
exec @revoke_result = sp_revokedbaccess @user_name
exec @grant_result = sp_grantdbaccess @user_name, @db_user_name output
end',N'@user_name nvarchar(128),@revoke_result int output,@grant_result int output',@user_name=N'----\sp2013uatfarmacct',@revoke_result=@p4 output,@grant_result=@p5 output
select @p4, @p5
I highlighted the row in red causing the issue. For some reason SharePoint during the Search Restore process try’s to delete the user “------\sp2013uatfarmacct” from the database Search_Service_Application_DB_60bb9889222841aa94f59aed71349a6b
And re-add them again.  But the reason for the failure is because the user “------\sp2013uatfarmacct” is the owner of the database role “SPSearchDBAdmin”, so it cant.
I checked all other Service databases that contain the role SPSearchDBAdmin and they all correctly have the owner as dbo
NOT ------\sp2013uatfarmacct.
Further checking the SQL trace log a SQL batch is executed at 12/18/2014 11:19:59.790 that states the following:
-- Drop existing role members
IF  EXISTS (SELECT * FROM sys.database_principals WHERE name = N'SPSearchDBAdmin' AND type = 'R')
Begin
    DECLARE @RoleMemberName sysname
    DECLARE Member_Cursor CURSOR FOR
    SELECT [name]
    FROM sys.database_principals
    WHERE
        principal_id IN
            SELECT member_principal_id
            from sys.database_role_members
            where role_principal_id in (
            select principal_id
            FROM sys.database_principals where [name] = N'SPSearchDBAdmin'  AND type = 'R' ))
    OPEN Member_Cursor;
    FETCH NEXT FROM Member_Cursor
    into @RoleMemberName
    WHILE @@FETCH_STATUS = 0
    BEGIN
        exec sp_droprolemember @rolename=N'SPSearchDBAdmin', @membername= @RoleMemberName
        FETCH NEXT FROM Member_Cursor
        into @RoleMemberName
    END;
    CLOSE Member_Cursor;
    DEALLOCATE Member_Cursor;
End
-- Drop/Create role
IF  EXISTS (SELECT * FROM sys.database_principals WHERE name = N'SPSearchDBAdmin' AND type = 'R')
DROP ROLE [SPSearchDBAdmin]
CREATE ROLE [SPSearchDBAdmin]
I highlighted the statement in red that is eventually causing the SP restore to fail. For some unknown reason to me when this statement is executed the new ROLE SPSearchDBAdmin owner is -----\sp2013uatfarmacct
instead of dbo.
As a test I executed via SQL Management Studio “CREATE ROLE [SPSearchDBAdmin]” and it correctly created the owner as dbo.
So the problem and my question is why when the SP Search Service is restored is the ROLE SPSearchDBAdmin owner being set to “-----\ sp2013uatfarmacct”, which in turn seems to be causing the restore failure?

Answer 1

Hi!
I believe it is trying to delete a user who owns the schema of the database. You can try changing the schema owner to some other user like "dbo", and then drop the first user.
Below are a few links that can help you with much more details.
http://blogs.technet.com/b/mdegre/archive/2010/12/19/the-database-principal-owns-a-schema-in-the-database-and-cannot-be-dropped.aspx
http://littletalk.wordpress.com/2009/11/09/fix-for-the-database-principal-owns-a-schema-in-the-database-and-cannot-be-dropped-error-in-sql-server-2005/
http://dotnetgun.blogspot.com/2011/02/database-principal-owns-schema-in.html
Thanks,
Owens
Owens G. Jesse