Migrating a fragile SharePoint 2010 farm to new hardware.
When I first became Administrator of the "C" SharePoint 2010 portal (real name classified) I noticed how delicate it was, and how riddled with errors the logfiles were. "You've had some cowboys in here", I thought.
Search was not working. The search service that was trying to run was calling a database that was missing from SQL server. A previous admin deleted that database from SQL; SharePoint had no idea and was still looking for it.
The owner of most of the content databases was the previous admin's elevated account. Services were running under that account as well. It was only a matter of time before that account expired and got removed causing the farm to crash.
The SharePoint Service accounts were unmanaged and I only had the password to one of them.
There was 2.2TB of data in SQL server contained within over 60 site collections and 60 content databases. Each Site collection got its own content database.
The SharePoint servers had never had updates applied to them beyond windows patches that get pushed down. The SQL Server was over 50 updates behind.
Most importantly, the server farm was on 4 year old hardware that needed to be decommissioned, and the OS was Windows Server 2008 when the regulations stated it needed to be 2008 R2.
As much as possible, we cleaned up the content, removing outdated site collections and archiving old data.
So the plan was made to create a new "C" portal with all new VMWare servers. I wanted to leave as much of the fragile setup behind so I created a brand new portal from scratch. I installed SQL Server 2008 R2 and added an alias. I added two load balanced web front ends and 3 servers to handle Central Admin, Search, and Application services (Excel Services, etc). So after this, I had a complete and fully functional farm with no content. We would be changing the URL for the portal permanently.
Using SharePoint PowerShell, I scripted a SharePoint backup of each site collection. (Scripts will be a separate post) I ran this several times with the nositelock option to time the completion. I saved the backup file to a UNC path on the destination sql server. Then I scripted the creation of the new site collection as well as the restore job. I tested everything and noted the times. My calculated estimate was 1.2 minutes per GB and restore was 2.5 mins per GB. I broke up the job into 5 batches that would fit into ASIs on 5 consecutive nights. As we were able to promise no down time, only a window where a handful of sites would be read only, there was minimal resistance to this change. The regulation to go to windows 2008 helped too.
The top navigation was in an external file, so before I began, I added a full URL to each link. Then as each restore completed, I would update the top nav bar with the new URL. I would also add a period to the end of the display text to give a visual cue that the site had been moved.
After the move was complete, I took the old URL and redirected it to the front page of the new portal. This way, any old shortcuts are not dead, but they also don't take you to your deep-linked location
The issues we ran into using this method were
Search was not working. The search service that was trying to run was calling a database that was missing from SQL server. A previous admin deleted that database from SQL; SharePoint had no idea and was still looking for it.
The owner of most of the content databases was the previous admin's elevated account. Services were running under that account as well. It was only a matter of time before that account expired and got removed causing the farm to crash.
The SharePoint Service accounts were unmanaged and I only had the password to one of them.
There was 2.2TB of data in SQL server contained within over 60 site collections and 60 content databases. Each Site collection got its own content database.
The SharePoint servers had never had updates applied to them beyond windows patches that get pushed down. The SQL Server was over 50 updates behind.
Most importantly, the server farm was on 4 year old hardware that needed to be decommissioned, and the OS was Windows Server 2008 when the regulations stated it needed to be 2008 R2.
As much as possible, we cleaned up the content, removing outdated site collections and archiving old data.
So the plan was made to create a new "C" portal with all new VMWare servers. I wanted to leave as much of the fragile setup behind so I created a brand new portal from scratch. I installed SQL Server 2008 R2 and added an alias. I added two load balanced web front ends and 3 servers to handle Central Admin, Search, and Application services (Excel Services, etc). So after this, I had a complete and fully functional farm with no content. We would be changing the URL for the portal permanently.
Using SharePoint PowerShell, I scripted a SharePoint backup of each site collection. (Scripts will be a separate post) I ran this several times with the nositelock option to time the completion. I saved the backup file to a UNC path on the destination sql server. Then I scripted the creation of the new site collection as well as the restore job. I tested everything and noted the times. My calculated estimate was 1.2 minutes per GB and restore was 2.5 mins per GB. I broke up the job into 5 batches that would fit into ASIs on 5 consecutive nights. As we were able to promise no down time, only a window where a handful of sites would be read only, there was minimal resistance to this change. The regulation to go to windows 2008 helped too.
The top navigation was in an external file, so before I began, I added a full URL to each link. Then as each restore completed, I would update the top nav bar with the new URL. I would also add a period to the end of the display text to give a visual cue that the site had been moved.
After the move was complete, I took the old URL and redirected it to the front page of the new portal. This way, any old shortcuts are not dead, but they also don't take you to your deep-linked location
The issues we ran into using this method were
- Outlook linked calendars (opening a SharePoint Calendar from Outlook) needed to be deleted and re-linked
- SharePoint Calendar overlays did not work
- Datasources in InfoPath needed to be recreated
- Saved shortcuts no longer worked or in the interim pointed to read only content
Comments
Post a Comment