I'm using WIX to create an MSI which has a custom action to install a clickonce application. I want to deploy the MSI via GPO. The custom action runs fine when I just double click to run the msi, but the custom action does not seems to be running when deployed via GPO. But if you look at the add/remove programs in the control panel you have the product/msi listed there as if it was successfully installed.
To see if custom actions work at all when deploying via GPO I created a simple custom action which just writes a file to c:\temp (existing) folder. Added the custom action to both InstallExecuteSequence and AdminExecuteSequence in before installfinalize step. Tried both deffered execute and immediate execute. It works when you double click the msi to install but not via GPO.
Is it possible to have custom actions when the msi is deployed through GPO? Are there any limitations? Is there anything special that I need to do to get it to work with GPO?
Thanks in advance!
Rukshan
I figured it out. The issue was that I hadn't configured the GPO to install the package when the user logs in. After checking that check box in the group policy properties it works.
If you assign the software to users and do not check "install this application at logon", the application will be listed on the user's add/remove programs panel but doesn't really install it. So I was under the impression that it was successfully installed without running the custom action when it really wasn't installed.
Now I have my custom action listed under Install Execute sequence
<InstallExecuteSequence>
<Custom Before='InstallFinalize' Action='ClickOnceIntallCustomAction' >NOT REMOVE</Custom>
</InstallExecuteSequence>
And it is set to execute immediately and check on return
<CustomAction Id="ClickOnceIntallCustomAction" BinaryKey="ClickOnceInstallBinary" Return="check" Execute="immediate" DllEntry="Test" ></CustomAction>
Related
I am running the .exe file through a CustomAction in Wix. The executable is running but not with admin rights. Seems like i am doing everything correct but not sure what's going wrong. Here is the sample of my Custom Action
<CustomAction Id="RunExe" FileKey="Setup" ExeCommand="-switch" Execute="deferred" Return="check" Impersonate="no"/>
<InstallExecuteSequence>
<Custom Action="RunExe" Before="InstallFinalize">NOT Installed</Custom>
</InstallExecuteSequence>
The actual problem is that this .exe that is executed through ExeCommand is not able to access a registry key(HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders).
Running the msi as administrator solve the problem but i need a solution in which WIX should itself able to run the command as admin or atleast give a prompt to user.
A deferred custom action in a per machine install runs elevated with the system account. It's not clear what you mean by access to the HKCU key, but the HKCU key for an executable running with the system account is the system account's HKCU, not the installing user's HKCU. It would help if you said exactly what you are trying to achieve, because you might not need code at all. The install will update HKCU for the installing user if you use the registry features of WiX/MSI, so this may be a case of not really needing code at all.
It's also unclear why running the MSI as administrator solves the problem because that custom action will already be elevated in a per machine install with InstallPrivileges elevated. There is insufficient info in your post as tp your install context, but my guess is that you might be doing a per user install without InstallPrivileges elevated - that's one situation in which the MSI would run CAs under the installing user's account but they would not be elevated unless you elevate the entire install by doing as you said - runningthe MSI as administrator.
I have created a MSI installer package using Wix Toolset 3.8 that is run by a third party installer service running under the "SYSTEM" account. My issue is that when trying to launch and run an installed executable from my MSI installer using a custom action, it also runs under the SYSTEM account instead of the administrator account that is currently logged in. I have spent hours researching on the net and from what I have read, specifying Impersonate="yes" will run that particular custom action under the account that launched the installer, but there lies the issue. Since the third party installer service is running from the SYSTEM account, specifying Impersonate="yes" would just run the custom action under the SYSTEM account as well correct? At least that's what my tests have shown. A little bit of background on my MSI installer:
InstallScope="perMachine"
<CustomAction Id="StartAction"
Directory="FOLDER"
ExeCommand ='cmd.exe /c start MYEXE.exe /tray'
Execute="immediate"
Impersonate="yes"
Return="check"/>
<InstallExecuteSequence>
<Custom Action='StartAction' Before='InstallFinalize'>NOT Installed</Custom>
</InstallExecuteSequence>
I have tried both "deferred" and "immediate" for Execute as well as setting "Impersonate" to both yes and no. Is there any way to make this work? I thought about using the runas command but I wouldn't know the password of the user account that initiated the install.
Thanks!
What is the EXE file doing? Do you have control of the application so you can move the logic from that external EXE into the main application's launching logic?
Other than that you can register such an EXE file to run once per user via ActiveSetup. You can also find another answer from me here.
Here is one more link to an explanation of ActiveSetup (I prefer the one above): http://www.ewall.org/tech/msi/self-healing
Also see these answer here: Stopping MSI from launching an EXE in the SYSTEM context
I have an installer in WIX. I have tried to deploy it to a group of target computers in the network and encountered the following issue. The deployment was successful but there is an issue when the installer launches the application after the installation finishes using the following code:
<CustomAction Id="RunMainApp" Directory="SUBDIR" ExeCommand="[SUBDIR]clicksharelauncher.exe" Execute="deferred" Return="asyncNoWait"/>
<InstallExecuteSequence>
<Custom Action="RunMainApp" Before="InstallFinalize"><![CDATA[UILevel=5 OR LAUNCH_APP~="YES" AND NOT Installed]]></Custom>
</InstallExecuteSequence>
When the application is launched, I realized that it is launched in SYSTEM user. Therefore, I get an error from the application saying that the application can't run in SYSTEM user. Could anyone tell me if there is a way to fix it?
This is happening because the InstallExecute phase of the installation runs as the SYSTEM account, and you're launching the application during that phase.
You'll need to get the custom action to Impersonate the user executing the installation by adding Impersonate="yes" to the custom action element.
More details can be found under the Impersonate section here:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/customaction.html
The following link provides details on how to add the startup of an application in the UI:
http://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/run_program_after_install.html
I'm very new to WIX and am using the minimal GUI to install and uninstall a dll. This dll gets registered as a service in a custom install script that I am calling upon install.
Upon uninstall, I stop and unregister the service in a custom script.
My problem is, before the custom uninstall script is called, I get the files in use dialog box as the dll is being used by the service. I want to avoid this, as I know I will be stopping the service in the custom uninstall action.
Any easy solutions to this problem ?
Thanks!
Nikhil.
Are you using a Custom Action to stop the service? If so I'd make sure that your custom action is run before the removal of your file
i.e.
<CustomAction Id="StopService" Directory="DirMyService" ExeCommand="NET STOP ServiceName" />
<CustomAction Id="StartService" Directory="DirMyService" ExeCommand="NET START ServiceName" />
<InstallExecuteSequence>
<Custom Action="StopService" After="InstallInitialize">Installed</Custom>
<Custom Action="StartService" Before="InstallFinalize">Installed</Custom>
</InstallExecuteSequence>
Haven't tested this, so you may need to stick in the windir before the net stop etc, and those might be the wrong places to put it in to stop/start the scripts. But might give you an idea of how to solve your problem.
I have a WiX installer project that utilises a custom dialog box to ask for parameters to update a web.config file and run a database script on install. Everything works correctly and the application is installed and runs correctly.
However, the custom dialog box is also displayed when I uninstall the software and it certainly doesn't need to be (as I'm not updating a web.config file).
Is there a way to suppress the custom dialog when the application is being uninstalled?
(I should also remove the sql procs I install, at uninstall time but that is outside of this issue).
The solution to your question is to condition the custom action with the condition (Not REMOVE="ALL"). This will make the action run on fresh install and maintenance install, but not on uninstall. If you don't need to run on maintenance install, but only on a fresh install you can set the condition to be: (Not Installed AND Not(REMOVE="ALL")). Full list of MSI properties and brief descriptions here: http://msdn.microsoft.com/en-us/library/aa370905(VS.85).aspx.
The sequencing and custom action logic in MSI files is VERY complicated. It really pays off to avoid custom actions whenever you can.
There is more - all MSI files have built-in support for silent installation. This means that the entire GUI sequence can be skipped, and the MSI file installed without user interaction. This is a crucial feature for corporate deployment via SMS / SCCM or other deployment mechanisms. Showing a custom dialog box when the setup is run in silent mode is a violation of this basic MSI feature. You can work around this by properly conditioning the display of the dialog based on the property UILevel: http://msdn.microsoft.com/en-us/library/aa372096(VS.85).aspx. Just to keep things interesting and confusing Microsoft has defined 4 levels of GUI during an installation ranging from completely silent, through various options such as progress bar only etc... See the link for details.
I could add a lot of details here about MSI sequences, conditions, custom actions and similar, but it wouldn't answer your question. Please add any follow-up questions.
Wix snippet to show the creation of a custom action and its insertion into the InstallExecuteSequence:
<!--Custom Action Sample Section-->
<Binary Id='VBScriptCustomAction.vbs' SourceFile='VBScriptCustomAction.vbs'/>
<CustomAction Id='test' BinaryKey='VBScriptCustomAction.vbs' VBScriptCall='Hello' Return='ignore'/>
<InstallExecuteSequence>
<Custom Action="test" Sequence='4111'><![CDATA[NOT REMOVE~="ALL"]]></Custom>
</InstallExecuteSequence>
<!-- End of Custom Action Sample Section-->