If you are a SharePoint Admin that is still running stsadm –o PrepareToMove before detaching a content DB AND your farm is running at least the Infrastructure Update (IU) then stop! Stop running the command, its not necessary and it is causing you problems and you probably don't even realize it.

If prepareToMove is run within a SharePoint farm that has at least the IU that Content DB will no longer participlate in profile syncronization; even if you remove and reattach the content DB to the same farm. The issue is due to a change in behavior that we introduced in the Infrastructure Update (IU). Before the IU when a content DB was removed and reintroduced back into a SharePoint farm the DB ID would change/regenerate. This had the side effect of causing all content within those DBs to undergo a Full Crawl by search. As you can imagine this a huge overheard so in the IU we ensured that the Content DBs never had to change IDs when reintroduced into a Farm. The PrepareToRemove was originally needed to ensure we did not have to redo a full sync when the same content DB with a new ID was reintroduced. Since this ID now does not change this is no longer needed when running within a farm that has at least the IU installed.

PrepareToMove sets 'Moving' to True in the SiteSynch table of the SSP DB which signals to the profile sync job to ignore the DB which has the effect of not allowing profile syncs to occur for this DB. After attaching a Content DB back into the IU farm 'Moving' is still set to True. Even after the sync timer job fires and the stored procedure profilesynch_RegisterSiteToSynch is executed this content DB will still have its 'Moving' set to True.

The fix/resolution is to run PrepareToMove again (ok so I lied there is a case where you want to run it with the IU) but this time with the –undo option. The -undo command is harmless and it will set 'Moving' back to False and allow profile syncs to this content DB to start running again.

Be on the lookout for new TechNet and KB guidance around this command.