Software

Ask something
Question Locked

Question about publishing non-msi applications

0 helpful
3 replies

by brenton keegan 2 views

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Hello Everyone,

I have a question regarding publishing non-msi applications. Publishing applications that do not use an MSI package for installation require the creation of a .zap file and the policies must be created as a user setting and not a computer setting.

Basically the problem I had is that the user need at least read access to the installer's location but I don't want to give them those kind of permissions.

My question is this: Is there any way around this? Perhaps some setting that would kick off the install as a different user.

(by the way, this is a windows 2003/xp environment)

3 replies

by robo_dev

There are a couple of approaches

Some people script alternate credentials into their installers and hide the credentials by compiling the scripts with a tool like autoIT

http://www.autoitscript.com/autoit3/

Some use remote install utils like Altiris software distribution to take the user out of the loop. e.g. http://www.appdeploy.com/

Scripting example for alt credentials:
http://mctexpert.blogspot.com/2009/06/how-do-you-provide-alternate.html

by brenton keegan

I use both AutoIT and altiris.

I thought about issuing a runas command in an autoit script and since it compiles as an exe it hides the credentials... as you said. Problem is that the user would still need read access to the autoit exe.

I assume you mention the altiris software as to somehow repackage them as an MSI so I can assign the applications, the problem is that I find repackaging them a bit of a messy operation... it becomes a really high maintenance process to handle frequent updates.

Personally I don't know if this is possible and I am only asking because my boss vaguely referenced some policy that allows for this. Personally I think he's thinking of Elevated permissions for installations.. which is like giving them temporary local admin and I think it only applies to things that use Windows Installer.

and it's not a good idea to use that as a user policy anyway... easily exploited.

This discussion is closed to new replies.