when insatlling msi using Group Policy, install claims it is alreayd intalled

[jogdial]

Development team have an application and they created an install shield project. They recently created an single MSI of the app to install for a specific customer. The MSI works fine when you just double click it and it installs. The problem is that the customer wants to deploy this application using group policy and when I try to deploy this from my 2003 server using a GPO, the log files indicate that it thinks it is already installed. It is not, clearly as when I immedately go to the share where the MSI is located for deployment, and click on it, it installs. It always uninstalls cleanly and I never get this message when installing by clicking the MSI, only when GPO tries to install when the GPO is applied.

Strangely, this is unique to the intall that my development team creaeted. As a test, I created an install project using the project assistant and a single executable file to install. I created a single MSI package, assigned it in the group policy and it installs perfectly.

I didn't design the install development are using. I'm more or less a troubleshooter, I used to be quite expert at IS - about 7-8 years ago and as this has escalated they have brought me in as the expert as I know how IS works and I do the AD group policy setups.

So, after that background, is anyone aware of why an install would fail saying it is already insatalled, installation will halt, when deploying with GPO but install fine when done interactively? I've been poking and proding at this problem for about a week now and have consulted the Microsoft Directory Service and GPO forums and everyone is scratching their heads. I have compared my test project and the development projectd in the project assistant and can't see any differences, but I probably need to go deeper I would guess... any thoughts, ideas and especially flat out answers are deeply appreciated.

Thanks
Bill

[MichaelU]

This sounds reminiscent of a case where the package may be reusing a package or product code that's already installed. See if the Product Configuration is specifying one (try again with Package Code empty and Generate Package Code set to Yes), or with a new ProductCode in General Information. (Make sure to save a copy of your product code before testing this if you need to create further Minor Upgrades or Patches)

[jogdial]

thanks for the input, I have found a lot of that on google, first the developers put new codes in and I tried it and still the same with pretty much any code... and also why would it install when I run the msi manually vs when I deploy with a group policy?

In the MSI debug files, it says a newer version is installed - variable is set, but I don't have the logs in front of me this evening - but unintall the newer version.

These are test systems that I am installing on which have virtually no software on them and it seems unlikey coincidence that the same code woudl come up.. and I have searched the registry for these code and found no matches.

Again, thanks for the help - I'm running out of any ideas on my own.

Bill

[jogdial]

Looking at the log files it would seem that the thing that is triggering it into thinking that it is already installed is the return from LaunConditions return value of 3... I've been looking at this and I can't see any reason/or what the reason is for returning a 3. A good install obviously returns a 0 or 1, can't remember which but I looked at an install that succeeded and it wasn't a 3. The appsearch is returning 0, so it isnt' finding the app... this is sooo frustrating and I'm supposed to have it working by 2pm here in the UK. 😞 before customer conference call, just love it when you have a deadline to work to - relevant bit of msi log file:

Action ended 10:50:49: DLLWrapStartup. Return value 1.
MSI (s) (08:54) [10:50:49:583]: Note: 1: 2205 2: 3: AppSearch
MSI (s) (08:54) [10:50:49:583]: Note: 1: 2228 2: 3: AppSearch 4: SELECT `Property`, `Signature_` FROM `AppSearch`
Action start 10:50:49: AppSearch.
MSI (s) (08:54) [10:50:49:583]: Doing action: LaunchConditions
Action ended 10:50:49: AppSearch. Return value 0.
Action start 10:50:49: LaunchConditions.
MSI (s) (08:54) [10:50:49:583]: Product: TNT-it -- {&TahomaBold8}A version of this product is already installed. Installation cannot continue.

{&TahomaBold8}A version of this product is already installed. Installation cannot continue.
Action ended 10:50:49: LaunchConditions. Return value 3.
Action ended 10:50:49: INSTALL. Return value 3.
Property(S): DiskPrompt = [1]
Property(S): UpgradeCode = {08272914-2315-4164-968E-99C7BE751A90}
Property(S): ProductCode = {7D47F3F3-096C-4B77-A6C2-D79FA0E711EF}
Property(S): ACTION = INSTALL
Property(S): UILevel = 2
Property(S): OriginalDatabase = \\lisa\installpackages\TNT-it.msi
Property(S): DATABASE = C:\Windows\Installer\9e53.msi
Property(S): Privileged = 1
Property(S): MsiRunningElevated = 1

[MichaelU]

If that's a verbose log, you should see property change notifications, so you can tell what the AppSearch does to the properties you check in your condition. It sounds like your candidates to look at are your properties' initial values, the AppSearch(es) and what they do to your properties, and the condition of tied to the message.

[jogdial]

I found the problem... there was a condition in LaunchConditions that no one seems to know how it got there and we took it out and it's working now... thanks to all for help.