It was time of my first onsite client assignment on SharePoint. Client had one server production environment. They wanted to upgrade the topology with completely new SharePoint Farm of three servers. So, the task was to move whole MOSS 2007 stuff to the new server environment without impacting data. The last three words “… without impacting data…” were actually putting pressure on my head. Moreover SSP was required to move because additional information has been added for users apart from AD import.
I thought I had to do only backup and restore. It appeared pretty easy at first thought. Just because of these three damn scary words, I thought to check out on internet for guidance related to this scenario. I couldn’t get anything except general guidance of moving server on Microsoft TechNet site. I promised myself for starting blogs with this post if I would be successful in this task. Well, I took long time to write this but finally made it. I hope it will be useful to all guys looking for SharePoint server movement.
Before beginning restoration, make sure that, there is no difference in versions of SharePoint at source and destination server. Also check whether the state of SharePoint Installation at the time of backup and restore is same or not. (E.g. SharePoint related service packs and patches if any)
The main tasks of the server movement are as follow:
1. Backup all the databases
2. Install and configure SharePoint on new environment
3. Deploy all solutions (WSP Files) globally to destination server- for installing features attached to the solutions
4. Install all the custom features
5. Deploy/Copy custom pages/files which are added to the “12Hive” folder later
6. Restore SSP
7. Restore My Site
8. Restore other web application
Tasks 3 to 5 are for making sure that we have configured the environment well enough for the web application to be restored successfully. The main and complex task was restoring SSP. I have started restoring SSP through Central Admin.
After a while, the restoration status was updated to “unsuccessful”. “Damn it, what went wrong?” I thought looking at the error detail down the page. I couldn’t remember the error message but I had corrected and restored it again.
Actually once you fail restoring SSP, until and unless you don’t clean all related stuff well, your restoration will be failed again and again. I wanted to find the actual reason. So cleaned, restored, cleaned, restored… I had tried almost 5-6 times and finally, I succeeded. I had realized how pleasant it is, to see the word “Successful” on the screen. Without wasting your much time to read, let me write all the detailed steps of restoring SSP:
1. Delete the SSP through following STSADM command.
stsadm -o deletessp -title <SSP name> -deletedatabases -force
e.g.: stsadm -o deletessp -title SharedServices1 -deletedatabases –force
2. Check and delete the web application associated with SSP if it exists.
3. Remove Link from Check and remove “Alternate Access Mapping” associated with SSP if it exists.
4. Check and delete IIS site as well as application pool associated with SSP if it exists.
5. Stop following services:
· Office SharePoint Server Search
· Windows SharePoint Services Search
· Windows SharePoint Services Help Search
6. Delete all the databases associated/related to SSP from SQL Server.
7. Reset IIS.
8. Start again following services:
· Office SharePoint Server Search
· Windows SharePoint Services Search
· Windows SharePoint Services Help Search
9. Restore the new SSP.
After the SSP restoration, all other stuffs had completed very smoothly without any more issues. I did few modifications to sites for change of server name and finally, the new environment was ready.
