Strange to find someone wanting to remove a server from their network these days but in our times of downsizing it does happen. Everything was going swimmingly, I had removed all the workstations except for the last one which had Outlook Business Contact Manager installed. I didn't expect any issues but received a nasty surprise when the user tried to fire up Outlook Business Contact Manager as a stand alone user.
When Outlook loaded it said that the login to the Business Contact Manager database was incorrect and that I had to attach to an existing database or create a new database. Hmmm...ok so I'll try and attached to the existing database - no go, so I elect to create a new database. Problem is that the client uses Business Contact Manager extensively so they needed the old database back. With a new Business Contact Database Outlook loads but there is no Contact Manager data.
Thinking, thinking, thinking....why would the login details be wrong? <Bing> Ah ha, because the previous login was on the network (ie domain\user) and the login now is just user (ie localmachine\user). This would still be the case even if the user names and passwords were identical - different privileges between a domain and a workgroup. So now I knew why the login was failing, trick was how do I fix it?
The first thing was to check that the original Business Contact Manager database files were still on the system. By default the database is installed in c:\documents and settings\<user>\local settings\application data\microsoft\business contact manager. The database is probably called msbusinesscontactmanager.ldf and msbusinesscontactmanager.mdf. In this directory I clearly had 2 sets of databases an old (prior to removal from network) and a new (after removal from network).
Next step was to go into services.msc and locate the local SQL service called MSSQL$MICROSOFTSMLBIZ and right mouse click on it and select stop. With that done I returned to the directory and renamed the existing business contact manager out and the old database to what the name of the existing database had been. so existing -> save then old -> existing. I then returned to the services.msc screen and started the MSSQL$MICROSOFTSMLBIZ service, then I restarted Outlook.
When Outlook started I saw a dialogue box saying that the Business Contact Manager was initialising after which Outlook loaded. When the client checked all the information he had stored using Business Contact Manager was back. Phew.
It would have been nice if Business Contact Manager would have warned me that I might have an issue logging into the database if I detached from the network but you can't cover every eventuality can you? At least it wasn't too hard to fix but I certainly had to do some testing beforehand since I couldn't find much on the web. Sometimes it is quicker to run up a Virtual machine and try it for yourself.