Those running SharePoint 2007 already know the major enhancements that this Software can bring to the corporate culture. With SharePoint 2010 the products strengths are developed further. Here, you can find a short summary of the improvements and new features of SharePoint 2010. Due to the vast positive changes SharePoint 2010 brings, most companies want to migrate to the new software as quickly as possible. Basically, Microsoft supports two migration paths: In-place upgrade and database-attach upgrade.
Latest posts by Alexander Weiss (see all)
- Set up a SharePoint 2010 development environment - Mon, Sep 3 2012
- MBAM 2.0 - BitLocker Administration and Monitoring changes in Windows 8 - Thu, Jul 26 2012
- BitLocker in Windows 8 - Thu, Jul 19 2012
System Requirements and Preparations ^
Both Versions of SharePoint, SharePoint Foundation (the previous WSS) and SharePoint Server (the previous MOSS), require Windows Server 2008 SP2 or Windows Server 2008 R2. Besides that, you need Microsoft SQL Server for versions 2005 SP3, 2008 SP1, or 2008 R2. All of them have to be 64-bit installations—32-bit is not supported by SharePoint 2010.
Besides these prerequisites, your current SharePoint installation must have a version number not less than 18.104.22.16821. This number equals MOSS 2007 SP2. You can find the version number in the Central Administration, Operations tab, under the link “Servers in Farm.” With SP2, Microsoft added a new function to the stsadm command. It is called pre-upgrade-checker, and it reviews your SharePoint installation for possible compatibility issues with SharePoint 2010. It will not make any changes to your current SharePoint installation, so it is safe to run in a productive environment. Be aware that it is quite resource intensive, so I would recommend running it during the off times. To run it, just execute the following command:
Stsadm -o preupgradecheck
It will display a short summary of the results in the shell:
However, more helpful is the comprehensive HTML report generated when the command finishes. You will need some time to read and fully understand it. If some “potential upgrade blocking issues” are listed, you should solve them before you start upgrading to SharePoint 2010. Thankfully, most issues are linked to online resources, which help in finding the problem’s solution. If everything looks fine in the report, you are still not ready to upgrade…but almost. You have to review your customizations. For example, have you changed any files in the SharePoint Hive under %PROGRAMFILES%\Common Files\Microsoft Shared\web server extensions\12? Have you deployed any custom- or third-party solutions? If you have kept a detailed change log, it will be a great advantage now. If not, make one now. You will need it once the upgrade process has finished.
If everything is done, you have to consider which kind of migration you want to do. Microsoft provides two different approaches: In-place upgrade and database-attach upgrade.
In-place upgrade ^
An in-place upgrade is surely the more comfortable method, because it is fully automated and you upgrade all of your servers at the same time. This requires that the server fulfill the installation prerequisites. If you select the option “install software prerequisites” in the installation tool, this is checked automatically and all the missing software parts will be copied to the hard disk. Once the migration process has started, there is no way to interrupt it, or do a rollback. This sounds risky, but Microsoft did well with the implementation of the in-place upgrade and the upgrade will run without interruptions most of the time. Performing a full farm backup is obligatory, though. Before you initialize the upgrade process, you should stop the World Wide Web Publishing service to prevent http traffic. You can do this in the IIS Manager by right clicking on the server and selecting “stop” from the context menu. To start the upgrade process, you must run the SharePoint 2010 installation routine. Once started, the installer will recognize that an older version of SharePoint is running on the server. It will you guide you through the whole migration process. This has to be done on all servers of the SharePoint farm.
When the installation routine is finished, you have to go to the “SharePoint 2010 Product Configuration Wizard” and run it. It will take some time to run, but after it is complete and if no errors occurred, the migration process will have finished successfully. All content has been converted to SharePoint 2010, and you can start exploring the new possibilities that SharePoint 2010 offers you. But before the fun part of the migration can start, you should check out the error log file. It can be found in %PROGRAMFILES%\Common Files\Microsoft Shared\ web server extensions\14\LOGS. If any errors are listed in the log file, you should fix them before considering adding new features to your web applications.
Database-attach upgrade ^
This is the safer approach because it does not interfere with your running system. However, it is more complicated and more work intense because you have to reapply all farm settings and customizations manually. If you are running a 32-bit Server or Windows 2003 Server environment, it is your only option, though. First, you have to create a new SharePoint 2010 server farm and mirror the web applications settings of your running farm on the new servers. To avoid DNS problems, you have to add the web application’s host names to the server’s local hosts file. It can be found under %WINDIR%\system32\drivers\etc.
Now it is time to reproduce the customizations of your old SharePoint installation’s file system. SharePoint’s 2010 hive is located under %PROGRAMFILES%\Common Files\Microsoft Shared\ web server extensions\14. You have to mirror exactly all the changes you have done to the old SharePoint installation, because missing customizations can have serious side effects. If important files are missing, a whole web application could fail to run.
Once the customizations are finished, you have to attach the old content databases. For that purpose, I recommend deleting the default content databases that were initialized when you created the new web applications. To add a content database to your fresh installation you have to use stsadm:
stsadm -o addcontentdb -url <url>-databasename <databsename> -databaseserver <mssqlserver>
When the command is executed, the old database will be upgraded to a SharePoint 2010 compatible version. Depending on the size of the database, this process can consume quite some time. If the performance of your SQL servers allows it, you can run a few of these upgrades parallel. Stsadm creates detailed log files in the LOGS folder in your SharePoint hive. One of them (called Update-*-error.log) will only show the warnings and errors. You will definitely want to check this log file to figure out if everything ran smoothly.
The Shared Service Provider no longer exists in SharePoint 2010, so if you import the SSP database it will only add the user profiles to the new database and all other settings will be lost. You will have to create them from scratch.
Finalizing the migration ^
Once everything is done and you want to check out the new SharePoint 2010 interface, you might be disappointed because it looks exactly like your SharePoint 2007 websites. Before you start to worry that something has gone tremendously wrong in the migration process, I can assure you that this is intended. It makes the migration process more transparent. Because if you were to see a messy website with the new SharePoint 2010 UI, you would have to figure out if something on the backend migration failed or if the new UI is incompatible with your customizations. When you see the old UI and if everything looks fine, you can be sure that the migration process has been correct up to now. If the SharePoint 2010 UI gets messy after you switch to it, you know for certain that the only cause can be incompatible visual customizations. But how do you switch to the new UI?
There is nothing easier than that. You just have to go to the Site Actions menu and choose Visual Upgrade. You have three options: display the previous UI, preview the new UI, and use the new UI. Before using the new UI, you should use the preview option to test whether everything looks right. If you are content with the results, you will notice that the changes to the UI are quite significant. However, not only has the UI changed, but also many management tools have been tweaked.
Although I will end the post now, your work is not done yet. You have to get used to the new functions and the new UI. Besides that, you have to prepare training sessions for the users to help them understand the new interface and features. I am sure, though, that they will be very happy with the new opportunities that SharePoint 2010 offers.