A runtime exception was detected. Details follow. Message: A duplicate site ID e988d221-a48b-4ae8- ad91-6c6ca40548c3(https://my site url) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue. Techinal Details: Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSit eIDException: A duplicate site ID e988d221-a48b-4ae8- ad91-6c6ca40548c3(https://my site url) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue. at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSite sForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy) at Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds() at Microsoft.Office.Server.UserProfiles.SynchCollection`2.Add(T objAdd) at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSit es(String strFirstChangeToken, SPChangeToken lastChangeToken) at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContent DB() at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter( Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

After extensive research of all the SharePoint databases I figured the table “sistesynch” in the sharedservices database is responsible for the errors caused by the hourly profile synchronizations service. I looked in the table and found out the database id‘s in this do not match with the database id’s from the config database of the SharePoint. Site ID’s seems to be ok in this table. This table may not have been updated when the content databases where detached and attached (could be a bug in SharePoint). After deleting the rows from this table the errors gone away and the table is re-populated back with correct sites and database id’s next time when the service ran (usually hourly). I also found that you can actually run this stsadm command which also does the same thing mentioned above (deleting rows from site sync table) and is probably a better way since this is a command from MS. Run the following command . stsadm -o sync -DeleteOldDatabases 0 The results of this command will be a list of old database id’s that have been cleaned up and the sitesync table will be emptied. Note: Since there is no documentation on any of these commands .All the above fixes are based on my personal investigation so please makes sure this works for you in your environments before you run. Backup the sharedservices and configuration databases just in case if this don’t work for you. It’s been couple of days since we ran this in our environment and we haven’t seen any issues and all the event log errors gone away. Good Luck. Vikram Garlapati