I am working for a customer helping them write a patch for their basic MSI setup. Their application resides on a closed system.
It is desirable on this system if the patch should fail to upgrade the system and a rollback occur, that the application should restart OR a reboot should occur which will have the same affect.
Is there a way to handle this? REBOOT = Force does not work in a rollback scenario. I guess I could set the App.EXE to launch as a Rollback custom action, and set the condition as "Installed" but I am not sure where in the sequence I should place it so it executes properly - for instance I want to make sure that all of the files, the database, registry settings, and other settings are rolled back properly before launching the application. So do I sequence this just before InstallInitialize? There is no documentation on this type of process that I could find and I don't want to be just guessing.
😄 It appears that I answered my own question in the writing thereof.
By writing a rollback custom action, I can successfully launch the application in a rollback scenario. Just make sure you select the asyncronous option and ignore the exit code so the installer can finish up and sequence the action just after InstallInitialize.
So to summarize: [LIST=1]
Create a new Executable custom action, one that is installed with the product.
Select the product key for the application to launch.
Configure the command line to the executable name plus any extra command line options that are required if needed.
Set the Return processing to Asynchronous (No wait for completion)
Set the In-Script Execution Scheduling to Rollback Execution in System Context.
Finally set the Install Exec Sequence to After InstallInitialize and the conditions for install to "Installed" or whatever other conditions you may want this to run under.
One thing to watch out for is running the custom action in system context. Unless this process normally runs in the SYSTEM account (such as a service, but even services tend to run with less privileges than LocalSystem these days), this may not be desirable as this would give the application the same privileges as the operating system. If there are any security issues with the application, having it run in system context could result in arbitrary code being able to run with system privileges. If this application doesn't have any need to run with elevated privileges, the custom action should just be run as a normal rollback action.
Good point Josh. In our case since we are on a closed system and it is a known environment this is not a problem but for the sake of others that may follow these steps your are absolutely correct, change this to a normal rollback execution instead of one in system context.
