I happened to find this interesting technote the other day :
As it was Enterprise Vault Outlook Add-in related, I took at look at the steps that can cause this sort of issue and what the Enterprise Vault Outlook Add-in installer tries to do when upgrading “across” client-types.
The issue comes about when you are changing from the DCOM, aka full, client installation to the HTTP, aka lite, client installation. A DCOM client has a few extra DLL’s installed by the installer. When you upgrade to the HTTP client, the installer should remove those DLL’s, and deregister them.
Why might you be doing that? Well you might be going from Outlook 2007 with the DCOM client to Outlook 2010 which needs the HTTP client.
The issue in the technote comes about when some of those removals don’t take place, and you’re left with an entry in HKEY_CLASSES_ROOT for EnterpriseVault.DirectoryConnection. When this happens the client sort of thinks it’s the full client, but it’s not.. and if your policy for the Outlook Add-in is set to “normal”, it’ll try to behave like the full client, and fail.. badly.
Unfortunately I don’t think there is a lot which can be done to prevent this happening, and so the technote I referenced above might then come in handy.
It would be interesting to know if many people have come across this particular issue, and whether they did anything else to resolve it.