Saturday, July 23, 2011

7 tips and tricks about the User Profile Replication Engine

Migrate user profiles from a different farm to your farm (MOSS 2007 to SPS 2010 IS supported)

Synchronize user profiles from a master a farm to a different farm (geographical replication or disaster recovery farm replication)

I have been playing with this tool a bit lately and here are a few things I noticed that might interest you. First of I would advise you to start with the official documentation at: http://technet.microsoft.com/en-us/library/cc663011.aspx . You will most likely only use the full and incremental commands.

1 -Full replication DOES NOT use any windows service

The Full synchronization ( Start-SPProfileServiceFullReplication )does not uses the Windows Service (aptly named “Replication Engine”) used by the incremental command (Start-SPProfileServiceIncrementalReplication). This is important as it means that the full sync is done with the account you launched the command line with WHEREAS the incremental sync is done with the “Replication Engine” service account. Knowing which account is running is important to know which account needs the permissions on the User Profile Service Applications.

2 - Local Admin permissions IS NOT needed for incremental sync

Running the incremental sync (i.e. the windows service) is possible with a non-local administrator account, but it needs:

Full permissions on the local folder where the replication engine is installed (C:\Program Files\Microsoft\SharePoint 2010 Administration Toolkit\Replication Engine)

Full permissions on the registry hive

HKLM:\Software\Microsoft\Replication Engine

HKLM:\SYSTEM\CurrentControlSet\services\eventlog

HKLM:\Software\Microsoft\EnterpriseCertificates

This is not based on any official documentation; I had to use Process Explorer to actually see what was preventing the Replication Engine from starting when running with a non-local admin account. The last two permissions might be optional but I added these anyway to be on the safe side. So far I haven’t seen any downside to this workaround.

3 - Full replication IS NOT needed before starting incremental sync

At least it is not always needed. If the User Profiles are already in sync because you did a fresh install and imported the profiles on source and destination with no other changes, you might skip the full sync and start with the incremental sync.

But if there is any difference between your two User Profiles SAs, start with the full as these differences will not be propagated.

In fact the incremental sync only propagates information that has been changed while it is running.

4 - Account changing option (credential parameter) behaves badly

The credential parameter of the Start-SPProfileServiceIncrementalReplication should be used to specify the windows service credential on the first run according to the documentation, well I don’t because it works erratically giving inconsistent results. Instead I set the windows service account itself. You can even do it in scripts.

5 - Social sync IS supported BUT

Social sync doesn’t included managed metadata (because it isn’t part of the User Profiles Service Application obviously) event though tagging is based on managed metadata. In fact tagging is stored in the User Profile DB as reference to the managed metadata entry.

Thus if you need to replicate tags you MUST replicate the managed metadata SA data as well.

6 - MySite URL CAN be replaced with the central administration Url

The documentation tells you to use the MySite Host Url for Source and destination but you can use the central administration URL as well.

In DRP (Disaster Recovery Plan) configuration it might be cumbersome to do so as URLs are shared on the source and destination farm. But the central administration URL being based on machine names is different on both farms.

Beware: this might depend on whether or not you User Profile SA is in the default Service Application Proxy group.

7 - Incremental sync is as fast as light

Yup it is seriously fast, so fast I thought my test protocol was broken when I started to test the replication :)

12 comments:

I am pretty pessimistic about this possibility as one need to use a "DoUpgrade" switch when doing the replication from 2010 to 2007.

Maybe with a limited set of properties to replicate. I don't have the environment available to try it out, If you have you could test the replication with a limited set of property especially removing every properties that have changed between the two versions ("Ask me about").

hi, log shipping your managed metadata service to a standby farm can do. Yet be careful as you won t be able to have this log shipped db used by your mms as it will be read only. It s adequate for a stand by farm though : http://technet.microsoft.com/en-us/library/ff628971.aspx

I have the replication service up and running but I ran into a problem when disabling a user account in the active directory. The next time an incremental profile synch is run, the disable user´s profile will be in the "Missing from import" group in the service application. This setting is NOT replicated to my other service application. Do you have any experience on this?

Hi RG, sadly I don't know the answer to that. In the worst case scenario you might need to write some scripts to achieve that but I have no experience with this scenario.

Hi Maurice, you are correct, always starts with a full. Also note that it is recommended to run User Profile to\from AD replication in all farms. Otherwise profile deletion will not happen in remote farms.