Murphy's Law can apply anywhere anytime and my recent re-installation of SharePoint is certainly no exception to the rules.
Soon after I finished recreating our SharePoint intranet, I stared sharing it with my immediate colleagues. While I was not really expecting some "Oh!" and "Aaah!" cheerful comments, I was still hoping for some kind of "Cool, it's back, thanks for the tool.".
But no, even that was expecting too much. The very first comment I received was an assassin comment like: "And I suppose you managed to retrieve all files stored in the previous SharePoint database ?". That comment triggered a machine-gun like stare from me to my colleague. No, I did not manage so far to retrieve these files and yes I had tried already. SQL Management Studio did not really help me by the way.
I had been cornered and really had to find a solution this time. So I returned to the web, googling frantically, trying various unsuccessful solutions until finally my patience and stubbornness got rewarded. I found found a great article from Keith Richie describing how to export the site content from a SharePoint Database for recovery purpose.
His article include a small source code and instruction to compile and run the program. It worked almost like a charm from the first run. Yet, as some of the recovered files were quite large, I had to boost the buffer size (as I worked locally this was not a problem) and even tweak the SQL query to work on a per directory basis to limit the execution run time. Happily this time SQL Server Management Studio was of great help to test and fine-tune the queries. Within 30 minutes from the moment I read Keith's post I had recovered all files I needed.
Today all files are imported in the new SharePoint and I preciously kept the program source and instruction ... just in case one day I need to recover files from another SharePoint database.
Friday, March 27, 2009
Wednesday, March 25, 2009
The Revenge of SharePoint
Remember my SharePoint article from 2 months ago ? Well, believe it or not, but I have crashed my SharePoint site beyond my repair skills capabilities. It happened after a domain migration and was due to some dark account permission problem on the SQL 2005 database.
After having wasted a few hours on the problem, I decided to re-install it from scratch on a new and better set up virtual machine. After all, it was only a prototype without too much production data in it.
The first thing I did was using my previous SharePoint installation article as guideline and i will say it was definitively worth writing it and I got my payback for it. While I was at it, I also wanted to bring in a couple of improvement to my initial setup.
As SQL Server 2005 was installed on the C:\ drive, I needed to move the SharePoint databases to the D:\ drive which was designed to contain the data. I proceeded as follow after having installed Sharepoint Services:
In order to move a Microsoft SQL Server 2005 SharePoint database, I needed to:
- Stop the IIS SharePoint site.
- Stop all Windows SharePoint Services: Administration, Timer & Tracing.
- Backup the SharePoint content and configuration database.
- Detach these databases using SQL Server Management Studio.
- Move the database files (.ldf & .mdf) to the new location.
- Attach these files back to SQL Server 2005 still using the SQL Server Management Studio.
- Restart the SQL server.
- Restart all SharePoint services.
- Restart the iis SharePoint site.
And it worked like a charm.
I decided to add some better web parts to the portal and as such downloaded and installed What's New, Chart, AutoComplete, and Copy Paste web parts from the SmartTools suite on CodePlex. The What's New web part is probably the best of them. All these parts are ridiculously easy to install and deploy.
I also wanted to change my security strategy and to really use two Web Applications: one for the Central Administration on some exotoc port and the SharePoint content sites on port 80. As I had already recreated my content sites under the Central Administration, I needed to move them all to a different application in order to better manage their security. Therefore I had to first move the Central Administration from port 80 to another port (see my article for instructions), then create a new web application on port 80, export all created sites and re-import them into the newly created Web Application on port 80. The export/import operation was made simple thanks to the stsadm command line tool. Afterwards I simply had to uninstall and re-install the CodePlex SmartTools to have them active under the new Web Application.
And that's it, my SharePoint site is now back and ready to be used.
After having wasted a few hours on the problem, I decided to re-install it from scratch on a new and better set up virtual machine. After all, it was only a prototype without too much production data in it.
The first thing I did was using my previous SharePoint installation article as guideline and i will say it was definitively worth writing it and I got my payback for it. While I was at it, I also wanted to bring in a couple of improvement to my initial setup.
As SQL Server 2005 was installed on the C:\ drive, I needed to move the SharePoint databases to the D:\ drive which was designed to contain the data. I proceeded as follow after having installed Sharepoint Services:
In order to move a Microsoft SQL Server 2005 SharePoint database, I needed to:
- Stop the IIS SharePoint site.
- Stop all Windows SharePoint Services: Administration, Timer & Tracing.
- Backup the SharePoint content and configuration database.
- Detach these databases using SQL Server Management Studio.
- Move the database files (.ldf & .mdf) to the new location.
- Attach these files back to SQL Server 2005 still using the SQL Server Management Studio.
- Restart the SQL server.
- Restart all SharePoint services.
- Restart the iis SharePoint site.
And it worked like a charm.
I decided to add some better web parts to the portal and as such downloaded and installed What's New, Chart, AutoComplete, and Copy Paste web parts from the SmartTools suite on CodePlex. The What's New web part is probably the best of them. All these parts are ridiculously easy to install and deploy.
I also wanted to change my security strategy and to really use two Web Applications: one for the Central Administration on some exotoc port and the SharePoint content sites on port 80. As I had already recreated my content sites under the Central Administration, I needed to move them all to a different application in order to better manage their security. Therefore I had to first move the Central Administration from port 80 to another port (see my article for instructions), then create a new web application on port 80, export all created sites and re-import them into the newly created Web Application on port 80. The export/import operation was made simple thanks to the stsadm command line tool. Afterwards I simply had to uninstall and re-install the CodePlex SmartTools to have them active under the new Web Application.
And that's it, my SharePoint site is now back and ready to be used.
Friday, March 13, 2009
Twenty years of World Wild Web
Happy birthday, Tim. ;)
The Web is indeed wide today ... but no less wild.
The Web is indeed wide today ... but no less wild.
Subscribe to:
Posts (Atom)