I have created a path rule in Software Restriction Policies to install my msi (C:\temp\my_msi_file.msi). I have tried to install my application in non-admin account. It opens gently and starts installation. While installing it ended with the error "You do not have sufficient privilege to complete this action". In my installer i am accessing database and registry values. I think in this point the installation is fails. Is there anyway to run my msi application without admin privilege? It will be good to set in OS level.
Note: I want to give full access permission only the applications created by me.
Right click on the file; Select properties; Navigate to security tab; You can see the file permissions. Click edit. Select system in the list. Click Apply and Ok. Now you can install the file
Related
I just watched at a customer site the execution of an MSI of ours that needs elevation, because it is a per machine install. The operator at the customer site was logged in as a consent administrator (i.e. with a restricted admin token) and simply launched the msi package of ours with a double click, went through the UI pages in order to finally hit the "Install" button on the standard WIX "Ready to install" page. What you would normally expect now is an elevation prompt, so the per machine install can be performed. What happened today when I observed this, was an attempt to perform the installation without administrative permissions, which surprised me. The install soon showed an error message stating "insufficient privileges" and a rollback was performed.
I have never observed such behaviour before. What could be the reason that the install does not "self elevate", i.e. does not show an elevation prompt after hitting the button "Install"? Is there any windows configuration setting that causes this behaviour? The computer in question was running Windows Server 2016, in case that matters.
Any help appreciated,
--
Stefan
I have a scenario,
On a particular machine, I am installing my custom software with MSI installer. MSI installer is created with PerMachine tag, so software is available for all the users of that machine.
Now,
I installed the software on C:\MyApp\ directory.
Then I modified a few configuration files present in C:\MyApp\Config folder to make sure the software connects with my other services.
I started the application, it's working fine.
Now, on the same machine, I logged in with another user.
I started the application.
MSI windows popup with some progress bar for installation.
It vanishes and the application starts but fails to load.
But all the files I have modified are reverted now, I need to again modify those.
Few points:
My installation direcotry is C:\MyApp, not any custom user directory. So modified files should be for all the users.
I think MSI is rolling back changes when I logged in with the new user.
How to stop this?
Please help
Self-Repair: Windows Installer self-repair is the cause of the behavior you see. See the link for an explanation of what happens. See more here - several links with information on self-repair from various angles.
Short Explanation: Essentially the launching of an advertised shortcut triggers an integrity check of the installed files and if a file or registry setting is found to be missing a self-repair ensues. It will put in place missing files and settings. During this process it will sometimes overwrite changed settings files - the problem you describe (due to various file overwrite oddities of Windows Installer - a long answer with various hints).
Fix?: My preferred fix for this is to not install the settings files and update them, but to rather have your application generate them on first launch - either one file per user or a shared one for all users. You can also use a read-only copy of the settings file that you install to copy to a new file that you generate and update. I also recommend you put these files in a writable location in the user profile and not in the main folder. Your setup will never interfere with these generated files. You can also try to set the hosting component for the files "permanent" and "never overwrite". Not very neat. Here is a whole rant on the subject. The very best solution - in my opinion - is to keep settings in databases and get them on launch. This allows good control of all settings. Look out for network and firewall issues.
I hope this answers your question. Are you installing IIS files? I find commercial tool Advanced Installer to have the better feature list for IIS installation - though I lack enough data to conclude. Some videos here: https://www.youtube.com/c/advancedinstaller/search?query=IIS - WiX is also very good, but without the nice GUI of Advanced Installer.
Note: you really should not install to the root of C:\ anything at all. Windows Installer actively tries to make it hard, and side-effects are likely. You can, however, target the IIS folders - wherever they are located.
Update: I found this old answer on how to allow selective update of settings files - I had to resurrect the linked forum answers from Wayback.
Good morning, I have a problem with a Wix installer (it is the first time I use wix) it turns out that when I start everything is fine, and it asks me for administrator permissions, in the "install" button it shows me the icon that I will need those permissions
when I click on Install,
I get the windows to notice to provide the permissions. Until there everything is fine. Then I run the installer again, and it gives me three options, Change - Repair- Remove
I click on remove (which also has the icon that needs Admin Privileges),
but it doesn't ask me for Administrator permissions and it executes the uninstall badly, it doesn't delete registry keys and other things.
I need you to always ask me for the permits. Can someone tell me what's going on?
Thanks
I have a quite simple installer created with Wix Toolset. My users complaints that they can't deploy this installer as system user. They have to do it as user. However, I have learned that installers can be deployed as system user. Could anyone tell me what I need to do in my wxs file so that they can deploy it as system user?
We typically deploy our MSIs using Microsoft SCCM as SYSTEM. We use PSEXEC to invoke a CMD prompt as SYSTEM to do our dev testing before sending it to SCCM. There are two reasons an installer would fail as SYSTEM:
1) User error: I can't tell you how many times I've seen packages put into SCCM with invalid command line arguments. One of my favorite is quotation marks get turned into Unicode quotation marks via email transmission. Another is logging to a directory that doesn't exist. Another is forgetting to tell the MSI to run silently. It just sits there and hangs. Another awesome one is typing the MSI name wrong. It's especially awesome because they almost give me an SCCM log when I ask for an MSI log. No MSI log means it's not the MSI's fault.
2) Installer design error: Have you tested your silent installs? Do you have any custom actions that make assumptions about the user context / environment? One of my old favorites (not) was InstallShield InstallScript custom actions that would fail due to a poorly designed DCOM interface for talking to the MSI session handle. It's been almost 10 years since that was fixed but I still come across installers now and then. Another example is assuming that the user will have rights to another machine or the internet (SYSTEM typically has neither in a corp environment.)
I'd start with testing as SYSTEM using PSEXEC. Log the install and see what the error is. Otherwise you haven't really given us any details to give a specific answer for.
You should get them to do a verbose log of what happens when they do the install. There are issues sometimes related to user specific locations, for example a file going to the user's personal folder, what does that mean for the system account? Or the install or a custom action may assume that a drive letter mapped for a user is system wide (they're not - they are per user) and that can cause errors. That's what Chris is saying too - the context matters. The system account does not have access to the interactive user's desktop, the network, profile locations that make no sense for a non-interactive account and so on.
I also am a SCCM user and regularly deploy apps through SCCM... This WIX installer also drived me crazy. But Christopher's reaction helped me...
1) If Wix installers get tested using PSexec, they probably work, SCCM, I don't know what it is, but installs keep failing without apparent reason. (but it fails installing as System is true)
Solution: incorporate psexec in your script in SCCM...
add your setup.exe & psexec.exe in your source folder. Use following syntax in your setup script:
copy psexec.exe to your software source location.
%~dp0PsExec.exe -accepteula \127.0.0.1 "%~dp0setup.exe" --quiet
2) #WIX dev team: also try to test with SCCM!
3) if above fails, you can also extend the suggestion with:
add following syntax in your setup script:
c:\windows\system32\net.exe user /add WixHelpInstaller PaSSW0rd
c:\windows\system32\net.exe localgroup administrators WixHelpInstaller /add
%~dp0PsExec.exe -accepteula -u .\WixHelpInstaller -p PaSSW0rd \\127.0.0.1 "%~dp0setup.exe" --quiet
c:\windows\system32\net.exe user WixHelpInstaller /delete
I have a .nsi file I use to create my installation exe. I had given my file the follow execution level in the past (and it worked successfully):
RequestExecutionLevel user
This was so that it could be installed as a local user version or by admin on all accounts.
I was recently releasing another file with the same layout (i.e. copy files to install folder/create start menu short cut/HKCU register for install) it now requires RequestExecutionLevel to be set to admin or highest. When I checked with my other installer I found this was the case there as well now.
Why does my installer NOW require a higher execution level?
Has a recent windows update changed the RequestExecutionLevel required?
The RequestExecutionLevel NSIS attribute just sets the RequestedExecutionLevel node in the manifest and should work exactly the same in 7, 8 and 10 so there must be something else going on.
Have you tried watching the installer with Process Monitor to verify that you are writing to the correct location?