I have written an msi which deals with registry. So, i have to run the msi as admin.
when i directly click and launch the Msi,I get the following error to modify the ini file "Access to the path is denied"
It works fine if i launch the msi from command prompt(Right click as administrator.)
I tried all the below suggestions but none of them is working. please assist how to run msi as admin.
Package Id="*" InstallerVersion="200" Compressed="yes" Platform="$(var.Platform)" InstallPrivileges="elevated" AdminImage="yes" InstallScope="perMachine"
CustomAction Id="UpgradeSelectedVersion" BinaryKey="CustomAction" DllEntry="UpgradeSelectedVersion" Execute="deferred" Impersonate="no"
Property Id="ALLUSERS" Value ="1"
or
Property Id="ALLUSERS" Value ="2"
Try the following:
<Property Id="MSIUSEREALADMINDETECTION" Value="1" />
Otherwise, you could wrap your installer in a wix managed bootstrapper application, a bit more work though. Then you add settings to your manifest file.
That custom action is deferred, which means it must be running in the InstallExecuteSequence, which should be elevated and running with the system account if you have InstallScope per machine and elevated privileges.
Don't mess with the ALLUSERS property because WiX just does the right thing. InstallScope per machine and elevated privileges will make it work. If you accidentally turn it into a per user install by messing with ALLUSERS then it will not be elevated and it will fail.
You should be seeing a UAC elevation dialog after the UI sequence. If you are not seeing this dialog then the install will not be elevated. Again, that might be related to you changing ALLUSERS. If you are installing this in silent mode then it will also fail because silent really does mean silent, and it will not show the elevation dialog and your CA will not run elevated.
It's possible that your failing custom action is not the one you posted, which is deferred and therefore after the elevation prompt. If you have a custom action in the UI sequence then it will not be elevated (unless you run the MSI from an elevated prompt) so that may explain the issue you are seeing.
Related
I have a Wix project I'm modifying. It has to be installed for All Users and write to HKLM. So, in the Package I have:
<Package Id="*" InstallerVersion="405" Compressed="yes" InstallScope="perMachine"
InstallPrivileges="elevated"
Manufacturer="$(var.Publisher)"
Description="$(var.ProductName) $(var.Version) Setup" />
I also have other checks that may be working or not...
Stuff like:
<CustomAction Id='IsPrivileged' Error='You must be an admin to install this product' />
<InstallExecuteSequence>
<Custom Action='IsPrivileged' Before='AppSearch'>Not Privileged</Custom>
</InstallExecuteSequence>
What little I had, ensure that when installing or uninstalling, it would need to elevate. However, people also want to modify ... and that's when it I encountered problems.
WHen I took over, the installer had the ARPNOMODIFY set to disable modifying. Since it would be nice to be able to modify, I commented out that line:
<!--<Property Id="ARPNOMODIFY" Value="yes" Secure="yes" />-->
So, now I can "Modify" or "Change" it depending on whether it's done from the Remove Programs UI in Windows or by running the installer again.
However, it doesn't work at all. Registry entries get erased, and when run that way I never get a UAC prompt. It just tries to run the installer.
I've been at it a long time and can't figure a way to get the Modify/Change to elevate. It just goes ahead and tries to run and messes everything up. ISTM that it should ask to elevate before beginning the InstallExecute sequence, but it never does.
How can I get it to elevate or require admin privileges?
I'd prefer to find a way to elevate, but in lieu of that, I'd be happy if it was blocked from continuing. But it just wants to run and hose my installation.
You can block a repair/modify from the ARP by conditioning off the MSI property RestrictedUserControl=1. If this property is set, it means that the installer is being executed 'without' admin privileges.
I have a installer which asks the user to select feature. Whatever user selects, it will never be changed in case of modify and upgrade the installation. For example:
There are three features in my installer which are below:
<Feature Id="Standalone" Title="Standalone" Level="2">
</Feature>
<Feature Id="CentralCase" Title="Central case" Level="2" >
</Feature>
<Feature Id="MiddleEF" Title="Middle Ef" Level="2" Display="expand">
<Feature Id="GUI" Title="Client" Level="3"></Feature>
<Feature Id="AppServer" Title="Application Server" Level="3">
</Feature>
</Feature>
Now suppose user starts the installation and select the first feature which is standalone and install it. Now if user wants to modify, he should not allowed to change feature or even if user wants to upgrade, user should also not allowed to change feature. He can only upgrade what he selected at first time. Is there any way to do this?
ARPNOMODIFY: I guess it depends how critical it is that these features never change. You can set the ARPNOMODIFY in the MSI to
1 and there will be no button to invoke Modify from:
<Property Id="ARPNOMODIFY" Value="1" Secure="yes" />
Disclaimer below. Here be dragons.
msiexec.exe: However, you can still invoke modify by launching the MSI file itself (the default dialog sets should correctly disable the modify button though), but worse: you can go via the msiexec.exe command line and change anything you want:
msiexec /i "MySetup.msi" ADDLOCAL=MyFeature
This might be OK since it would appear to be seldomly used. However, you should be aware that remote management systems often rely on the msiexec.exe command line to handle MSI deployment, and as such the deployment system could be used to change feature state easily (via the deployment tool GUI, no command lines to deal with).
Custom Action: I don't know of an auto-magic way to abort setup if the user tries to modify the feature structure invoked via the msiexec.exe command line, but I suppose you can use a custom action maybe right before InstallInitialize in the InstallExecuteSequence to abort the installation if ADDLOCAL, REMOVE or ADVERTISE are set? If you do not condition this custom action properly, it could cause a package that won't uninstall at all or upgrade properly.
Some unverified conditioning suggestions: How to execute conditional custom action on install and modify only?
MigrateFeatureStates: For a major upgrade the GUI will not run as if it is running modify, but a fresh installation (since the product GUID is new). Hence the original installation GUI is shown and not the modify one. Accordingly you might need to disable some GUI controls or hide whole dialogs to prevent feature selection (not sure in WiX default dialogs). Added a link for that below. The standard action MigrateFeatureStates will take care of preserving the feature installation states between versions, provided you haven't done anything drastic to the feature structure. You enable this standard action to run in the Upgrade table. Should be default to run in WiX MSIs I think.
UPDATE:
Preselected Property: There is a special property called Preselected that is to automatically hide feature selection. You can try to set it or check whether it is set automatically by WiX to see if it hides feature selection. I have honestly never tried it.
Some Further Resources:
Hiding whole dialogs: Wix, custom dialog when previous version exists
I'm trying to create an installer that supports perUser and perMachine installations dependent on a selection of setup types on the UI.
The perUser setup type installs the application into "WIX_DIR_COMMON_DOCUMENTS" and shall require no admin permissions.
The perMachine setup type install the application into "ProgramFilesFolder" and shall request an UAC dialog.
My attempt was to initially set the Package/#InstallScope to perUser and then modify the ALLUSERS property later on.
If the user selects the perMachine setup type I'm trying to set the ALLUSERS property to 1 doing the following:
<Publish Property="ALLUSERS" Value="1">1</Publish>
The "Install" buttons gets an UAC icon, but no UAC dialog appears after I pressed it!
Instead I get an error message that I obviously have no privileges to install the application for all users of the machine.
Is it a bug that no UAC dialog appears or intended? Am I missing something?
Someone from the WiX Mailing list pointed me to the Single Package Authoring article on msdn.
I had to initialize the following properties:
<Property Id='ALLUSERS' Value='2' />
<Property Id='MSIINSTALLPERUSER' Value='1' />
and set the 'MSIINSTALLPERUSER' property to an empty string for a per-Machine installation.
<Publish Property="MSIINSTALLPERUSER" Value="{}">1</Publish>
Be aware that this only works for Windows Installer 5 and higher!
I have an MSI built via WiX, it's per-user and doesn't display the UAC prompt if the user has rights to the destination folder. However, if the destination folder is in Program Files, it errors with "Insuficient privileges".
How can I show a UAC prompt in the case the destination folder is not writable?
It doesn't really work that way. Per User installs should never require elevation and should never write to Program Files as that's a per machine location. Instead it should install to %LocalAppData%\Programs\Company\Product.
Read the following for a lot more background information. Parts apply and parts may be beyond scope ( dual per-user / per-machine requirements ):
Authoring a single package for Per-User or Per-Machine Installation context in Windows 7
I know this is an old thread, but I want to let others who come across it that it is indeed possible.
As was mentioned in the previous answer, conventional per-user installs should not require admin rights. However, I came across a perfectly valid situation where I needed to run a custom action which required admin rights. Requiring my users to launch the MSI with msiexec from a command line with elevated privileges did not seem like an acceptable solution.
It doesn't seem like this should be so difficult, but luckily I stumbled onto the answer in this post: The Package/#InstallScope attribute doesn’t support per-user, elevated packages! So just omit it in your Package definition:
<!-- NOTE: If you need to create a per-user installation (meaning it's not -->
<!-- visible in Add/Remove Programs from other logons) that prompts for -->
<!-- elevation, omit both the Package/#InstallPrivileges="elevated" and
<!-- Package/#InstallScope="perUser". -->
<Package InstallerVersion="200" Compressed="yes" />
Don't forget to leave ALLUSERS undefined, as well. I described this further on my blog:
How to Elevate a Per User Installer Using WiX
Our product was installed via InstallShield Setup over the years. I changed the installation to MSI (WiX) this year. Now the MSI should clean up the directory, which remains the same.
One custom action in the MSI I implemented to start the uninstallation of the old product:
<CustomAction Id="UninstallIS" Property="QtExecCA" Value=""[WindowsFolder]IsUn0407.exe" -f "[ProgramFilesFolder]\company\product\Uninst.isu"" Execute="deferred" />
<CustomAction Id="QtExecCA" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="ignore" Impersonate="no" />
After the removal of the old product there are temporary files and some subdirectories that are different from client to client and are unknown to the InstallShield Setup, so I would try to delete them via the MSI.
Keeping the UAC in mind, I think that I can't use command-line commands to do this also the 'Remove File Table' is not useful here (to much unknown files and many directories).
What is a possible way to do this?
Thank You for any help!
You can use a Deferred custom action which has Impersonate flag set to "no". This way it will run under the local system account with full privileges.
The custom action can use custom code (for example an EXE or DLL) or a command line.
Please note that deferred custom actions can be scheduled only after InstallInitialize action in InstallExecuteSequence.
As a side-note, make sure you thoroughly test it. Deleting files from the target machine is very dangerous. You never know what you may end up deleting.