Sunday, March 17, 2013

SharePoint Content Migration
 
 
I was assigned a task to relocate an old SharePoint site from an old server to our new SharePoint server. My first thought is to use "stsadm.exe -o export/import" to export the old site and import to the new site. However after seeing the old web site has 2GB of data, it seems it is too risky to introduce the data into the new site and since we are going retire the old site in the future any way, I decide it is better to use "back/restore" to restore it as a new web application running on different port on the new server.
 
Since I had done several back/restore for production environment, the task seems trivial. However there are always some surprises.
 
Of course I was trying it out first in a test environment. I was using the SharePoint Central Admin UI to do the backup. Everything went fine there. When I was trying to retore it in a test machine, I got errors as next
 
[11/16/2009 1:12:06 PM]: Error: Object WSS_Content_CoreNet123 (previous name: WSS_Content_CoreNet) failed in event OnRestore. For more information, see the error log located in the backup directory.
SqlException: The operating system returned the error '3(The system cannot find the path specified.)' while attempting 'CreateFile' on 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\FTData\ix_MBI_IntranetDB\SQL.HDR'.
RESTORE DATABASE is terminating abnormally.
 
It looks familiar. I thought maybe I missed some permission for the service accounts that are running SQL or SharePoint. I checked and they are fine. All service account are granted Admin permission to the server. I tried to create the path manaually and starts to get a little bit different error:
 
[11/16/2009 1:37:31 PM]: Error: Object WSS_Content_CoreNet failed in event OnRestore. For more information, see the error log located in the backup directory.
SqlException: The operating system returned the error '5(Access is denied.)' while attempting 'CreateFile' on 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\FTData\ix_MBI_IntranetDB\SQL.HDR'.
RESTORE DATABASE is terminating abnormally.
 
Googled about "SQL.HDR", it seems it is about the "Full-text indexing" of SQL 2005 which the old SharePoint site runs on.
 
After several tried, I decide to go another route to manaully back/restore the content database and attach the content DB to a new SharePoint web application.
 
It seems this is a wise decision, when I was restoring the database inside SQL server, I got simliar messages from SQL restore
 
 
ADDITIONAL INFORMATION:
System.Data.SqlClient.SqlError: The operating system returned the error '3(The system cannot find the path specified.)' while attempting 'CreateFile' on 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\FTData\WSS_Content_CoreNet_2.ix_MBI_IntranetDB\SQL.HDR'. (Microsoft.SqlServer.Smo)
ADDITIONAL INFORMATION:
System.Data.SqlClient.SqlError: The operating system returned the error '5(Access is denied.)' while attempting 'CreateFile' on 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\FTData\WSS_Content_CoreNet_2.ix_MBI_IntranetDB\SQL.HDR'. (Microsoft.SqlServer.Smo)
It seems the problem is that SQL restore doesn't work with directory "'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\FTData".
I found the SQL restore has an opiton page to set the "Full Text" restore path, I tried to set it to something "c:\temp", the restore starts to work.
 
Eventually I set it to C:\Program Files\Microsoft SQL Server\MSSQL10.MOSS\MSSQL\DATA\WSS_Content_CoreNet.ix_MBI_IntranetDB
 
The restore starts to work. After the successful retoring of the DB, I attached the content to a newly created SharePoint web application.
 
Lesson learned: The SharePoint backup/restore may not flexible enough in some scenarios to let you to troubleshoot and fix the restoring issues. Going to the lower level of database backup/restore and attaching the DB to the SharePoint Web Application is another route you can go to move/migration/restore your SharePoint site.

No comments:

Post a Comment