Gidday All,

I have an existing per user installation (msi) which I'm upgrading to per machine install.

Active Setup runs but doesn't seem to upgrade the existing per user installation when logging on with another profile.
All Features are constant in both packages and I've changed the Product code on the Upgraded package as well as having the right upgrade code from the per user install.

My command line in the Active Setup StubPath is: msiexec.exe /i {48B59286-A818-4DAE-92FE-F48A9B6346B2} /qb! REINSTALL="ALL"

I have also tried using the WI 3.1 property: MSIENFORCEUPGRADECOMPONENTRULES=1 at the end of the StubPath command line.

Am I missing something?

Thanks in advance,

Wayne
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Hi Wayne,
i got some confusion here.
What are you doing exactly by "an existing per user installation (msi) which I'm upgrading to per machine install"?
Just a hint: Active Setup runs in users context, therefore, a 'REINSTALL="ALL"' mostlikely won't run because of permission issues!
Regards, Nick
Answered 11/02/2006 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
shouldn't your stubpath just be MSIEXEC /fu {GUID} ....

that should result in the profile resident portion of the MSI pushing out.
Answered 11/02/2006 by: fosteky
Purple Belt

Please log in to comment
0
Thanks Nick and fosteky,

Nick,
I have an existing installation that was installed in the per user context from the DFS. Even though the REINSTALL runs in the user context, I thought that it would run what's in the upgrade table under this context using the Active Setup; which should remove the user installed msi package.

Fosteky
I originally had the switch on the StubPath /fusom which didn't work for me. The /qb! is only there for debugging and will be silent when moved to prod.


Also, I'm using SMS deployment, this means that it installs in the system context which fails to recognise per user installs unless you assign the per user installation tick to the install program. Which installs in the per user context; which gets us no where.


A bit of a quandary. I don't like per user msi's a lot (that's said in my "you've got to be joking" context[:@])

I appreciate the replies,

Thanks
Wayne
Answered 11/02/2006 by: WayneB
Blue Belt

Please log in to comment
0
Hi Wayne,
time has come, that scratching the surface will bring you not further anymore. :-)
Turn on Logging, and look what exactly happens.
The logfiles for a GPO install go to %systemroot%\temp.
One way to go, would be a 'dummy' MSI just to uninstall the existing thing, via the upgrade code.
Afterwards, you can install the app normally.
Regards, Nick
Answered 11/03/2006 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
There were a post on Altiris support forum (forums.altiris.com) regarding your issue. Sorry can seem to find it right now but maybe you'll have the time to search a little harden then me;)

Are you using the Upgrade table for this upgrade? As if so a per user installation will not be found in a per machine upgrade so you will author a custom action to set the upgradecode. If you do find the post at altiris that will touch this.
Answered 11/03/2006 by: AngelD
Red Belt

Please log in to comment
0
Thanks Nick and AngelD,

Spent too long on this already, times a wasting and there's too much fun in store, so had to make a judgement call.

We'll do a separate per user uninstall of the application using SMS. run it as a mandatory ad if it exists. Kinda what you suggested Nick.

I've thrown in some code that will go through all the user profiles and remove any Desktop and Start Menu shortcuts so that the self repair is not triggered. This is done through a CA in the upgraded app.

I'll chase down that article thanks AngelD.


Have a good one,
Wayne
Answered 11/06/2006 by: WayneB
Blue Belt

Please log in to comment
0
Hi Wayne,
good to read, that you found a solution.
There is also a very good two-part article about this subject on Codeproject:
http://www.codeproject.com/dotnet/msi_upgrade_uninstall.asp
It even has a DLL to set the UpgradeCode when you want to switch the installation context.
Regards, Nick
Answered 11/07/2006 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
Thanks nheim!

That was exactly the "two-part article" the Altiris Support Forum thread referred to and which I was trying to find.
Answered 11/07/2006 by: AngelD
Red Belt

Please log in to comment
0
Thanks Nick and AngelD,

That's a great article. I had a problem with the sites picture displays though; with Part 2: Define the Custom Action and Sequence the Custom Action execution. But the information is great.


Regards
Wayne
Answered 11/07/2006 by: WayneB
Blue Belt

Please log in to comment
Answer this question or Comment on this question for clarity