Enterprise Vault Outlook Add-In and Microsoft User State Migration Tool

[chrismbradford]

Hi guys, we're running a project to refresh client Operating Systems - the refresh involves using the User State Migration Tool version 5 to capture user settings/preferences and data from old devices and restore to new machines once the Operating System and applications such as Office are deployed.

Source/old machines are running Windows Vista or Windows 7, Office 2007 and have the Enterprise Vault Add-In for Outlook version 9.0.2.1136. Target/new machines have Windows 7 SP1, Office 2013 and Enterprise Vault Add-In for Outlook version 10.0.3.1090. All operating systems are 32-bit.

On machines where the User State Migration Tool is used every time Outlook is opened the following error is presented:

Either there is no default mail client or the current mail client cannot fulfill the messaging request.

If Outlook is started using outlook.exe /safe it opens without issue. If I disable the Enterprise Vault Add-In within Outlook, it opens without issue.

I’ve been through the following to no avail:

• http://support.microsoft.com/kb/813745
• http://www.symantec.com/business/support/index?page=content&id=TECH20486&profileURL=https%3A%2F%2Fsy...
• Removing the Enterprise Vault Add-In and re-installing doesn’t resolve the issue, neither does the ResetEVClient.exe utility.
• Run fixmapi.exe to no avail.

I’ve traced Outlook.exe with Process Monitor and on a USMT’d client I can see that Outlook is looking for mapi32x.dll (which doesn’t exist on either the source or target machine), but on a non-USMT’d client this file is never requested when I trace Outlook.exe with Process Monitor.

What we have noted is that the issue affects every Windows profile on the machine, those copied over by the User State Migration Tool, but also new ones - so whatever is occurring is breaking the Enterprise Vault Add-In for the machine, not a specific profile.

Finally, if we don't use USMT (not viable on the number of machines we have to replace!) I'm able to logon, and under a fresh user profile can open Outlook without issue,

If anyone has any suggestions please let me know - thanks!

[JesusWept3]

OK so quick q, when the profiles are being migrated, is it copying across all the EV registry settings and the EV Install binaries ? 

Or are you doing the migration and THEN installing the client?
or do you install the client and then bring across the user details?

Do you have any ev_client_ logs being generated in the temp area?
Also are these Vault Cache/Virtual Vault users or a mix of both non VC and VC users etc?

[chrismbradford]

By default USMT will not capture/restore any of the EV Add-In keys or data - I'm looking to extend this, but wouldn't expect this to affect a new Windows Profile on a USMT'd laptop.

The new machine is pre-staged with Offivce and the Enterprise Vault 10 Outlok Add-in before the user profile is migrated via USMT.

The EV Client logs are not generated for new logins on a mahcine that has been USTM'd. On a profile that was migrated I get the following:

21/08/2013 12:14:18.197[8048][H]: Log file created (level 1).
21/08/2013 12:14:18.198[8048][H]: Unable to perform a MAPI Logon: 0x80004005
21/08/2013 12:14:18.199[8048][H]: Loaded UI Language Path: c:\program files\enterprise vault\evclient\languages\en
21/08/2013 12:14:18.200[8048][H]: Loaded Help Language Path: c:\program files\enterprise vault\evclient\languages\en
21/08/2013 12:14:18.201[8048][H]: Module path: C:\Program Files\Enterprise Vault\EVClient\Valkyrie.dll
21/08/2013 12:14:18.202[8048][H]: No language resource module was loaded, the default English resources in Valkyrie.dll will be used
21/08/2013 12:14:18.203[8048][H]: A std::exception has been caught: Failed to create Desktop object.
21/08/2013 12:14:18.228[8048][H]: FUI: Not loading UI as action map is empty.  Is the user enabled?
 

Thanks.

[chrismbradford · Accepted solution]

Finally have a workaround - known error caused by USMT. Working with MS PSS modification of the following reg key will resolve the issue without an Office repair: HKLM\SOFTWARE\Clients\Mail\Microsoft Outlook\MSIComponentID Set this to the following value to resolve the issue: (6DB1921F-8B40-4406-A18B-E906DBEEF0C9} Initial tests excluding this from capture/restore via a custom XML but this doesn't seem to work. We're now using the following Run Command Line step in the USMT Task Sequence to resolve the issue: reg add "HKLM\SOFTWARE\Clients\Mail\Microsoft Outlook" /v MSIComponentID /t REG_SZ /d {6DB1921F-8B40-4406-A18B-E906DBEEF0C9} /f