Clients with Beta MSI packaged with 3.1 VMO form

[Ginger Dillon]

Hello -

We are testing SMS deployment of VMO 4.0(3)B required for Outlook 2003. Many of our clients are running a beta version of 3.1.4.62 (tfxext32.dll version) and 3.1.4.39 (avmmoctrl.ocx version). This was a beta MSI that was packaged with the 3.1 VMO form since we were running 3.1(5) on the server at the time. It corrected a problem with spaces in the VMO General tab for extension and server name. We have a mix of 3.1 and 4.0(1) and 4.0(2) clients in our organization and as such are following the recommended VMO install instructions. For 3.1 installs, the recommendation is to overlay instead of attempt to deinstall due to problems (i.e. Dr. Watson errors, registry key info left behind, etc.) For 4.X installs, the recommendation is to first remove, then reinstall 4.0(3)B. If our script encounters a client with a 3.1.0.56 version of tfxext32.dll, the overlay of the 4.0(3)B client runs successfully. However, if we initiate the 4.0(3) MSI on a 3.1.4.62 client, we get the screen prompting to Repair or Remove. Here are my questions:

1. Can we find out which file the MSI is looking at which prompts for the Repair or Remove? If we have that information, we can check the version of the file in our script before executing the MSI.

2. Even though the clients are running a beta version of the 3.1 MSI, do you think we can safely deinstall those clients before running the 4.0(3) MSI? We did try running Repair, but that does not install the new software.

Thanks so much :-)

Ginger

[path]

Hi,

Not sure I am following the where the MSI appeared in a 3.1 build since it is only for VMO 4.x; but for now here are a few answers.

Q1:

The MSI based installer looks at the registry entries for the VMO ProductCode (that would be {D43281E3-D934-46D3-8341-66B7B4BFC626}. If another product with the same code was installed via the Microsoft Software Installer service we can have a clash here (1 out of a few billions chances), I would expect this is not the case and a previous version using the MSI based VMO package is present. After a quick registry check or using the msiexec application to find if the name package name matches we can figure out a better course of action. The ProductVersion property is important to look at; since this is what controls the choices displayed (repair, remove, upgrade).

Q2: I will have to test this first. I can't give you a better answer than the caution/note you already have. On the other and, the 4.0(3) MSI can remove the older version if it detects their presence. this detection is based on inspection of the values for these registry entries:

"HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\ViewMail for Outlook\UninstallString" and

"HKLM\Sodftware\Microsoft\Exchange\Clients\Extensions\ViewMail Extensions"

[Ginger Dillon]

Hi -

Thank you for your quick response! I have forwarded your info to our SMS team and we will test as well. Regarding the MSI, back in 2002 we had 3.1(5) running in test. Over a weekend, we merged two CCM clusters into one AND upgraded our production unified messaging customers from Unified Messenger to Unity 3.1(5). The Unity development team was instrumental in making this high-profile change a success for us. We were able to push a beta version of the MSI, that did not require CDO, out to several hundred clients with SMS and did so without disruption to our customers' lines of business. Now we are preparing for Outlook 2003 and the deployment of VMO 4.0(3)B to those same customers. Our goal is to make the upgrade as seemless as the last one we did :-)

Sincerely,

Ginger

[gfrison]

I think the best approach is to force an uninstall for the VMO MSI and then install the new VMO MSI, all via the command line msiexec.exe. The uninstall can be done with no UI via:

msiexec /q /x ProductCode

If the prior VMO is not installed via the MSI, this will fail, but that can be of course ignored (and without a UI, it will not be noticed either way). If it is installed, it will be removed. Then the subsequent install of the latest VMO will always be in a "fresh install" state.

This should work for both the "beta" MSI and the newest one. If VMO is installed by the non-MSI installation, as already noted, the latest MSI will detect that and delete it.

About the only issue would be if the ProductCode is the same for the "beta" and "public" VMO MSI's. An easy trick to find the VMO MSI ProductCode is to look into the uninstall command that is run via Add/Remove Programs:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Search that key on down for "ViewMail". Note the "UninstallString" key will have something like:

msiexec.exe /IProductCode

So it simply uses the command line switch for msiexec to 'install' with the ProductCode (which offers Repair, Remove, etc., since it's already installed). Similarly, msiexec /q /x ProductCode will force an uninstall (remove).

[Ginger Dillon]

Hi Glen -

Great information! Thanks so much also for your level of detail :-)

Sincerely,

Ginger