Error Attaching Database After SharePoint 2010 Farm Restore

Recently I ran into an issue when attempting to restore a SharePoint 2010 Farm Backup of a single web application via Central Administration. The backup was from a different farm than what it was being restored to. The environment consisted of SharePoint 2010 Enterprise (SP1 + CU Feb 2012) and SQL 2008 R2 (SP1).

Upon completion of the restore, there was one error related to the content database restore for the web application that caused the restore to partially fail:

Object [NEW DATABASE NAME) (previous name: [OLD DATABASE NAME]) failed in event OnPostRestore. For more information, see the spbackup.log or sprestore.log file located in the backup directory.

Now, the database actually does get restored to the SQL content database server, but does not complete the database add to the web application. The first issue is that the database retains the old service accounts from the previous environment, and an ‘access denied’ occurs when the restore process tries to attach the database to the web application for the new environment.

The first step to resolving this was to go into the SQL Studio Manager on the SharePoint SQL box and grant the appropriate service accounts from the new environment DBO rights to the newly restored database.

After adding the service accounts DBO permissions to the new databases, my next attempt to add the content database to the web application (Central Administration >; Application Management >; Manage Content Databases >; Add a content database), produced the following error:

The attach operation cannot continue because another object in this farm already contains the same ID. Each object in a farm must have a unique ID. In order to proceed with the attach operation you must assign a new ID to this database. To attach this database with a new ID, use the Mount-SPContentDatabase command with the -AssignNewDatabaseId parameter. Note that if this new database and an existing database contain the same site collections, attaching this database will likely result in orphaned site collections due to conflicts between the two databases.

This basically points to an orphaned database issue. To resolve this, I needed to open up SharePoint 2010 Management Shell and use the following PowerShell:

$orphanedDB = Get-SPDatabase | where{$_.Name -eq “[NEW DATABASE NAME]“}

Next, I used PowerShell (not Central Administration) to mount the content database to the new web application and also assign it a new database ID:

Mount-SPContentDatabase -Name [NEW DATABASE NAME] -WebApplication [WEB APPLICATION URL] -AssignNewDatabaseID

After the above was completed, I needed to then use Central Administration to update the Site Collection Administrators (Central Administration >; Application Management >; Change site collection administrators ), as they still had the old environment accounts assigned.

Once this was all completed, my web application was back up and in working condition.

SharePoint 2010 ULS Logs Empty – 0 KB

Recently I built a test environment and was in need to investigate a few issues in the ULS Logs.  However, to my dismay, I found that there was no information in them.  They were being created, but all had a 0 KB size.  As one would first attempt, I restarted the SharePoint 2010 Tracing service, and found no resolve.

As I looked at the service in compared to another working SharePoint 2010 farm, I found the service was running as ‘Local System’ on the working farm, and in my test environment it was running as one of the SharePoint service accounts.

I changed the ‘Log on as’ to ‘Local System’ for the SharePoint 2010 Tracing service, then restarted the service, and all was back in order and ULS logs were capturing data.