MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

MOSS Migration Issues

  Asked By: Ralph    Date: Jun 20    Category: MOSS    Views: 836

We are doing migration from SPS 2003 to MOSS 2007.
We have successfully migrated the WSS sites for size < 500 MB with gradual

We are facing issues like repairdatabase and repairorphan sites for the
sites > 2 GB..

Can anybody suggest a solution to the problem.

As of now we are depending on the hotfixes from microsoft.



13 Answers Found

Answer #1    Answered By: Kerri Steele     Answered On: Jun 20

Fix the orphans before running the upgrade perhaps?

I had no problem upgrading a 4 GB content database - the key thing is to
make sure that what you have before the upgrade is in pristine condition.

Answer #2    Answered By: Alisha Itagi     Answered On: Jun 20

How about a 20 GB content database that has a 130GB log file. Looks like we may
have to hand create MOSS Portal to look as much like the existing 2003
production portal and then manually copy documents and receate list items.

Answer #3    Answered By: Octavio Dotson     Answered On: Jun 20

Why not shrink down the log file? Typically we run our maintenance plans on
SQL server to discard them quickly after they've been committed. The only
reason I can see to keep them around to accumulate to 130 GB would be if
you're doing log shipping.

Answer #4    Answered By: Judy Pittman     Answered On: Jun 20

From my experience, database size hasn't been too much of an issue. I performed
a gradual upgrade of a 43GB content database and it worked fine. I iniitially
had issues  with orphaned objects, and after a call to PSS, the fix actually
turned out to run the SPS backup/restore utility. It seems that the API for
this application has some kind of brute-force mechanism in place to "deal with"
orphaned objects.

Answer #5    Answered By: Caleb Gordon     Answered On: Jun 20

Yup, there was a SharePoint update that came out last summer which adds the
ability to get rid of the orphans rather than performing a WSS split.

Answer #6    Answered By: Himanshu Gohil     Answered On: Jun 20

We are doing Gradual Migration.For some sites we migrated successfully.
but for some sites we are facing challenges..

We got the update from Microsoft for repairing database and repairing orphan
We repaired the database and then we got one orphan site and we deleted the
orphan sites

now we are getting the orphan sites count is 0.

Then we run prescan.exe.
We got the following error in the log file.
05/30/2007 12:05:59 Restoring quota and locks on SPSite
05/30/2007 12:05:59 Checking if
prescan.exe" is a WSS V2 SP2 database.
05/30/2007 12:05:59 Checking if any site has not yet been scanned in
05/30/2007 12:05:59 Error: The following site has not been scanned. Id =
97eb08dc-8acd-4fc8-9d54-6acfcc1a63db and Url = /sites/ps
05/30/2007 12:05:59 Checking if any list has not yet been scrubbed in
05/30/2007 12:05:59 Error: Prescan has encountered sites or lists that were
not updated because they cannot be accessed using the SharePoint Products
and Technologies object model. The most likely reasons for Prescan to skip a
list are covered in the Knowledge Base article at:

Answer #7    Answered By: Ashton Schroeder     Answered On: Jun 20

You can also set your database recovery mode to "Simple" and it will truncate
the transaction logs automatically once they're committed. Since we don't offer
point in time recoveries we do this for most of our DBs.

Answer #8    Answered By: Iris Ballard     Answered On: Jun 20

but how do you set the DB recovery mode to Simple?
I am asking because we have a log file that is up to 9.9 GB and all
attempts to shrink it are now working.

Answer #9    Answered By: Jamila Guthrie     Answered On: Jun 20

You can go into SQL Enterprise Manager, or SQL Management Studio if you're
running SQL 2005. From there, navigate to the properties of the database, and
there should be a tab labeled Options. You can switch the recovery model from
Full to Simple from there.

Answer #10    Answered By: Kalpana Ghatge     Answered On: Jun 20

Now working or Not working?

The setting will only truncate the transaction logs, it will not shrink them.
However, if your logs stay small because of the constant trucation, they
shouldn't grow to be too large.

Answer #11    Answered By: Bobbie Rodgers     Answered On: Jun 20

Yes, and by truncating them, they'll be in essence shrinking the amount of
disk space. You're right, transactions are transactions they're not going
to change in size, but the amount of disk space that they consume will

I'm a personal fan of just having a maintenance plan run every 15 minutes on
the active node of the SQL cluster to flush out the transaction logs that
are old.

Answer #12    Answered By: Vinay Thakur     Answered On: Jun 20

Truncating logs does not reduce disk space they consume. You must also
shrink the log file.

From http://support.microsoft.com/kb/873235, "The backup operation or
the Truncate method does not reduce the log file size. To reduce the
size of the transaction log file, you must shrink the transaction log
file. To shrink a transaction log file to the requested size and to
remove the unused pages, you must use the DBCC SHRINKFILE operation."

See also http://support.microsoft.com/kb/907511 for how to use DBCC

Answer #13    Answered By: Davon Henson     Answered On: Jun 20

I don't know if this will help, but you might try checking and deleting items
from your
Recycle bin. Sometimes when you create and delete a lot of items in SPS the
Recycle bin dosn't delete them for a month.

Didn't find what you were looking for? Find more on MOSS Migration Issues Or get search suggestion and latest updates.