LoZ

On Sep 14, 11:17*pm, livingstone <livingstone_a...@yahoo.com> wrote:
> LoZ, Phil, thanks a million for your time and input. I am "not quite
> there yet". Maybe (most likely) because I don't fully understand /
> PASSIVE option and/or difference between running MSI from the command
> line vs. interactively-by double clicking the MSI. My understanding
> (and I might be wrong) is that /PASSIVE literally takes all default
> options to avoid having the user interact. If REPAIR is the default
> option when running the MSI by double clicking it for the second time
> why wouldn't the II run of the msi from the command line take supposed
> default option of REPAIR and actually run custom actions as well?
>
> Also, the second consecutive run of the MSI from the command line
> msiexec /I Something.MSI /PASSIVE
> msiexec /I Something.MSI /PASSIVE
> will actually DO SOMETHING so to some extent I have to disagree with
> LoZ that>> "This won't just not run the CAs, it won't actually do anything. "
>
> If any of the files installed by the first run of the MSI get deleted
> (by mistake, for example), running the MSI on top of itself in
> Scenario #2 will actually reinstall the missing files - isn't this a
> sort of repair?
>
> Maybe I should I ask the question like this: how can I make sure that
> CAs will execute on the II consecutive run of
> msiexec /I Something.MSI /PASSIVE
> LoZ, I tried your suggestion to set condition on my custom actions to
> REMOVE<>"ALL" and it didn't help - CAs still don't run in Scenario #2
> outlined in my first post.
>
> To answer LoZ's question - the reason I am even trying to test running
> MSI on top of itself
> msiexec /I Something.MSI /PASSIVE
> msiexec /I Something.MSI /PASSIVE
> is to have a full understanding of what it does, if anything, in case
> my customer ends up doing it. My customer always runs with /PASSIVE
> because they push my MSI via SMS at night and the requirement is that
> no user interaction is permitted (MSI is sort of silent, userinput-
> less install). I needed to know what happens, if anything, if the
> customer pushes the same MSI by mistake two times in a row. Now that I
> discovered what it does I am trying to make the second run of the
> msiexec /I Something.MSI /PASSIVE
> do the exact same thing that the first run did. Maybe I *am chasing my
> tail?
>
> Thanks again folks.
> Cheers,
> livingstone

Hi livingstone,

The behaviour you see during a second installation (msiexec.exe /i) is
entirely by design. The thing to bear in mind is that Windows
Installer is aware that the product you are installing has already
been installed and registered on the machine. In UI mode (/passive not
used) Windows Installer offers the user the chance to say "whoops,
wrong command line" and choose to repair or modify (REINSTALL property
gets set) instead.

In non- or basic-UI modes (/passive, /quiet) Windows Installer just
sees that the product is registered and effectively does nothing. This
is expected behaviour. It's being run non-interactively so there is no
user sitting there to tell it what they ACTUALLY meant to do.

I work for a big company using SCCM to deploy MSIs and can assure you
that this is the behaviour that I see when an advertisement is re-run
on a machine. It fires the same command line (msiexec.exe /i <msi
path> /quiet) and Windows Installer kicks in to handle checking
whether the product is already installed.

I may not have communicated it very well but I was not expecting that
conditioning a CA using REMOVE<>"ALL" would run under your scenario
#2. But it is exactly the condition you would use to ensure that the
CA fired in every valid execution mode (install, repair/reinstall) and
not when the product was being uninstalled.

Hope this clears it up a bit.

Cheers,
Loz