I have a client application for tracking user status ("Gone for the day", "Out to lunch", etc.) that needs to be started as part of its installation process. I have set up a wix installer to handle the installation and in particular a CustomAction to launch the application once the installation is complete. Below is the xml
<CustomAction Id="Launch_StatusTracker" FileKey="StatusTracker" ExeCommand=""
Return="asyncNoWait" />
<InstallExecuteSequence>
<Custom Action="Launch_StatusTracker" After="InstallFinalize">NOT Installed</Custom>
<Custom Action="WixCloseApplications" Before="InstallInitialize">Installed</Custom>
</InstallExecuteSequence>
The code above executes just fine when I manually run the generated msi on my machine. It installs the application and then starts it up. However, when the application is installed using an SCCM 2012 Application the program is installed but it does not startup. Here is the warning message that I see in the Windows Event Viewer:
Application 'C:\Program Files\StatusTracker\StatusTracker.exe' (pid 7216) cannot be restarted - Application
SID does not match Conductor SID.
I've looked online for this type of error but I haven't been able to find anything about it that relates to SCCM. As an alternative I tried to have it run a batch file instead that will startup the program but that will not work for me because I need the program to run in the context of the current user.
What context is SCCM running the installer in? Typically it's SYSTEM and that's probably causing problems trying to start the process in the interactive user context. I used to have some tricks to get around this but they are all hacks. You may just have to take a reboot and have it start on next logon.
You can use PSEXEC to launch a command prompt as SYSTEM. Test the install silent in that context to mimic SCCM behavior.
Related
I have an Excel Add-in that uses a Wix (3.10) install script. The installation works fine. However, if the user tries to remove the add-in through System | Apps & Features, it fails with "There is a problem with this Windows Installer package. A program required for this install to complete could not be run." Looking at the uninstall log, I see this:
Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: _BDF865EC_34B3_4B29_986C_98D6EC1A9807, location: C:\Windows\Installer\MSI2FE4.tmp, command: /uninstall="C:\Users\Windows10\AppData\Local\myCompany\myProduct\myAddin.dll" /privileges=user
The action that it is balking at is this:
<CustomAction Id="_BDF865EC_34B3_4B29_986C_98D6EC1A9807" BinaryKey="adxregistrator_exe" Execute="deferred" ExeCommand='/uninstall="[TARGETDIR]$(var.myProject.TargetFileName)" /privileges=user' Impersonate="yes" />
However, if I re-run my installer and select 'Remove', it uninstalls fine. Also, If I run the uninstall from a command line (using the msiexec command found in the registry entry for this product), it also uninstalls fine.
Also:
This only happens in Windows 10. Older versions of Windows are fine.
I have replicated on several machines, including a fresh install.
I have an older installer (a VS2010 Setup Project), the problem happens with that installer as well.
I have tried with UAC at different elevations, no difference.
I have seen other posts here about changing the Impersonate setting to "no", no difference.
It seems to me that there is a problem with the new Windows Apps & Features app, but I have yet to find anything on the Microsoft forums.
Update:
A Wix user posted this: DTF Bug with new Windows 10 Apps and Features. Also, we have tried a variety of commands (thinking it was a UAC issue), none of them work, even 'built-in' Windows commands fail.
I have run into the same issue and finally came with this solution:
Win 10 Apps & Features uninstaller checks for the WindowsInstaller registry value and behaves correctly when this value is not present
1) Define the custom action
<CustomAction Id="DeleteWindowsInstallerValue" Return="ignore" Directory="TARGETDIR" Execute="deferred" Impersonate="no"
ExeCommand= "reg.exe DELETE HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode] /v WindowsInstaller /f" />
2) schedule the action in the InstallExecuteSequence
<Custom Action="DeleteWindowsInstallerValue" Before="InstallFinalize"/>
Honza
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 have a WIX install program.
When I test my install program on a machine where the old version of the software is running, I get the prompt below.
The problem is that the installer can't manage to close the application. When the new program runs, it complains about the old one running.
Is there a way to forcefully kill the app?
If not, is there some entry in WIX that will require the user to shutdown the application before it will continue installation?
I found the answer here:
WiX <util:CloseApplication> element not working
I made one tweak to the solution in the post above. I kill the application earlier in the install sequence so the window above doesn't appear.
<!-- Code to force termination of running program...MSIExec couldn't do it -->
<Property Id="QtExecCmdLine" Value='"[WindowsFolder]\System32\taskkill.exe" /F /IM "$(var.ProductName).exe"'/>
<CustomAction Id="APP.TaskClose" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="immediate" Return="ignore"/>
<InstallExecuteSequence>
<Custom Action="APP.TaskClose" After="LaunchConditions"/>
</InstallExecuteSequence>
If you are wondering what "$(var.ProductName).exe" is, I pass the exe name on the commandline because I'm creating several branded versions of the same program. Just substitute your exe name.
And yes, it is safe in this particular intance to do this. There is no data held in memory that could be lost.
You should use the WiX util extension CloseApplication:
http://wixtoolset.org/documentation/manual/v3/xsd/util/closeapplication.html
That should work.
Long term you should get the app integrated with Restart Manager so it will shut down automatically.
I'm launching a custom action console application that can return 0 or -1.
On Windows 8 when it returns 0, the install continues.
On Windows 7 when it returns 0, the install ends prematurely.
<Property Id="QtExecCmdLine" Value=""$(var.SourceFiles)\MyProgram.exe""/>
<CustomAction Id="CheckForOld" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="immediate" Return="check"/>
<InstallExecuteSequence>
<Custom Action="CheckForOld" After="AppSearch" />
</InstallExecuteSequence>
Does anyone know what can be done to resolve this?
What are the UAC levels/settings on the Windows 8 and Window 7 machines? If you have UAC disabled on your dev machine but enabled (default setting) on the test Win 7 you could get the EXE failing to run as a custom action.
In this case I also recommend migrating your code to a DLL, you could write a C# DLL, using WixToolset and DTF.
The DLL can then set a property with the result of this search, and you can use that property to define a new launch condition to stop the installation, if required.
From Tao of the Windows Installer, Part 5
Rule 53: Test thoroughly It is crucial that you test your packages thoroughly before deployment. A classic mistake is for
developers and package authors to test only on their own systems where
they have full administrator rights and then discover that normal
users cannot use their applications.
Is that a QT exe file? What is the EXE file doing / checking? What happens if you turn off error checking - does it run and perform its task?
I wouldn't recommend to run a custom action with an exe file if you write the code yourself. Write it as a dll and connect the debugger to the code to step through it using a debug build dll - you will see exactly what happens as you step through the code:
Insert code to show a message box from within the function you want to debug
Compile a debug dll file and insert into the MSI file with the necessary plumbing to hook things up. This isn't entirely trivial, but not that complicated. See link below.
Run the MSI and wait for the message box to show
Attach the debugger to the correct msiexec.exe - either the user context one or the system context one depending on how your custom action is sequenced
Set breakpoints and step through the code to determine what is happening
How to create a basic MSI dll:
http://www.codeproject.com/Articles/1747/MSI-Custom-Action-DLL
What is this EXE supposed to do? There are several code smells. First is that it's scheduled in the UI sequence only. It won't get run during a silent install. The second is it's an EXE scheduled as immediate. EXE's can't access the MSI handle and set properties or do anything useful so I assume the EXE is changing the configuration of the machine. This is inappropriate outside of the execute sequence transaction. Finally, QtExecCmdLine needs an absolute path to the EXE on the destination machine. I don't see how $(var.SourceFiles) could provide that. That's a preprocessor variable that's only going to tell you where the file exists on the build server.
You aren't testing on your own dev machine? I'm guessing you build this on a Win 8 box and then tested on the same box. It happens to work cause it can find the file. When you run it on another machine (Win 7) it can't find the file and fails because the file can't possibly be there... you haven't installed anything yet.