Hello
I need to create a sccm application that installs X-lite on a bunch of computers. The current installer can be found here: http://www.counterpath.com/x-lite-download/
The challenge can be summarized like this:
- No logged on user has any admin rights.
- The exe installs to %localappdata%
- The office environment is free seating. So this needs to be installed in every users %localappdata% on all computers.
- The exe prompts for admin rights.
- The exe has no known parameters.
- X-lite has to be the newest version. At launch, it checks for updates and gives the user the choice to update (manually, requires admin) or close. Whatever the solution may be, this has to be low maintenance.
My solution so far:
- PADT script that runs Execute-ProcessAsUser -RunLevel HighestAvailable -Path $PathToExe -Wait
- The Deployment Type is run under the SYSTEM account, and the user is allowed to interact with the installer.
The installer interface shows up, the user needs to accept eula and press next. If the logged on user is admin, everything works fine. If not (which is the case here), the installer will prompt for admin credentials.
I was under the impression that ExecuteProcessAsUser would grant the logged on user admin rights from SYSTEM’s security token through a scheduled task. This seems not to be the case.
Thoughts?
Hi,
First of all you need to understand why your software need admin rights to be install. Maybe the software is uncompressing and one part need admin right and the other one will not.
Did you ask the Publisher Customer support? May be the Customer support have a machine base msi instead a user base one.
Thanks,
If I recall correctly, the installer creates two firewall entries and creates a shortcut in %public%\Desktop. I tried creating these manually before install, in case the installer would skip these steps, but no luck. The customer support has stated that there are no switches, but earlier versions did. I figure it’s because they want customers to upgrade to the non-free version called Bria.
Hi,
How are they suggesting to deploy that software on your computers? They should have a suggestion? Is it because it is a free version? If so then may be using the other version…
Thanks,
@kevin-2 quite an old thread but worth asking. Did you ever find a solution to this? "I was under the impression that ExecuteProcessAsUser would grant the logged on user admin rights from SYSTEM’s security token through a scheduled task. This seems not to be the case."
No, the customer changed to a different software that was possible to package properly
I was under the impression that ExecuteProcessAsUser would grant the logged on user admin rights from SYSTEM’s security token through a scheduled task. This seems not to be the case.
Execute-ProcessAsUser adds a scheduled task that runs as the currently logged on user. This will not grant extra rights but lets the installation execute user oriented stuff as the currently logged on user.
You can always do lower privilege stuff using a higher privilege account but you can not do higher privilege stuff with a lower privilege account.