The idea to write this entry came as a result of many failed Profile sync operations I've seen lately, so, here it is:
As a scenario, let's assume that you have a webapplication you want to move on a different port. I stress the word move, because otherwise you could simply extend the webapplication on the desired additional port and you could be in business.So let's assume you want to get rid of the old web app and create a brand new clean one.
A very important step that is almost everytime forgoten is running the preparetomove operation (stsadm-o preparetomove that is).
What effect can this have on your server, you ask?
Well the simplest behavior you will almost for sure encounter is receiveing these errors hourly :
Event Type: ErrorEvent Source: Office SharePoint ServerEvent Category: User Profiles Event ID: 5555...
Failure trying to synch web application <WebApp Guid here>, ContentDB <Content Db GUID here> Exception message was A duplicate site ID <Site ID here>(<site URL here>) 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.
Another behavior would be that you can have the usernames displayed funny, let's say by SID or Account Name (DOMAIN\Name), or the details not being updated as it should.
The error(s) are generated by the stale entries in the SSP db, in relation with the profile sync operation which runs hourly.
How to get out of this? Dont get into it in the first place :-) !
Before performing ANY detach database operation from a webapplication consuming services from an SSP run the stsadm -o preparetomove operation http://technet.microsoft.com/en-us/library/cc263196.aspx
Second, if you are however there, follow the steps described in Cory's blog to get rid of the old associations in the sync job in the SSP: http://blogs.technet.com/corybu/archive/2007/06/01/detaching-databases-in-moss-2007-environments.aspx
in a nutshell :
in a command prompt:
for each of the guids above do:
wait for the next sync job to to complete or..
to force a syncronization job to occur within the next 5 minutes run in a cmd window:
stsadm -o sync -SyncTiming M:5
At the end, set the syncronization schedule back to 1 H
stsadm -o sync -SyncTiming H:1
Happy detaching/attaching :-)
Thanks for the tip.
Would performing attach/detach of content databases in Central Administration has the same effect of "preparetomove"?
Hi Dan, you are correct, performing a detach through the Central Administration UI will perform the preparetomove too.
However, there are databases that cannot (due to size for instance) attached through UI. This can also happen while moving the databases between servers, etc.