A Sharepoint Services 3.0 setup I'm managing had a few issues lately, and I had to bring back up an old version of the system. The original setup had a Search Server Express 2008 installed, and the backup I restored did not, even though I had the databases for it.

After reinstalling everything that was needed, and having the Search Server properly indexing content, I kept having a lot of messages like "The database connection string is not available." in the event log, and "Your search cannot be completed because of a service error." in the search tool in any Sharepoint site. I had the content database properly associated with the correct indexer.

I did not notice at first that the service named "Windows SharePoint Services Search" was not started, and when I tried to start it, I had a nice "The handle is invalid." error message... Not very helpful.

A few posts around the web were suggesting to stop that service, then restart it. One suggested to check the user account of that service, which was "Network Service" for me. I changed it to the same domain account that the "Windows SharePoint Services Timer" service is using. At this point, the service was starting properly, but I was still having the "The database connection string is not available." message.

In the "Services on Server", I tried stopping the "Windows SharePoint Services Search" service, (telling me that it was going to delete the index content), which succeeded. But trying to restart the service gave me an error saying that the database already had content, and that I had to create a new one.

I did create a new database, but the service would still not start, this time giving an other error message that I enjoy so much : "An unknown problem occured".

I went back to some forum posts, and I came across a command to "initialize" the service from the command line with STSADM :

 stsadm -o spsearch -action start -farmserviceaccount [domain_account] -farmservicepassword [domain_account_password]

Which at first gave me this :

 The specified database has an incorrect collation.  Rebuild the database with the Latin1_General_CI_AS_KS_WS collation or create a new database.

I did re-create the database with the proper collation, then ran stsadm again and it gave me this : 

 The Windows SharePoint Services Search service was successfully started.

Hurray ! That did the trick, and indeed, my searches in any Sharepoint sites were not returing any error. I just had to wait for the service to refresh its index, and my search was running again !

This is a long and verbose post, but I hope this will help someone with this cryptic message...

I've had some hardware trouble lately, with hard-drives failing with some VMs on these, and my Hyper-V Mover tool hase saved me a great deal of time.

I've had some time to improve it and this time, it is possible to attach and detach VMs from remote machines, and particularly those that are on Hyper-V Server machines.

I've created a page for this tool, the Hyper-V Virtual Machine Mover, version 1.0.1.0.

Still no sources available but they'll be available on CodePlex soon.

A while ago, the Montréal's STM transit system announced that they were now supported by Google Transit.

While it is possible to trace proper routes, Google's having the same problem as I do, which is that the STM is updating schedules per trimester. And since it's the STM that is providing the data and that it's not been updated since the 1st of January 2009, schedules have been incorrect ever since.

To be perfectly fair, I did not update the schedules in my application since that time too by lack of time to create a proper update procedure, but I'm not paid for that either...

Now that I've given it some thoughts, I'm now streamlining the schedule updates stops after stops as long as they are out of date. Previously, I updated the database all at once, but this does not scale... Now the updates are progressive, which is far more manageable for me.

Anyway, now there may be a simple message saying that the displayed schedule is outdated, which is better than trusting the time and blaming the STM for no reason :)