Friday, June 29, 2012

How to move the LiteSpeedCentral database

We are running LiteSpeed at work in order to compress our backups in SQL Server. I was tasked with moving the LiteSpeedCentral database from one SQL server to another. A simple task one might think.

By a quick search, I found a support ticket that says that you simply do a backup/restore of the database and a reconfiguration of the LiteSpeed client on each server. Simple enough, I did that.

The reconfiguration could have been easier, i.e. swap "old server" for "new server" instead of having to reconfigure everything, but sure enough, it worked.

I then got a lot of warnings on my old SQL Server telling me that some service on the LiteSpeed application server is trying to connect to the database but is failing.


I did some digging trying to find out what was causing this. The warnings came with an interval of fifteen minutes which narrowed it down to the SQL Server Agent job LiteSpeed for SQL Server Update Native Backup statistics and more specifically the query exec [LiteSpeedLocal]..[LiteSpeed_ImportNativeHistory]. When I ran this manually, it executed without errors but I still got the login failures logged on the old SQL Server.

No matter what I did to reconfigure the LiteSpeed application I could get rid of this warning. Finally I managed to find a dicussion on the Quest support forum that pointed me to the registry where I could find entries that were left pointing to the old Central Database Server. They were at HKLM/SOFTWARE/Imceda/SQLLiteSpeed/Engine/ActivityServers/[Database]/ Deleting these entries solved my issue.

So seriously Quest. Is it so hard to have a properly documented procedure for moving the database? It should be a pretty common task for customers to have to do..

Wednesday, June 13, 2012

Script updates of contacts in Outlook

I wanted to have all of my colleagues contact information in my iPhone so I thought of the simplest way to handle it. I quickly decided that the best way would be to simple add the appropriate domain accounts as contacts in Outlook which in a few seconds work gave me about 240 new contacts with the correct information entered as they appear in our Active Directory.

I then realised that they all had the internal speed dial phone number entered as their work number. This is a four digit number which is the same as the last four digits in the externally used number. Hence I needed a simple way to automatically add a prefix to the number for each contact, but only those that had four digits in the field since my address book is filled with external contacts as well.
After fiddling briefly with macros, csv-files and other means to get this to work, I had an epiphany and thought of PowerShell.

Three rows of PowerShell code written, tested and executed in a few minutes solved my problem

$outlook = new-object -com outlook.application
$contacts = $outlook.Session.GetDefaultFolder(10)
$contacts.Items | % { if($_.BusinessTelephoneNumber.Length -eq 4) { $_.BusinessTelephoneNumber = "123-45" + $_.BusinessTelephoneNumber; $_.save() } }


Using PowerShell to automatically update lots and lots of data will most likely be the first I think of the next time a similar task appears. This was almost ridiculously easy.