PrepareToMove Away From Running This Command

re: PrepareToMove Away From Running This Command

Rob Roach — Sat, 31 Jan 2009 05:17:54 GMT

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?

re: PrepareToMove Away From Running This Command

adamtoth — Mon, 02 Feb 2009 21:27:54 GMT

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?

STSADM PrepareToMove command and the Infrastructure Update

Dave Wollerman's SharePoint Blog — Wed, 04 Feb 2009 18:58:27 GMT

Must read if you have run or are use to running the STSADM preparetomove command when detaching/attaching

re: PrepareToMove Away From Running This Command

J.H. — Fri, 20 Feb 2009 19:20:38 GMT

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.

re: PrepareToMove Away From Running This Command

Raul Queiroga — Wed, 25 Feb 2009 18:55:11 GMT

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?

MOSS SP2 Upgrade Process - Step By Step

Thu, 04 Jun 2009 00:52:26 GMT

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