The path to our SharePoint 2010 migration–part one

Last few weeks we started our SharePoint 2007 to 2010 migration. The following article describes the path we followed to migrate our intranet.

The current situation

  • A standalone SharePoint 2007 application (webserver and SQL server on the same machine)
  • A content database of 30GB
  • more then 500 my sites in a different content database.

Future situation

We wanted to migrate to SharePoint 2010 where the webserver and the SQL server were on a different machine. First we configured the following machines:

  • a SQL 2008 SP1 server (win2k8 R2) with plenty of free disk space
  • a win2k8 R2 machine, configured as webserver


On the first machine we installed SQL server, on the second we installed SharePoint 2010 (farm installation) and pointed the databases to the first sql server.

We also installed the service pack of SharePoint 2010 (English and Dutch) and the English and Dutch language packs.

We encountered the following error:

Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: "Access denied" or "No network provider accepted the given network path"

To solve this you can adjust the registry like described here.

Next we installed the June 2011 update (multilingual update) and the PDF iFilter.


Now we ran the famous preupdatecheck (STSADM.EXE -o preupgradecheck) against our SP2007 database. The result was that we had to copy some custom assemblies (like custom workflow actions and custom web parts)


Before we started the migration we made the database of our SP2007 system read-only and we made a backup of all our databases. We restore the database to the new SQL server (this database will be the future content database)

The we created a new webapplication (use a dummy database name as you can remove this one later, this is yes another blank database). Use the CAS to remove the dummy content database (also delete it from SQL server).

Now we can add our current content database to the webapplication. Before you attach the content databases to the Web applications, use the Test-SPContentDatabaseWindows PowerShell cmdlet to verify that you have all the custom components that you need for that database.

Once this check is ok you can add the content database to the webapplication:

Mount-SPContentDatabase -Name <DatabaseName> -DatabaseServer <ServerName> -WebApplication <URL> [-Updateuserexperience]

Once the migration of the content database is ready you can migrate the SSP and the mysites:

  1. Backup your existing MySites content database(s) on your MOSS 2007 farm SQL Server
  2. Back up existing SSP database on MOSS 2007 farm SQL Server
  3. Move both database .BAK files to the new SQL Server
  4. Restore the SSP database from .BAK as database named Profile_DB on your new SQL Server
  5. Restore the MySites database from .BAK as database named WSS_Content_MySites on your new SQL Server
  6. Run Test-SPContentDatabase for the mysites database against the web application:
    PS C:\Users\a_s****> Test-SPContentDatabase -Name STARTHOWESTBE_mysites -WebApplication https://start.*****.be –serverinstance sqlservername| ConvertTo-CSV | Out-file c:\temp\testMYSITES.csv
  7. Attach and upgrade the restored 2007 MySites database (i.e. WSS_Content_MySites) using the SharePoint 2010 Management Shell
    1. Mount-SPContentDatabase –Name WSS_Content_MySites –WebApplication https://start.*******.be
    2. activate search on the content databases
    3. Turn off the following services in your SharePoint 2010 Central Administration site 
    1. User Profile Service
    2. User Profile Synchronization Service
  8. Delete existing User Profile Service Application(s) if they already exist [Central Administration -> Application Management -> Manage Service Applications]
    1. Make sure to check the box for delete associated data/content
  9. Reset IIS
  10. Create a new User Profile Service Application in Central Administration [Central Administration –> Manage Service Applications –> New]
    1. Name = User Profile Service Application
    2. Create New App Pool
    3. Use the restored 2007 SSP database as the “Profile Database Name”
    4. Accept all other default database names
    5. Enter the newly created MySites web application url (e.g. http://mysites) as the default My Sites location for the new User Profile Service Application
  11. Go to “Administrators” in the ribbon menu for the User Profile Service Application and verify that DOMAIN\farm_account has “Full Control” rights
  12. Start the User Profile Service in Central Administration [Central Administration –> Application Management –> Manage Services on Server]
  13. Start the User Profile Synchronization service in Central Administration [Central Administration –> Application Management –> Manage Services on Server]
  14. Reset IIS
  15. In services.msc on your Central Administration host server (i.e. “App Server”), verify the two ForeFront Identity Management Windows services
    1. Services are started
    2. set to startup “Automatic”
    3. Running as DOMAIN\farm_account
  16. Setup Profile Import [Central Administration -> Manage Service Applications -> User Profile Service Application – click on title]
  17. Click on the link to “Add New Synchronization Connection” [see examples below]
  18. Run a Full Import
  19. Setup Profile Sync schedules [Central Administration –> Monitoring –> Timer Jobs]
  20. Test the My Sites site with a domain user account…success!

In a next article I’ll describe the things we had to fix after the migration.