The errors in the Eventlog were varied and painful, with lots of vague references to the apocalypse and the like. Naturally the logs get incredibly dense and I had another issue to contend with along the way - disk corruption. The ntfrs filesystem was reporting corruption and had taken out a chunk of the Sharepoint Wizard's configuration. That obviously had to be fixed first and was very worrisome - especially given I was working on a RAID1 disk.
Normally, because the database needs an upgrade when you apply SP3, if it doesn't start straight up you can run the SharePoint Products and Technologies Configuration Wizard to repair it. Failing that, you can disconnect the farm, fix the database issues and then re-run the wizard and connect back to the farm. With the disk issues and also with the failure of the systems admin to fully apply all the updates none of this was working - in fact the Wizard was failing spectacularly.
This is where things got to from my notes:
- Ran the config wizard and told it to disconnect from the server farm per MS documentation
- re-ran config wizard - it is now reporting that IIS is not working properly.
- have looked in to this - suggestion is that a compatibility mode setting has not been applied. Unable to apply this in Windows Server 2003.
- have run a repair on WSS 3.0 - this requires a reboot
- many many ASP.NET 2.blah errors. All non-descriptive and very dense to understand without being a .NET programmer.
I had a backup of the all the WSS databases, and the databases themselves were actually running on the server still. What I didn't realise and what I hope you, gentle reader, can take from this, is that the restore was far easier than I thought. I removed SharePoint from IIS, and created a new web application. I also created a new site collection and new database. From here I went to Content Databases and added in the old content database but I still couldn't get the right site to come up. In fact, the old content DB and the new one conflicted and I had no access to anything. What I should have done was this (all through the WSS Central Administration Site)
- create a web application
- in Content Databases add the old content database - you may have to use the stsadm command to do it which is:
- stsadm -o addcontentdb -url http://server -databasename WSS_Content (which is the default name)
- Check under Site Collection List - you should see your old website application there
- restart IIS and check the site.
Where I had a lot of pain was that I didn't realise the old site was held within the WSS_Content database and I didn't need to add a new site or create a new site collection. How remarkably painful is all I can say. I hope in future that it'll be a bit easier during upgrades.
Hello, There are an other more advanced and affordable option available in online for the SharePoint Recovery. I would like to suggest you to use this third party tool http://www.repairsharepoint.com which is the sophisticated tool that effectively repairs inaccessible MDF files and recovers the database.
ReplyDelete