Recently, our team was tasked with moving all the SharePoint databases of a SharePoint 2007 farm from one database server to another.
Microsoft recommends using SQL aliases while installing SharePoint. This makes such database moves much easier. Unfortunately, this guideline was not followed when the farm was first created, probably because such guidance was missing in the early days of SharePoint 2007 when the farm was originally created. The key to performing such a move is to create an alias for the new SQL instance and give this alias the same name as the current instance of SQL Server that the SharePoint databases are hosted on. Of course this would mean that the alias can only be configured after the original SQL instance is stopped to avoid any conflicts.
Microsoft provides a fairly comprehensive and accurate guideline around moving all SharePoint 2007 databases via this TechNet article: http://technet.microsoft.com/en-us/library/cc512725(office.12).aspx. Here are a few notes of my own in addition to the TechNet article:
- The article enlists various SharePoint services to be stopped before the databases are detached and the move is carried out. The article is correct in that it does not mention the “Windows SharePoint Services Web Application” as one of the services to be stopped on the front end servers. I wanted to put out an additional note of caution that the service should NEVER EVER be stopped or restarted. Doing so has the potential to delete any customizations that were deployed, including but not limited to web.config entries, assemblies deployed to GAC and so on. This can be disastrous particularly if you don’t have any backups that you can restore these customizations from.
- The article also mentions steps to back up and restore Shared Service Providers for the farm. One issue we faced here was that the SSPs were not getting restored. Further investigation revealed that this was due the Search service not getting correctly restarted. The solution was to rectify the search settings and perform the steps to restore the SSPs again. In addition when you restore the SSPs again, you will need to delete any corrupted SSPs that got restored previously and also delete the content databases for such SSPs that got restored as part of the previous restoration attempts.
That’s pretty much it. Good luck with your move!
Gaurav Mahajan 
Hello Sir,
1.How many ways we can deploy the custom web parts. Is it possible to deploy web parts without install in GAC is there any other way to deploy?
2. Ten users entering data in Info-Path forms and submit the data, now i want to generate the reports for those 10 users.
How can we do this?
Hello Arun,
Thanks for stopping by. Your questions are not related to the blog post above but I’ll still try and help.
#1. You do not necessarily need to deploy the assemblies to GAC. You can deploy them to the bin folder of your web application as well. Here’s a good link that explains how to deploy the web parts and also compares the two approaches: http://technet.microsoft.com/en-us/library/cc288040(v=office.14).aspx
#2. Reporting will depend on how you store the data from these forms. I am assuming these are browser based forms. If so, you can promote the fields so they are available in the document library. You can then report out of the data available in the document library. There are other ways that you can get to the data but I’ll need to know the specifics.
Hope the above helps
Thanks
Gaurav