WIX: Sleep between Custom Actions during installation

If you require to pause your installation between some custom actions, you can use the following:

<Property Id="QtExecDeferred" Value='"ping" -n 15 127.0.0.1'/><CustomAction Id="QtExecDeferred" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" Impersonate="no"/>

The QtExec allows to run command line silently.

WIX: How to run Command Line silently

WIX provides a Custom Action that allows to run Command line silently - Quiet Execution Custom Action

You should use it exactly the same way as listed in the WIX example. Just put your command in the Properties value.


<Property Id="QtExecCmdLine" Value='"command" parameters'/><CustomAction Id="QtExecExample" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="immediate" Return="check"/>

Make sure the command has double quotes. For example: '"ping" -n 15 127.0.0.1'

Don't forget to add the WixUtilExtension extension during building the msi package.

UAC prevents execution of custom actions during msi installation

In the previous post there was a link to the Robert Flaming's blog where he describes how MSI works with UAC. But I have some additional comments and want write them here:

In the following post Robert describes how permissions change under UAC:

• the Violet region runs as Standard User
• the Orange region runs as Standard User
• the Teal region
  • Standard Actions run as with the needed permissions
  • Custom Actions run as Standard User unless the NoImpersonate bit is flipped.

But what does the NoImpersonate bit means? There are different explanations in different articles. Based on my testing I've found out the following:

When you set Impersonate="no" in WIX for you custom action, it means that the custom action will be executed under the Local System account. And it is fine if you need to do changes with your local system. But if your custom action accesses a remote server it fails.

So, the only way that I've found is to prohibit the msi execution under unprivileged user. You should set the MSIUSEREALADMINDETECTION property to 1 and add a Launch Condition for Privileged that gives an error message about running via an elevated command prompt and then quits the installation.

<Property Id="MSIUSEREALADMINDETECTION" Value="1" />




<Condition Message="The installation should be running with full administrative account. Please run an administrative command prompt and launch installation using msiexec.">

Privileged

</Condition>

MSI and UAC

The very useful blog

Content is the following:

1. Introduce...
   1. ...the UAC in MSI Notes series
   2. ...my view of the root problem
   3. ...the conflicting per-user definition
   4. ...it'll be just like Managed Installs
   5. ...the jagged edge to user
   6. ...my relief providing framework
2. Architecture Insights
   1. The "Saw Tooth" Diagram
   2. Credential Prompt and Permissions
3. Common Package Mistakes
   1. The AdminUser Mistake
   2. Modify System with InstallUISequence Custom Action
   3. Modify System with InstallExecuteSequence Custom Action Outside of Script
   4. The NoImpersonate Bit Mistake
4. More Architectural Insights
   1. My "Four Square" Diagram
   2. Challenges for a Beautiful Custom Action
   3. O Whitepaper, Where Art Thou?
   4. Read the Friendly Manual
5. Conversations with Customers
   1. Should I write my installer as a Standard User install? If yes, how?
   2. When General Custom Action Mitigation Fails
   3. How do I get the shield on the advertised shortcut?
   4. How do I troubleshoot UAC in MSI via the log?
   5. Do I need to consider "this" when I'm designing for UAC in MSI? Generally, no.
   6. Is "this" intentional? If so, why?
   7. How to Build Packages that work for both Standard User and Per-Machine?
   8. Easier for my current custom installer to support UAC than switch to MSI?
   9. How do I get one credential dialog for a multiple package install?
   10. What are the Hurdles in Windows Vista Logo compliance related to UAC and MSI?

Installation hangs on "please wait while the installer finishes determining your disk space requirements"

By a some reason installation may hang on a dialogue with the "Please wait while the installer finishes determining your disk space requirements" message (1, 2)

To solve the issue one of the following solutions may help:

• Stop the installation and start it again.
• Start installation from command line with /qr switch (i.e. msiexec /i {name.msi} /qr). (qr swtitch - no interaction with user in dialogue wondows)
• Move msi to a folder with shorter path and run it from there.

What can be done in the msi project:
Remove SpawnWaitDialog event with CostingComplete = 1 condition
CostFinalize does not work

Reduce software installation time

In MSI 5 there’s a new property MSIFASTINSTALL that can be set on the command line or in the Property table to speed up large install packages. It’s a combination of flags that will avoid creation of a system restore point, skip some costing tasks, reduce the frequency of progress messages, or any combination of these.
http://www.verboon.info/index.php/2009/07/reduce-software-installation-time/

Reboot request on Windows 2008 during msi uninstall

During uninstalling application, the following message may appear:

"The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup."

However, there is no need for reboot as all services are stopped before removing any files.

To suppress reboot request, set the REBOOT property to ReallySuppress

msi limitation - 1600 components per feature

msi has the follwoing limitation: 1600 components per feature:

http://msdn.microsoft.com/en-us/library/aa368579(VS.85).aspx

But why?

http://www.appdeploy.com/messageboards/printable.asp?m=20038

http://blogs.msdn.com/icumove/archive/2009/05/31/right-corner-wix-heat-left-corner-thousands-of-files.aspx

Installation process

Excellent article: How Windows Installer installs msi

When we launch Windows Installer engine (by running msiexec.exe) we are launching the client process. Client process will launch the Windows service process.

Log investigation is always helpfull. Read about logs here. The article contains link to a document where log file is explained in more details. Here the link for the document (Annotated_Windows_Installer_Log)

Upd:

one more article about installation phases

how to read Windows Installer Verbose log article

custom actions article

Inside msi

About msi itself:

Windows installer (MSDN)

To understand reboot requests after installation:

Insights into the underlying Windows Installer reboot behavior

WIX - first steps

WIX tutorial

From MSI to WiX (Alex Shevchuk's blog)

Article in MSDN magazine