none
MOSS Patching Issues (Possible Orphaned Site) RRS feed

  • Question

  • Hi, we are currently patching MOSS' August commulative hotfix and it is unlikely that we are being haunted by a possible orphaned site issue

    We have already performed stsadm databaserepair prior and found no orphaned objects but when we installed the hotfix and ran the wizard we encountered.

    Pre-Upgrade [SPSite Url=https://*********.com/sites/linktel] failed
    The system cannot find the path specified. (Exception from HRESULT: 0x80070003)


    This site has already been deleted a year before, but is still persistent on the Central Admin (can't be deleted there as well). To add, when we use stsadm enumsites, there is an entry that reads the same, which we are thinking to be the same site causing problems.

    The system cannot find the path specified. (Exception from HRESULT: 0x80070003)

    The catch here is we have already pacthed the same server twice (SP1 and IU) and did not encounter this concern before.

    Can anyone provide some recommendation since our management would not call a MS Premiere support on this being a dev environment.

    ** If it is not too much, are there any links, site where the most common MOSS Patching Issues are listed and documented

    Thanks So Much
    Wednesday, January 14, 2009 1:39 PM

Answers

  • Another thing you can do is detach the contentdb from SP and then reattach it. To do that you'd run this command:

    STSADM -o deletecontentdb -url https://******.com -databasename whateverdb

    Then to add it back you'd do:

    STSADM -o addcontentdb url https://******.com -databasename whateverdb

    Just to be clear -- this is NOT deleting anything from SQL.  All this is doing is removing the association between MOSS and the db in SQL.  Sometimes doing stuff like this will take care of strangeness like you are reporting. Also, you'd have to detach the contentdb for the entire web application (unless you have set it up so that each site collection is using a unique contentdb).  Just note that doing this will cause downtime so if you are in the middle of your day, you might want to hold off until afterhours.

    John
    SharePoint911: SharePoint Consulting
    http://www.rossonmoss.com
    • Marked as answer by MejeeR Thursday, January 15, 2009 9:15 AM
    Wednesday, January 14, 2009 3:44 PM

All replies

  • If it comes up with a STSADM -o enumsites, what happens if you try to STSADM -o deletesite ???
    John
    SharePoint911: SharePoint Consulting
    http://www.rossonmoss.com
    Wednesday, January 14, 2009 3:33 PM
  • Another thing you can do is detach the contentdb from SP and then reattach it. To do that you'd run this command:

    STSADM -o deletecontentdb -url https://******.com -databasename whateverdb

    Then to add it back you'd do:

    STSADM -o addcontentdb url https://******.com -databasename whateverdb

    Just to be clear -- this is NOT deleting anything from SQL.  All this is doing is removing the association between MOSS and the db in SQL.  Sometimes doing stuff like this will take care of strangeness like you are reporting. Also, you'd have to detach the contentdb for the entire web application (unless you have set it up so that each site collection is using a unique contentdb).  Just note that doing this will cause downtime so if you are in the middle of your day, you might want to hold off until afterhours.

    John
    SharePoint911: SharePoint Consulting
    http://www.rossonmoss.com
    • Marked as answer by MejeeR Thursday, January 15, 2009 9:15 AM
    Wednesday, January 14, 2009 3:44 PM
  • Hello John, the detach/attach of contentdb via STSADM was sick :D It solved our problem!

    The wizard was able to complete the installation and the suspected orphaned site was nowhere to be found via enumsites / central admin and upgrade.log

    Prior to this we've also tried doing the DB detach/attach method via SQL itself but I think your method thru STSADM really disconnect the link between the MOSS and the CONTENTDB...

    Cheers. Thanks

    ReejeM
    Thursday, January 15, 2009 9:15 AM