Installer issue in deployment project VS2005

[Guest]

I have a installation package which installs ok when setup.exe is used, but
if I try to install via msiexec, I get an error "This installation package
could not be opened. Verify that the package exists..."

In partidular, I need to be able to uninstall this package unattended from
the command line, any suggestions will be appreciated. The version of
msiexec.exe is 3.1.4000.1823, msi.dll is 3.1.4000.4039

 

[Linda Liu [MSFT]]

Hi Bo,

If you launch the MSI package by double-clicking it, could the MSI package
install without any problem?

You may have a try installing the MSI package via msiexec command on other
machines to see if the problem still exists.

If the problem still exists on other machines, the MSI package may be
corrupted or damaged; otherwise, the Windows Installer on the machine where
the problem exists is possibly broken.

For the latter, you may recover the broken Windows Installer by upgrading
it. The following is the download link of Windows Installer 3.1
Redistributable (v2):

http://www.microsoft.com/downloads/details.aspx?FamilyID=889482fc-5f56-4a38-
b838-de776fd4138c&DisplayLang=en

Hope this helps.

Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Linda,

Thanks for responding. Yes, if you double click it installs just fine,
that's what's so weird about the problem. That and the fact that VS2005's
setup.exe installs it fine indicates to me unequivocally that the msi file is
not corrupt. I've installed V2 of installer 3.1, and it didn't have any
effect. The version numbers on msiexec.exe and msi.dll I gave in the original
post were those found post-install of installer 3.1 v2.

We have also seen older machines where msiexec.exe worked on this package
just fine.

I'm currently working on the following work-around: use setup.exe to pass
"command line" parameters to the installer API, like:

C:\> setup REMOVE=ALL LIMITUI=TRUE

This has shown some promise, but we've found instances where it fails to
remove the .dll the package installs from the Global Assembly Cache. We're
still working on it. I would prefer to know I can use msiexec.exe with VS2005
deployment projects!

Bo McIlvain

 

[Linda Liu [MSFT]]

Hi Bo,

Thank you for your prompt response and detailed feedback!

'm currently working on the following work-around: use setup.exe to pass

"command line" parameters to the installer API,

Could you please tell me with what tool you create the MSI package and
setup.exe? I don't remember we could pass parameters to setup.exe if the
MSI package and setup.exe is created with VS2005.

This has shown some promise, but we've found instances where it fails to

remove the .dll the package installs from the Global Assembly Cache.

How do you remove the DLL the package installs from the Global Assembly
Cache? What's the error message when you fail to remove the DLL from GAC?
For DLL that is installed by MSI, we could only uninstall it via MSI.

The following is a KB article discussing this topic:
http://support.microsoft.com/kb/873195/en-us

I would prefer to know I can use msiexec.exe with VS2005 deployment

projects!

Yes, we could use msiexec.exe with a VS2005 setup project. For example, to
add an uninstall program for your application, add the msiexec.exe file in
the setup project and create a shortcut for this file. Set the Arguments
property of the shortcut to "/x {ProductCode}".

Hope this helps.

Sincerely,
Linda Liu
Microsoft Online Community Support

 

[Guest]

Linda,

Thanks for getting back to me. I think we've almost got the problem solved,
after some intense work on it yesterday.

First, your questions:

1. The MSI package was indeed created with VS2005. The package installs an
Outlook 2003 COM Addin, used by a law firm client of mine to add buttons on
their email so that standard disclaimers an be easily added/removed from
outgoing email. I had given it to their IT dept to install, and we found a
bug in it after they installed it into their standard desktop image and
rolled it out to 500 users, so we wanted to uninstall/reinstall via remote
process driven by Altiris, which must be a non-interactive process, hence the
need to use command-line tools. While I was struggling with the failure of
msiexec.exe to do the uninstall, I remembered that many setup.exe's pass
command line params on to msiexec, so I tried that and got the error message
that the command line params were bad. I looked in the log file, and found
that the setup.exe produced by VS2005 was passing command line params,
unmodified, as a string to the MsiInstallProduct API call. The MSDN
documentation describes this command line as a set of MSI property settings,
so that's what you saw in my example. It works pretty well, although it
doesn't quite have the functionality of the msiexec.exe's normal command line
switches. For example, you can't get the full range of UI choices you have
with msiexec.exe. LIMITUI=TRUE works well enough for our purposes, however.

2. This is the heart of the issue. I realized after a while that the only
desktops where the uninstall using setup.exe and command line params was
working at all were on ones where I had uninstalled the old package at least
once using Add/Remove programs. We couldn't get uninstall to work ANYWHERE
except in the Windows Add/Remove Programs interface, which was unacceptable
as we needed to do this un-attended.

I have concluded that somehow we have in fact a mismatch between the .msi
package file I'm using for the uninstall and the one currently installed on
the desktops. So, what I did (and you anticipate me in you final comment) was
to go into the registry on a machine where the package was installed, search
for my package name under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall,
locate the uninstall string (which uses the Product Code, and not a .msi
install file!), copy it to a .bat file and change the command line switch
from /I to /x and added /qb to do it quietly (but not silently). This worked
at the local machine's command prompt, and we are testing today to see if it
works with Altiris, and I have high hopes for success at this point. So, if
we ignore msiexec.exe's error message about a corrupt file and address it as
a product mismatch, things are beginning to make sense again, and in my
experience that's the best indication that we're on the right path.

So, what appeared to be a problem with msiexec opening the .msi file
actually turns out to be that msiexec couldn't locate the package referenced
in the .msi file as an installed package on the machine, probably because the
product codes don't match. I thnk you should pass this along not as bug in
function, but as an erroneous error message. There was nothing wrong with the
..msi file except that it wasn't the right one!

Thanks for your help, this has been a tough one...

Bo McIlvain

 

[Linda Liu [MSFT]]

Hi Bo,

Thank you for your detailed feedback!

How about the problem now? If you use msiexec.exe /x {ProductCode} to
uninstall the application via Altiris, does it work?

So, what appeared to be a problem with msiexec opening the .msi file
actually turns out to be that msiexec couldn't locate the package referenced
in the .msi file as an installed package on the machine, probably because the
product codes don't match.

You could open the MSI package with Orca to see the ProductCode contained
in the MSI package. The ProductCode resides in the Property table.

Hope this helps.

Sincerely,
Linda Liu
Microsoft Online Community Support

 

[Guest]

Linda,

Well, it look like Altiris can't do that directly, for some reason it fails,
msiexec claims to be unable to find the installed package, and it doesn't
matter if you tell Altiris to execute as LocalSystem or as a domain admin
account. Since this DOES work for a logged-in user, we've come up with a
script we can execute when a user logs in, and we're proceeding with that.

Thanks for your pointer to Orca! I was unaware of its existence. I used it
to look at the .msi package that msiexec.exe told us it couldn't open, and
its product code matches the installed product code perfectly, so that's not
the problem.

Does Microsoft have any interest in pursuing this further? I think, as far
as we're concerned, our immediate problem is solved, but this experience
certainly lowers my confidence for using deployment packages. If you have any
suggestions for things we can look at to nail down the source of this error,
we'll be happy to work with you. I hate leaving bugs (whatever the cause)
unidentified.

Thanks for your help,

Bo McIlvain

 

[Linda Liu [MSFT]]

Hi Bo,

Thank you for your feedback!

Let me summarize this post first.

You installed your product on a client machine and want to uninstall it
now. You remote connect to the client machine using Altiris. Then if you
launch the MSI package by double clicking it, the product can be
uninstalled successfully. However, if you try to uninstall the product by
the command line 'msiexec.exe myapp.msi', you get an error "This
installation package could not be opened. Verify that the package
exists...". Your solution so far is to tell Altiris to execute as
LocalSystem or as a domain admin account.

If I have any misunderstanding here, please feel free to point it out.

What's the version of OS on the client machine? I found a KB article
addressing the problem that an error occurs when running Windows Installer
installation on Terminal Server or Remote Desktop connection. Although this
problem occurs when using Remote Desktop Connection and the error message
is different from that you get, the reason may be the same.

Below is the link of the KB article:

"BUG: An error occurs running Windows Installer installation on Terminal
Server or Remote Desktop connection"
http://support.microsoft.com/kb/255582/en-us

In additon, you may have a try connecting to the client machine via Remote
Desktop Connection and uninstalling your product via msiexec to see if the
problem still exists.

Hope this helps.

Sincerely,
Linda Liu
Microsoft Online Community Support