Having recently upgraded and migrated one of our farms from the old datacenter running 2007 to the new datacenter running 2010 there were some slight issues with the User Profiles and getting them moved to the new location.  Within SP2010 there are generally only two ways to get user profile data onto the new farm from an existing farm in SharePoint 2010. The first is to consume the User Profile Service of the host farm, but this causes issues if you want to host a My Site host (that contain personal sites) on the consuming farm. The second way is to use the Replication Engine. The Replication Engine uses audiences and trusted My Site Hosts to determine which farm “owns” the particular set of user profile data. The Replication Engine can also be used to keep data in synch with SharePoint 2007 data, which in our case was a good thing since we had to leave some sites behind on the 2007 farm until such time that we can update the custom coded web parts to be 2010 compliant.

Steps:

  1. Backup your Profile database.
  2. Download the SharePoint 2010 Administration Toolkit http://www.microsoft.com/downloads/en/details.aspx?FamilyID=718447d8-0814-427a-81c3-c9c3d84c456e&displaylang=en and install it on at least one server. If you want to push data in more than one direction you will need to install it on another server in the other farm as well.  I generally like to use the server we’ve set up for central admin or an application server and stay off the WFEs.
  3. Backup your Profile database.
  4. Create your audiences and Trusted My Site Host entries on all the servers involved.  If they’re not set up correctly you get lots of fun error messages which are typically MSCryptic.
  5. Backup your Profile database.
  6. Read the User Profile Replication Engine Overview at http://technet.microsoft.com/en-us/library/cc663011.aspx. The 2010 version is a PowerShell window with a few commands. Basically you can start and stop incremental replication, do full replications, and get a list of profile properties, because PowerShell is awesome that way.
  7. Backup your Profile database.
  8. Before you start replicating…turn off the smtp service, full replications will send out colleague notifications, which is not fun to try to explain to everyone why they got a bunch of notification for stuff they already had.
  9. Just for good measure, Backup your Profile database

A couple of points to remeber when trying to run a profile replication in SharePoint 2010.

  • The account running the replication needs the ‘Full Control’ permission on the User Profile Service Application on the destination SharePoint farm.
  • Although the documentation states that the URLs to use for the source and destination should be those of the my site host on each farm, I could not get it working using these URLs at all. Instead, the URLs for the Central Admin site (!) on each farm worked a treat. These values are running the Start-SPProfileServiceFullReplication or Start-SPProfileServiceIncrementalReplication cmdlets.
  • Again, the documentation implies that you should pass in the Properties to the replication cmdlet, either explicitly or via the pipeline (well, all the examples I could find did). I found this to be troublesome, and it is an optional parameter so try the most simple call to the replication cmdlet – if the User Profile Service on the source farm is customised, this seemed to cause issues if trying to replicate fields that don’t exist on the destination.