Hello all,

I have installed an application using the following command line via SMS 2003:

msiexec /i AppName.msi ALLUSERS=1 TRANSFORMS=AppTransform.mst /qn /lwei %windir%\temp\INSTALL-AppName.log

When I test the app however a call is made to the source location for additional files etc. I would like to stop this happening if possible and thought that using "ALLUSERS=1" would help...not so.

Of course I can allow users to access the required files quite easily (by altering permissions on the network location) but this just seems a bit messy and I would like the application to install all required components.

Hopefully this is just a simple problem for someone to help with and I had hoped that I could find a solution on App Dep without posting so sorry if this question has been raised somewhere else and I just haven't been able to find it.

Thanks in advance

Mos
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
- This is the wrong forum for your post. This forum is concerned with errors returned by the Windows Installer engine itself. I initially thought it belonged in the 'Distribution/SMS' folder but now I think it should be in 'Package Development'.
- ALLUSERS only controls whether you get a per-machine or per-user install. Look up th eproperty and how to use it on MSDN.
- As the application is calling for extra files as you use it, I'd say that it's performing a repair. This will be due to files needing to be installed into the user's profile folder or to registry entries being made to the HKEY_CURRENT_USER hive. This behaviour is entirely expected. If you don't want it, the application *may* be persuaded to work with the files being installed to the 'All Users' profile instead or, if the repair is being caused by HKCU registry entries, by moving those to HKEY_LOCAL_MACHINE equivalents. From what i know of developer's idleness, I'd say that that "fix" would be extremely unlikely to work.

Have a look in the Event Viewer's Application log. That will show you the GUID of the component being repaired. You can trace back from that GUID in the MSI which actual component is involved and go from there.
Answered 01/20/2009 by: VBScab
Red Belt

Please log in to comment
0
Thanks for the insight and apologies for posting in the wrong place. This all makes sense as I have been trying to add some reg settings to HKCU to get the app to work for each user...looks like I’ll have to make a share for the app to get around the "repair" type prompts... Thanks again Mos
Answered 01/20/2009 by: mosquat
Orange Belt

Please log in to comment
0
looks like I’ll have to make a share for the app to get around the "repair" type prompts... Why? Is it that the vanilla users don't have access to the original source?
Answered 01/20/2009 by: VBScab
Red Belt

Please log in to comment
0
Well normally users dont have access to the SMS source packages (no need really) but in this case it would make sense to use a distribution share with permissions set so they can call the source upon first use....hope this makes sense?
Answered 01/20/2009 by: mosquat
Orange Belt

Please log in to comment
0
Use Live Search instead.


ORIGINAL: VBScab

looks like I’ll have to make a share for the app to get around the "repair" type prompts... Why? Is it that the vanilla users don't have access to the original source?

Answered 01/21/2009 by: rodtrent
Orange Belt

Please log in to comment
0
LOL...Oh dear...more evidence of MS's relentless plugging of Live Search...

At my current client, it's a standing joke that any MS rep (even those from MS partners) ALWAYS use Live Search whereas the rest of the universe use Google. Market forces and all that, Rod...
Answered 01/22/2009 by: VBScab
Red Belt

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