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
Related
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
If the application is running and user tries to uninstall the application then it doesn't give an option to close the application like it use to give for normal wix. This problem has occurred only after I moved to bundle project. Any step to be performed?
Earlier it use to give The following application should be closed before continuing the install:
There are a few things to look at:
If your bundle uninstalls the MSI product completely silently then the uninstall will obey that rule and will not offer any files-in-use dialogs.
Windows Installer sometimes decides not to force the user to shut down the app if it can be process isolated and cleaned up when the user finishes.
A verbose log will give more detail.
WiX has the CloseApp help for closing down apps, and integrating the app with Restart Manager can also help these situations.
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 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
I am new to programming in Go. I would really like your help regarding one of my problems.
I am required to do go install on a file, the executable of which (in Windows) is created in a folder called GOPATH\bin.
Until now, I typically followed the routine: go install <file>.go ---> <file>.exe.
However, this time it appears that after the execution of <file>.exe, the exe doesn't finish complete executing for a while and I get the following error when I go install again.
C:\Users\Rahul\Desktop\Compilers\src\cs553s2013\mylexer>go install
is_digit.go go install command-line-arguments: open
C:\Users\Rahul\Desktop\Compilers\bin\is_ digit.exe: Access is denied.
See http://grokbase.com/t/gg/golang-nuts/135fyje5d9/go-nuts-go-build-access-is-denied-windows-7x64
Absolutely no idea why, but the above suggestion worked. One must enable the "Application Experience" windows service on Windows 7 to solve this issue.
I had this service disabled, and was seeing a similar strange 2-3 minute time of "Permission Denied" on my project's binary (the binary would also disappear after a refresh via alt+F2 of $GOPATH/bin, from a Windows Explorer view of the $GOPATH/bin where Eclipse + Goclipse was building my binary). I noticed that just after execution, and before the binary finally disappeared, it was changed to be owned by some unknown user (in Explorer, it isn't owned by the compiling user, Administrator, or even SYSTEM).
I can only speculate -- perhaps Windows keeps any .exe on the filesystem, if it has exited without some sort of undocumented 'all-OK' status to the windows kernel, assuming it 'crashed', so the Application Experience service can send it as diagnostic data to Microsoft -- and if that service is disabled, the Application Experience service can't finalize whatever handshake NTFS or Explorer is waiting for to allow the file to be overwritten by subsequent compiles. So the golang .exe sits there, with elevated permissions, with some system/undefined user, un-deleteable by Eclipse, until Explorer does something to mark it as definitely dead.