A few years ago, I installed a SharePoint 2003 Server as a proof of concept for a client. This SharePoint farm was later upgraded to Microsoft Office SharePoint Server (MOSS) 2007. The good news is that the client is really starting to use the portal both as an intranet site and an extranet site to help manage projects. The bad news is the company was running low on disk space and processing power as the portal grew. The SharePoint farm consisted of two virtual servers running a 32-bit frontend, 32 bit server, and a 32-bit SQL Server 2005 server using Virtual Server 2005 as the virtualization platform. Because the portal is growing very quickly, I wanted to get the company on the x64-bit platform.
The plan was to move the portal to a VMware ESX Host Server and use x64 virtual server guests for both the front end MOSS 2007 server and x64 SQL Server 2005. Because I wanted to move the portal to the x64 platform, any of the Physical to Virtual (PtoV) migration tools would not work. Here’s a summary of the steps for moving the portal to the new server hardware:
1. Install ESX on the new server.
2. Create x64 Windows Server 2003 R2 virtual guest servers for the MOSS 2007 frontend and SQL Server 2005 servers.
3. If the server will accept inbound mail, install SMTP on the MOSS front end server.
4. Install SQL Server 2005 with SP2 on the back-end database server.
5. Install MOSS 2007 on the SharePoint front-end server.
6. Install x64 PDF iFilter on the front-end server.
7. Don't create a shared services provider on the new server; otherwise the existing shared services provider will not properly migrate.
8. Install WSS 3.0 SP1.
9. Install Office Server SP1.
10. Install the WSS post SP1 hotfixwhich is referenced in " Description of the Windows SharePoint Services 3.0 post-Service Pack 1 hotfix package: January 31, 2008" at http://support.microsoft.com/kb/941422.
11. Make sure that Service Pack 1 and the Hotfix for Service Pack 1 are installed on both the old and new servers. Without these patches the restored site will not properly restore all of the timer jobs. For more information refer to http://support.microsoft.com/kb/942989. Unfortunately, I was not aware of this bug until after the migration was complete. I discuss a workaround below, if you didn’t apply the Hotfix for SP1.
12. Follow the directions at http://technet.microsoft.com/en-us/library/cc262370.aspx and http://technet.microsoft.com/en-us/library/cc261956.aspx for moving the site using Stsadm. Stsadm is the preferred way to migrate the site because it retains the permissions on the portal; if you use Central SharePoint Administration, all the permissions will be set back to default.
13. Use Stsadm to create a backup of the old server.
14. Delete the Default Web Site on the new server by using IISAdmin. If there is a Web site on the target server that uses the same port as one of the restored sites, the restore job will fail.
15. Restore the backup from the old server to the new server. Make sure to select New Configuration and enter the appropriate information in the new configuration screen.
16. Check the restore logs for any errors.
17. Export the Secure Sockets Layer (SSL) certificate from the old server and import it into the new server.
18. In Sharepoint Central Administration, Operations Tab, Alternate Access Mappings, verify the Web sites have the proper alternate access names. At the very least you will probably have to add an https://<portal_name> for the restored Sharepoint site.
19. If you have a commercial SSL certificate, export the certificate from the old server and import the certificate into the new server using IIS Admin.
20. Update the email server(s) to allow relaying from the new server if you plan to send outbound mail from the portal.
21. If you have a DNS entry on your internal server, make sure to update the A record with the new address of the server.
22. If the portal will be accessed from the Internet, make sure to update the Network Address Translation (NAT) policy on the firewall to redirect portal traffic to the new server.
23. Verify you can access the new server on HTTP and HTTPS.
24. Test the site to see if anything’s missing.
25. Add the new server into the backup rotation and remove the old server form any backup jobs.
I had the client test the portal after the migration was complete and everything looked OK. However, a few days later, IT noticed that users were not receiving their SharePoint notifications when users updated the portal. After some research, I discovered this was due to the bug in SharePoint that is addressed in a Hotfix for SP1. One suggestion is to apply the hotfix, back up the portal, and restore it again. Unfortunately for me, this was not an option because the portal content was significantly updated since the original migration. Fortunately I found a workaround at http://www.sharepointblogs.com/llowevad/archive/2008/02/18/workaround-for-creating-timer-jobs-after-a-restore-in-sharepoint.aspx. It involves the following steps:
1. Create a new Web site.
2. Prepare to move the databases on the current site.
3. Swap the databases with the new Web site.
4. Swap the URL addresses.
5. Clean up the old references in the system.
Dave Wollerman’s directions are great and it took me about an hour to get the timer jobs working again. This is a job that is best left for the weekend. Initially the client wanted me to move the portal overnight, but I’m glad I convinced them to wait until the weekend to move the portal to the new server hardware. Happy Migrating!
End of Article
Register
