SharePoint Services and SQL Reporting Services Must Start Manually on My Server
Here among the cubicles, a consultant from Microsoft told us to install SQL Server 2005 with Microsoft Office SharePoint Services. Since my development VM disk suffered hard disk sector and index problems for the first time, I am thinking of reasons why he told us to stay away from SQL Server 2008.
The Application Log of my VM was defiled by actual errors! It was SharePoint trying to log into my SQL Server 2008 instance but it wasn’t ‘ready’ to accept connections… I strongly suspect that SharePoint services will try to access the database during system startup and shutdown—when services SPTimerV3, SPTrace, SPAdmin and SPSearch are set to start automatically. What’s a dangerous possibility is that SharePoint might try to write to the database during a system shutdown. The 2008 SQL instance might ‘abandon’ SharePoint, leaving it to perhaps damage the disk with its unmanaged, wild-ass DCOM parts.
So it turns out that I have already written a PowerShell script to shut down services so I can run SyncToy 2.0 against things like *.mdf files. I run these backups from my VM before shutdown. Now with SharePoint and SQL Server 2008, I’m going to have to run this script after startup—to kick off the SharePoint services (SPTimerV3, SPTrace, SPAdmin and SPSearch) I have set to “manual.”
It’s been a tough week.
This entry was posted on Thursday, March 26th, 2009 at 8:33 am and is filed under .NET related, Data Management Solutions, InfoPath, Word, root. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.