locked
How to deal with sharepoint event 7888 and 5555 errors RRS feed

  • Question

  • We have been working on upgrading a dev vm server from moss sharepoint 2007 service pack 1 to 3.

    To start, we cloned the vm and had the SQL Server team back up the dev sql server tables.

    During the  SP3 process, some errors occurred. So we asked the VM team to return the VM to its original form and asked the SQL Server team to restore the database.

    The next time through the process, the SP3 process said it was successful.

    However, now we are getting errors such as this:

    Event Type: Error
    Event Source: Office SharePoint Server
    Event Category: Office Server General
    Event ID: 7888
    Date:  6/7/2012
    Time:  11:00:01 AM
    User:  N/A
    Computer: NTSRV45D
    Description:
    A runtime exception was detected. Details follow.
    Message: A duplicate site ID b84e9d3b-05c2-4eaa-932d-da32867c44c1(http://casportdev) 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.

    Techinal Details:
    Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSiteIDException: A duplicate site ID b84e9d3b-05c2-4eaa-932d-da32867c44c1(http://casportdev) 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.
       at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSitesForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy)
       at Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds()
       at Microsoft.Office.Server.UserProfiles.SynchCollection`2.Add(T objAdd)
       at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSites(String strFirstChangeToken, SPChangeToken lastChangeToken)
       at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContentDB()
       at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Event Type: Error
    Event Source: Office SharePoint Server
    Event Category: User Profiles
    Event ID: 5555
    Date:  6/7/2012
    Time:  11:00:01 AM
    User:  N/A
    Computer: NTSRV45D
    Description:
    Failure trying to synch web application 0c29eb27-a96b-40d9-8423-7b88ff4b72b3, ContentDB bb682a7f-b0bb-46b6-9bc9-6ad4f1f7e28b  Exception message was A duplicate site ID b84e9d3b-05c2-4eaa-932d-da32867c44c1(http://casportdev) 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.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    We didn't restore a content database from one server to another - we restored the content database from its own backup.

    We need to move forward.  In googling these errors, we see references to stsadm -o preparetomove . We didn't use that - we had taken down the machine when the clone vm and the database backup occurred and when things were restored.

    What specific actions can be taken now on this site to stop these errors?

    Thank you


    • Edited by lvirden Thursday, June 7, 2012 7:10 PM fixed typo
    Thursday, June 7, 2012 7:10 PM

All replies

  • Is the original content database that you backed up still attached to the farm you're trying to restore its backup into? With SharePoint 2007, you can't have two instances of a single content database attached to the same farm, because both databases use the same GUIDs to identify the site collections contained within them. If you want to attach the restored database to that SharePoint 2007 farm without getting those errors, you're going to first have to detach the original content database (you can do this without deleting it from SQL Server if you're worried about that). NOTE: in SharePoint 2010 there is the new "Unattached Content Database Restore" functionality that allows you to get around this issue, but its not available for SharePoint 2007.

    Now, if you don't have the original content database attached to the farm, then we're probably looking at a different issue, perhaps the farm is holding on to info about orphaned site collections or something. If so, update this thread and we'll dive into it deeper.

    John


    MCITP and MCTS: SharePoint, Virtualization, Project Server 2007
    My books on Amazon: The SharePoint 2010 Disaster Recovery Guide and The SharePoint 2007 Disaster Recovery Guide.
    My blog: My Central Admin.

    Friday, June 8, 2012 12:41 AM
  • Is the original content database that you backed up still attached to the farm you're trying to restore its backup into?

    ====

    I really have a problem understanding this question. The database guy made a backup of the database originally, restored it after we hit the errors during upgrade, I fixed the orphan site collections by detaching the content database and reattaching it, then ran the service pack 3 again.

    The restore was done back to the same instance it came from.

    Does that help?

    With SharePoint 2007, you can't have two instances of a single content database attached to the same farm, because both databases use the same GUIDs to identify the site collections contained within them.

    =====

    We never had more than one content database attached to the server. 

    =======

    Now, if you don't have the original content database attached to the farm, then we're probably looking at a different issue, perhaps the farm is holding on to info about orphaned site collections or something. If so, update this thread and we'll dive into it deeper.

    =====

    We don't have the original database attached - we have the database upgraded by sp3. 


    Friday, June 8, 2012 2:10 AM