Failure trying to synch web application and A duplicate site ID was found

If you’re shunting SharePoint content databases around between environments using the stsadm deletecontentdb and addcontentdb commands, you may find a couple of new errors in your events logs:

Failure trying to synch web application {guid}, ContentDB {guid}  Exception message was A duplicate site ID {guid}(http://yoursite) 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.

followed by:

A runtime exception was detected. Details follow.
Message: A duplicate site ID {guid}(http://yoursite) 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.

After restoring a production content database to my dev environment, I was finding these two errors every hour on the dot.

Importantly—and despite what this error message notes as a possible cause—Todd Carter details why you shouldn’t be using stsadm preparetomove in a modern (post-IU) SharePoint environment. It seems like preparetomove actually fixed up some GUIDs before a detach/attach operation and it’s still documented with no warnings on Technet but hey, there’s something to be said for collective community wisdom when it comes to Sharepoint ;)

The problem itself seems to lie with SharePoint’s inability to update database IDs during the detach/attach process and (possibly) the fact the content database consumes an SSP. I’m a bit unclear on how the Infrastructure Update may have addressed this but at the end of the day I just want a clean event log and stable environment.

To correct this problem and clear both error messages, I ran the following stsadm command:

stsadm –o sync –DeleteOldDatabases 0

Despite it’s name, the DeleteOldDatabaes parameter doesn’t delete databases, only the “old records corresponding to these databases.” The zero value instructs the command to delete all records that have not been synchronized for the specified number of days. For a report of what might be cleaned up, run stsadm –o sync –ListOldDatabases 5 first.