Share via

PrepareToMove Away From Running This Command

  • Article

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.

Comments

  • Anonymous
    January 30, 2009
    We seem to have some profiles that are not getting synched with all our site collections (we have policy one content db per site collection).  Could this be do to the 'Moving' flag getting set some other way?

  • Anonymous
    February 02, 2009
    This is one of the most poorly documented commands in SharePoint, and this blog post confuses me even more. Here is a scenario where I've needed to use PrepareToMove. Can you tell me if I would still need to use this command in this scenario?: A web application and content db in a production farm needs to be copied and restored to two different web applications on a development farm. This is so that two development projects can happen independently, based on a snapshot of the latest content from production. Procedure: Create SQL backup of the content db. Restore to dev SQL server environment twice (so dev has two dbs with different names) Create two web applications in dev Add a restored content database to each web application. Problem: If you did not run preparetomove at some point in this scenario, only one of the restored web applications would be able to see the site collections in the content database. Running preparetomove on one of the restored dbs would regenerate IDs and enable this scenario to work properly. How do the changes in the IU affect this scenario?

  • Anonymous
    February 04, 2009
    Must read if you have run or are use to running the STSADM preparetomove command when detaching/attaching

  • Anonymous
    February 20, 2009
    In case anyone was wondering, the database where the SiteSynch table is located is the SSP Service database.   Adamtoth - I have done what you have said consistently several times without running PrepareToMove.   Create the new web apps in your DEV environment first making new databases for them.   Detach these 2 new content databases you created by making your new web apps from your SharePoint farm. Have your DBA (or you can do it yourself if you know how) restore the content from the 1 old content databases to the 2 new content databases.   When the restore is complete, reattach the 2 new databases you just refreshed to your farm using the AddContentDB command in STSADM.  Make sure to add -assignnewdatabaseID and -clearchangelog parameters to the AddContentDB command.   Check the SiteSynch table in your SSP Service database as indicated above and if the 'Moving' column is TRUE, run the PrepareToMove STSADM command using the -contentDB command with the name of your new content DB and the -undo parameter.  Do this -undo command 2 times, once for each new contentDB.   This worked for me when I had to refresh 2 separate databases in my DEV farm from 1 production content database.  

  • Anonymous
    February 25, 2009
    Hi, Following your advice I did a backup/restore in a (december cumulative moss instalation) without the preparetomove and although the profiles sync correctly and the moving flag is set to false I get those dreaded 5553/7888 profile import errors...any ideas on how to get rid of those?

  • Anonymous
    June 03, 2009
    MOSS SP2 Upgrade Process: As defined and cleansed by http://technet.microsoft.com/en-us/library/cc263467.aspx#section1