Hello everyone --

Based on feedback we have received from recent customer engagements, webcasts and the blog, we plan to have several KB articles created to clear up some points about Windows Installer 4.0 on Windows Vista. Since the KB creation process can take some time, I wanted to post a summary of the information to be included in the KB articles here to the blog. Please provide comments if you have any questions or thoughts!

KB Title: Signed Windows Installer (MSI) packages display unsigned UAC dialog during uninstall on Windows Vista.

Summary: Software developers and end-users should be aware that signed Windows Installer (MSI) packages will display the unsigned UAC consent dialog on subsequent operations that require a response to the UAC consent dialog, such as uninstall.

More Information: Because of the way that Windows Installer caches packages for future transactions, the certificate on the package becomes invalid. This results in the unsigned UAC consent dialog being displayed on subsequent operations that do not have access to the original package, such as uninstall


KB Title: Custom Action code that is not NX compliant will not run on Windows Vista.

Summary: Software developers should be aware that starting with Vista, msiexec.exe is NXCOMPAT. (i.e., it is compiled with the /NXCOMPAT switch.) This ensures that non-executable code is not run by msiexec.exe. Msiexec.exe is the image for Windows Installer service, a Windows Installer client and any custom action sand-box processes. What this means is that any custom code that is not NX compliant would not be run and would result in a forceful shutdown by the Vista NX sub-system.

More Information: If your Windows Installer (MSI) package use libraries that are not NX compatible, then they might not work on your Vista systems. It is recommended that you recompile your setups using the new NX compatible libraries. Older versions of ATL (pre-Visual C++ 8.0) are known to be not NX-Compatible. Using ATL shipped with Visual C++ 8.0 is NX compliant.


KB Title: Windows Installer (MSI) packages only have access to the specific privileges of the Windows Installer service on Windows Vista.

Summary: Software developers should be aware that, starting with Windows Vista, the Windows Installer service only has privileges required for software installation. Custom actions that require additional privileges will fail.

More Information: The Windows Installer service has the following specific privileges: SeTcbPrivilege,SeCreatePagefilePrivilege,SeLockMemoryPrivilege,SeIncreaseBasePriorityPrivilege,SeCreatePermanentPrivilege,SeAuditPrivilege,SeSecurityPrivilege,SeChangeNotifyPrivilege,SeProfileSingleProcessPrivilege,SeImpersonatePrivilege,SeCreateGlobalPrivilege,SeAssignPrimaryTokenPrivilege,SeRestorePrivilege,SeIncreaseQuotaPrivilege,SeShutdownPrivilege,SeTakeOwnershipPrivilege,SeLoadDriverPrivilege. Since Custom Actions inherit the same privileges of the Windows Installer service, custom actions will have only these privileges, even when running in an elevated context. If your application installation requires configuration that requires other privileges, it can not be done though a Custom Action.


KB Title: Pending OS updates may cause unexpected failures in Windows Installer (MSI)-based installations on Windows Vista.

Summary: Software developers should be aware that changes in Windows Vista may result in Windows Installer (MSI)-based installations that are dependent on assemblies for commit-type custom actions may fail when there are pending OS updates requiring a reboot. The machine should be rebooted to complete the OS update process and the installation should be tried again.

More Information: Due to a change in the way Windows Vista handles pending operations, assemblies installed by Windows Installer may not be available for commit-type custom actions if OS updates have been installed that require the system to be rebooted to complete the operation. If your installation in dependent on assemblies and you are seeing 1031 Application Event Log messages on the failure, then the failure is likely due to this change. Rebooting the machine to complete the pending OS update operation and then running the application installer again will rectify the failure. Software developers can also use the new MsiSystemRebootPending property to ensure that there are no pending reboots before their installer is run.


[Author: Tyler Robinson]
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.