SharePoint: Love it when it works, hate it when it doesn’t
When SharePoint works everyone on my team is happy. I’m happy too because all I have to worry about are permissions and the odd configuration change. However, when things go wrong they go wrong. My week was has consisted of trying to recover from a failure. No idea why, but I do know what. The server that host the Site and SQL server failed either shutting down or starting up. I don’t know and neither do the operations team who are closest to the server. (I’m in the UK they are in the Seattle area). Anyone, blank screen dead box. Only thing to do is power the machine down and up again.
The good news was the Security patch applied, the bad news the SharePoint Configuration and Content Databases when offline. They refused to come back and seemed to indicate that the SQL instance was SQL 2000 trying to attach a 2005 database. Well as it turned out, SharePoint had used the MSDE version of SQL on the machine not the full 2005, but the databases appeared in the 2000 listing.
Only way back? That was to attached the two DBs in the full SQL and try and move the SharePoint config over. The fun starts here, the documentation in different areas talks about STSADM as the command to use, while the TechNet library indicates usign PSCONFIG. I used PSCONFIG and while this did 75% of the job, I was still having some issues, but not that kept my team from working.
After a couple of days, the team reported that the Project Server site was not working. I looked into it, and found that the services were not running. Attempting to start them just refreshed the admin page. When I attempted to re-install Project Server, it decided to delete all the SharePoint virtual web folders, and pretty much made the server look like MOSS 2007 was not installed.
The only recourse was to re-install MOSS 2007 and start again. First advice, bear in mind this KB article, https://support.microsoft.com/kb/927156. If you remove MOSS the key used to decrypt the passwords is deleted. You then have to discard you config database and start again.
Second advice, before you even start this process, document everything. The site, the web application names, the database names and their locations, the access path names, the works.
The third and final piece of advice I have is check you databases are backup, either via SQL or your backup software and practice a SharePoint recovery when there is no pressure on. I’ve done it now and next time – hopefully never – I have a much better idea of what the commands are, how they work and the procedure needed.
And that is my reason for not blogging for a week your honour.