Windows Installer Team Blog : Frequently Asked Questions

What changed in Windows Installer (MSI) in Windows Vista Service Pack 1?

Windows Installer Team — Wed, 30 Apr 2008 01:53:00 GMT

Stefan Krueger met with us a few weeks ago for the Microsoft MVP Global Summit. Among the many topics we discussed was a suggestion from Stefan that we use the team’s blog to communicate relevant bug fixes that we make in our releases. This posting is the result of that suggestion. (Thanks, Stefan!)

Windows Vista Service Pack 1 was recently released and you may have noticed that the version of MSI on the system has incremented to 4.0.6001.18000. Below you will find a list of the most important issues that we addressed in Service Pack 1 and the SDK.

Updates that can be found in Windows Vista Service Pack 1:

· User Shortcuts in Redirected Start Menu Do Not Get Removed On App Uninstall

If you attempt to uninstall an application that was installed for a roaming user, you may receive error 1910 and the shortcuts from the start menu will not get removed.

· Win32_product does not work on vista when more than one per-user application is installed

Queries to the Win32_Product WMI class will fail if the machine has at least 2 per-user applications installed with a generic failure error.

Updates that can be found in the Windows SDK for Windows Server 2008:

· PatchWiz 4.0 ignores the IgnoreMissingSrcFile property

This property in the TargetImages Table is often used to reduce the time necessary to generate a patch, but the property was ignored in patchwiz 4.0 that was included in the Windows Vista SDK.

· Patchwiz 4.0 does not recreate the Patch table if dropped

Previous versions of patchwiz would automatically recreate critical tables (eg: Patch, PatchPackage) if they were dropped in the patch. Patchwiz 4.0 did not include this behavior, which caused failures in some cases.

· PatchWiz 4.0 does not support authoring of OptimizeCA MsiPatchMetadata property

The OptimizeCA property can be included in the MsiPatchMetadata of a MSP to restrict custom action usage and improve performance during patch application. Using this property with patchwiz 4.0 caused a build failure.

· PatchWiz 4.0 is unable to build patch for products with large number of files (>32767)

Previous versions of patchwiz supported building patches with a large number of files, but patchwiz 4.0 did not.

· Orca crashes when a transform is generated and a row is deleted from the current table

Orca crashes if the user attempts to generate a new transform and deletes a row from an existing table. (Using Orca, select New Transform, then delete a row from a table).

· ICE30 does not display all ICE errors

ICE30 only detects a subset of the total number of SFN/LFN collisions for components that contain files.

[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.

Request for suggestions for updating the 1603 KB article?

Windows Installer Team — Fri, 18 Jan 2008 23:09:00 GMT

Feedback on our existing Knowledge Base article for the error 1603 is that 'it is not very useful.'

My first thought to update the KB would be to go over the troubleshooting techniques such as verbose logging and then how to find and read the errors in the log.

Before proceeding to writing, I thought I'd check-in with the Windows Installer community via this blog.

Are there things besides troubleshooting info you would recommend get covered in the 1603 KB?

Thanks for your consideration.

[Author: Robert Flaming]
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.

Tips to find Windows Installer specific product support

Windows Installer Team — Thu, 03 Jan 2008 23:22:00 GMT

Customers have mentioned having trouble finding Windows Installer support when they try to navigate the maze of Microsoft support offerings.

If you too need to find Windows Installer specific product support, the support staff dedicated to Windows Installer can be reached by

For non-Premier Service accounts, see the Professional Support site

Choose an option from the "Developer" row
Mention key words "Windows Installer", "MSI", and "Development"

For Premier Service accounts, contact your Technical Account Manager

Windows Installer product support services are provided by a dedicated team of specialists inside the larger Microsoft support organization.

If you stump these specialists with a difficult or rare issue, they have an escalation path into the Windows product group.

Integration Hurdles for EXE Custom Actions

Windows Installer Team — Sat, 20 Oct 2007 17:35:00 GMT

A while back, two sets of engineers were arguing whether simply calling an EXE custom action would be good enough for Windows Installer based package. The first team with the EXE didn't want to do the work to move to Windows Installer but they really wanted the second team to take a dependency. The team based on Windows Installer said the integration problems with calling an EXE was so great they would not integrate without a Windows Installer package.

As an attempt at arbitrating the disagreement, it was requested the Window Installer team provide an analysis. A quick paper was written to capture the analysis. This paper has since been shared in other similar circumstances.

In a recent instance, Microsoft blogger Aaron Stebner suggested this quick paper would make a good blog. Here it is. Hope it's useful ;^)

Integration Hurdles for EXE Custom Actions

Overview and Scope

Windows Installer (MSI) architecture was designed to work best when all the installation behaviors are native to the Windows Installer. When the native behavior (called Standard Actions) are insufficient, there is a way to provide extend behavior (called Custom Actions). Custom Actions come in various base types that are differentiated on the way the Windows Installer service instantiates the custom action in the appropriate sandbox. Among the types of custom actions are executable files and dynamic link libraries.

Bare custom actions are risky to the integrity of a Windows Installer base install and this document will consider the risks.

This document will not dive deep into the architecture or the possibilities to improve the custom action architecture in the future.

Integration Hurdles

The installation integrity risk running EXE custom actions come in a number of varieties

Problem	Description	Mitigation (by consumer of EXE)
Crash	Bad EXEs can bring down the custom action sandbox	None
Binary Dependency	Bad EXEs can require technologies that are not in the system at the time of the install. Specific instance: MSXML custom actions required MFC 7 but it didn't exist on machines.	None
Load	Bad EXEs can expect to load DLLs from the path but the path could be customized by the user on the machine.	None
Rights	Bad EXEs can require more rights (e.g. admin) than the package thus breaking scenarios (per-user)	None
Logging	EXEs do not have access to the Windows Installer Log so there is no integrated troubleshooting.	None (best effort, build DLL that provides log path to EXE and puts the log next to or into the Windows Installer log)
UI	EXE do not have access to the UILevel so they do not know whether it's OK to display UI.	None (best effort, build DLL that reads UILevel and alters command line)
Progress	EXEs do not have access to the widows installer progress bar.	None (best effort, add entries to the ReserveCost table)
Hangs	EXE may hang and neither the Windows Installer nor the user has no way of knowing whether the install is hung or just taking a long time.	None (best effort, build DLL that calls CreateProcess and WaitForMultipleObjects)
Costing	EXE do not have any way of being integrated into the Windows Installer costing	None (best effort, build DLL that add ticks to the progress bar)
Rollback - rollback behavior - decision when to execute rollback (did failure occur in the FWD case thus calling the Backward case is extraneous?)	Bad EXE do not support rollback.	None (best effort, build DLL that calls EXE uninstall if exists)
Transparency and Predictability	EXEs are not data driven from the contents of the MSI thus are not transparent to users, especially admins.	None
Uninstall	Bad EXEs do not support uninstall	None (best effort, build DLL that calls EXE uninstall if exists)
Uninstall Rollback	Bad EXEs do not support uninstall rollback	None (best effort, build DLL that calls EXE install)
Repair/Resiliency	Bad EXEs do not support repair	None (best effort, build DLL that calls EXE install again)
First Run	Bad EXEs mix per machine installation with per-user installation that should be invoked at first run	None
Error Codes	Bad EXEs do not provide return codes or have return codes that do not match the custom action return code expectations.	None (best effort, best effort, build DLL that interprets errors returned from the EXE and returns the appropriate value)
Watson	EXE failures are difficult to map to Watson buckets (for teams that have implemented Setup Watson)	None (best effort, build DLL that initializes Setup Watson with the needed context to differentiate EXE error)
PSS Costs	When an EXE fails, the supports costs are absorbed by the enclosing product	None (best effort, build DLL that records needed context to differentiate EXE error)
Localization	Does installation or manipulation by the EXE cause strings to be written to the system? If yes, how are the strings differentiated?	None
Selection	Some EXEs have different levels that can be installed (Minimum, Full).	None (best effort, build DLL that maps UI or feature selection to different levels in EXE)
Terminal Server and SMS	Bad EXEs do not run correctly on Terminal Server where there is no user logged in and will not have a user hive	None
Group Policy (Publishing, assignment)	<missing this context>	None
Debugging	There is no way to debug custom actions in EXE from MSI.	None (best effort, build DLL that uses dll debugging then alter EXE call from inside DLL)
Access to Database	EXEs are unable to access the database	None (best effort, build DLL that uses dll method to access the database)
Run From Source or Cache	EXEs are unable to be configured to run from source	None
Servicing	EXEs are more difficult to confirm they contain the right security fixes when servicing	None
Help	EXEs that contain 2.0 User Education integration may not have MSI's namespace parents configured at the time they are called	None (best effort, move the EXE to a different location in the sequence after the html help custom actions)
Events	EXEs that produce events during install will appear outside the MSI context	None
Customization	Numerous third party tools exist to customize an install to the needs of a particular specialized user (usually LORGs)	None
File In Use	There is no way for a custom action to inform the user that files they want to manipulate are in use	None
Pending File Renames, File in Use, and Rollback	If a EXE custom action replaces files that are held in use and a MoveFileEx causes those files to end up in Pending File Renames, then the install rolls back it's possible that the files will still be changed on the next boot.	None
Detection of When to Install (Resiliency v Rollback)	A rollback during repair or reinstall could cause premature removal of a EXE install that existed on the machine before MSI was installed. If one implements rollback, one has to implement foolproof detection for existing installs of the component and not run the EXE package if the same version of EXE is already on the machine. Otherwise, a cancel or failure in the MSI could cause a preexisting installation of the EXE component to be removed.	None
Reboot	If the EXE requires a reboot, there is no way to communicate the need for the REBOOT to the MSI	None
Cancel	As EXEs can not call MsiProcessMessage, they are unable to respond to the cancel button.	None (best effort, build DLL that calls MsiProcessMessage)
Watson	EXEs that crash may cause a Watson dialog during the install	None

Test Scenarios

When testing the MSI that contains this EXE, one needs to test the following

Deployment technologies

Group Policy Software Distribution

Publishing
Assignment

SMS deployment
Install from network share/media
Install from local cache
Hard drive imaging

Customer segments

Retail install
OEM pre-install
Enterprise deployment

User types

No user (install during winlogon, install by SMS agent) - these will not have a user hive
Lockdown user
Regular user
LUA without registry virtualization
Admin user

What happened to Windows Installer 4.1?

Windows Installer Team — Mon, 01 Oct 2007 17:29:00 GMT

For a time, there was a release named Windows Installer 4.1 on the MSDN topic Released Versions of Windows Installer that was associated with Windows Vista SP1 and Windows Server 2008. When this reference to 4.1 was removed, it naturally lead to the question: what happened to Windows Installer 4.1?

The back story here starts about this time last year when we were finishing up Windows Installer 4.0 in Windows Vista and asking ourselves "What's next?". At that time, we didn't know the bar for features in Windows Vista SP1 and next major release of Windows. For those of you watching Microsoft closely at the time, you may recall this is when there was a lot of change going on in the upper echelons of Windows

The old guard moved on:

The new guard stepped in:

Kevin Johnson took the helm as president of Windows
Steven Sinofsky moved from Office to Windows Client
Jon DeVaan added Core Operating System Division to his Trustworthy Computing responsibilities

We also had the seeds of an out of band release germinating in the organization.

In this fluid context, we had to figure out names for what appeared to be three simultaneous efforts from the Windows Installer team. Knowing none of the feature and release criteria, our best guess at the time was that Windows Vista SP1 would ship first, an out of band release would ship next, and then the next full version of Windows would be our focus. With this guess at timelines, we chose the names Windows Installer 4.1, Windows Installer 4.5, and Windows Installer 5.0 as the labels for the next three buckets of work from the Windows Installer team.

It just so happened that at this same time, the Windows Vista version of the Platform SDK was finishing up. Given our best guess was that we'd be doing significant work in Windows Vista SP1, we added the reference to Windows Installer 4.1 for anticipatory completeness.

What changed was that the new guard in Windows had a very different bar for the Vista SP than had been in practice for previous releases (at least in my memory). Generally there is lip service to no large feature work in a SP but this time folks listened. Big feature adds were heavily scrutinized. The items we wanted to fix in the SP, UAC tweaks, were big feature by the new bar.

When the UAC tweaks were rejected for Vista SP1, the justification for 4.1 faded as there were no new features in the Windows Installer in Vista SP1.

Where is good, comprehensive training covering the Windows Installer?

Windows Installer Team — Sat, 08 Sep 2007 17:04:00 GMT

Our friend and blogger Aaron Stebner asked on behalf of his readers whether the Windows Installer had recommendations for "good, comprehensive training covering" the Windows Installer. This question comes up regularly and I've built up the following stock answer.

Windows Installer depends on our tools vendors to provide a considerable portion of our end to end story. There is an opportunity for the Tools Vendors to differentiate themselves in the market with the degree to which they onboard their users quickly and given them all the information they need to be successful.

Where education value from the tools vendors is not available or incomplete, one can drop down and build expertise in bare metal Windows Installer. One should expect bare metal Windows Installer expertise does take time to build as we are a system technology with a lot of interdependencies with other parts of the system (the nature of being an installer). What we provide is the Windows Installer portion of the Windows Platform Software Development Kit which contains a lot of information on ‘what?’ is in Windows Installer but has very little ‘why?’, ‘when?’, and 'how do I?'.

There is a broad range of resources available in the community for someone to build their expertise. In the Platform SDK, there is a topic “Other Sources of Windows Installer Information” which a long list of links to things like Whitepapers, Newsgroups, Blogs, Web Sites, Tools Vendors, Chat transcripts, and Knowledge Base articles.

If you’re interested in direct hands on help on a particular incident, there are a set of experts in Microsoft Product Support and Services that have deep knowledge of the Windows Installer. They are kind of hard to find so you may have to ask for the Windows Installer support team directly. If you’re in interested in training a group within your company, Microsoft Consulting Services does offer a week long on-site training on the Windows Installer. Mark Lathrope has provided the MCS services in the past.

One of the Windows Installer Most Valuable Professionals, Phil Wilson, has written a book “The Definitive Guide to Windows Installer” that I’ve heard good reviews about. Inside the Windows Installer team, Phil's book is on the list of new hire resources we recommend folks use to ramp up.

Another of the Windows Installer Most Valuable Professionals, Stefan Kruger, runs a web site http://installsite.org which offers training as well a number of other services. As I view Stefan's catalog of classes, most of Stefan's classes are specific to the authoring application that one uses to author packages.

I've noticed that when I give this answer in person, customers have appeared a bit deflated as they were hoping for more from the Windows Installer team itself. For us, it's a tough trade-off as building better training and education competes with building features into the engine that folks would like us to have.

Configuring Windows Vista Software Explorer

Windows Installer Team — Fri, 06 Jul 2007 19:33:00 GMT

One of the questions I received in the lounge area at Tech Ed 2007 in Orlando pertained to Windows Vista Software Explorer display of applications. Specifically it centered on the ARP* property mappings to the Software Explorer information display. Before I get to that, many thanks to those of you that saw me present in a breakout session at Tech Ed (and understand my love of Chick-fil-A® and how much I miss it while living in the Pacific Northwest). Here’s a “shout out” to those of you that were there! Thanks for coming!

Software Explorer is the new name of what was formerly called Add/Remove Programs (ARP) on prior Windows operating systems. There have been a few modifications to the information displayed and how you navigate around the user interface, so I thought I’d take this opportunity to identify what values correspond to MSI properties and installation. Many of you may already be familiar with the information as some of the basics are provided in the MSDN topic: Configuring Add/Remove Programs with Windows Installer. The MSI properties haven’t changed, but here’s how they map to the Software Explorer UI. Note: If you specify the ARPSYSTEMCOMPONENT property in your installation with a value of 1, then your application is only displayed in Software Explorer if you provide your own additional HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall key specification.

First, the default Software Explorer view hides some of the information from you. The default view does not include all of the possible display information. The initial set is Name, Published, Installed On, and Size.

The view is configurable, so you can specify additional information that you’d like to include by simply right-clicking on the column header and then choosing “More…”:

Which then presents you with the column list to choose the detail information:

And given the column list, here’s the mapping of column list identities to MSI properties (much of this maps to existing Add/Remove Programs mapping info that’s already documented on MSDN in the topic: Uninstall Registry Key):

Column Identity (Detail)	MSI Property
Name	ProductName
Publisher	Manufacturer
Installed On	Determined and set by MSI
Size	Determined and set by MSI
Contact	ARPCONTACT
Help Link	ARPHELPLINK
Support Link	ARPURLINFOABOUT
Update Info Link	ARPURLUPDATEINFO
Comments	ARPCOMMENTS
Last Used On	Determined and set by Software Explorer
Location	ARPINSTALLLOCATION
Product ID	ProductID property available via MsiGetProductInfo[Ex] API
Readme	ARPREADME
Registered Company	COMPANYNAME property available via MsiGetProductinfo[Ex] API
Registered Owner	USERNAME property available via MsiGetProductInfo[Ex] API
Source	SourceDir
Support Telephone	ARPHELPTELEPHONE
Used	Determined and set by Software Explorer
Version	ProductVersion

Hopefully you now have a better idea of how your MSI package authoring impacts the Software Explorer display.

[Author:Carolyn Napier]

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.

Windows Installer 4.5 Beta Accepting Nominations

Windows Installer Team — Mon, 25 Jun 2007 10:00:00 GMT

The Windows Installer team is closing in on our Beta release of Windows Installer 4.5 so it's time to open the Beta program. As usual, the connect site at http://connect.microsoft.com is the host for the program. The Windows Installer 4.5 specific subsite is at https://connect.microsoft.com/programdetails.aspx?ProgramDetailsID=1506.

We're opening nominations ahead of our beta documentation and binary release. For now, the draft white paper "Agility Trends in Package Software" is posted at https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=432&DownloadID=7300. The draft paper frames the problems we're targeting with the Windows Installer 4.5 release.

UPDATE: as E notes below in the comments below, one has to sign-up for the beta program to get access to the doc.

This paper is part of the information we offered the tools vendors on the Live Meeting call we had last month. I'm still working on improved broad live meeting logistics and a bit more polished demo that I'll provide later in the beta program. Your patience is appreciated as the information is gradually staged out of the Windows Installer team.

Thank you for joining our Windows Installer 4.5 beta program.

[Author: Robert Flaming]

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.

Editors note:

- Investigating broken link to paper. Edited down to be less conspicous for now.

- Fixed link to paper. Edited back up to the original text. Root Cause of Break: first time beta site administrator error in that I didn't grant permissions correctly. Thanks for the help (and patience ;^).

- Added note that one needs to sign up for the beta program to get the doc

Update on KB Articles requested for Windows Installer 4.0 on Windows Vista

Windows Installer Team — Thu, 07 Jun 2007 19:00:00 GMT

Late last year, we posted the article Preview of Upcoming KB Articles: Windows Installer 4.0 on Windows Vista listing four KB articles we'd requested be written based on user feedback. Two of the initially requested four have been written

Proposed Title: Custom Action code that is not NX compliant will not run on Windows Vista.
Actual KB Title: Windows Installer custom action code must be compatible with Data Execution Prevention in Windows Vista
KB Number: 929710

Proposed Title: Signed Windows Installer (MSI) packages display unsigned UAC dialog during uninstall on Windows Vista.
Actual KB Title: Notification message when you remove or repair a program in Windows Vista: "An unidentified program wants to access your computer"
KB Number: 929467

After receiving some customer feedback from David Hacker of Macrovision, we’ve added another KB request to the queue.

KB Title: ElevationShield will not show during maintenance mode on a Windows Installer native UI PushButton control

Summary: With Vista and Windows Installer 4.0, a setup author could request the User Account Control shield show-up on a Windows Installer native UI PushButton control by authoring the msidbControlAttributesElevationShield attribute in the Control table. The shield cannot be made to occur on a button during maintenance mode. This can cause user disorientation as the User Account Control shield will not be present to warn the user that a User Account Control credential dialog box is about to pop up.

More Information: This phenomenon occurs because the control attribute msidbControlAttributesElevationShield is gated on the MsiInstallElevated property. The MsiInstallElevated property is set during maintenance mode for managed applications. Per-machine installations are defined to be managed application.

[Author: Robert Flaming]

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.

Policy Interactions and Behavior (Source List)

Windows Installer Team — Fri, 02 Mar 2007 21:07:00 GMT

A few years back, I received some questions pertaining to what privileges were required to modify the source list for a given product. The questions have come up again and rather than debating on where this information belongs (MSDN vs. TechNet vs. whitepaper), I figured I’d skip all of that and lay it out in a blog entry. (The debate will rage on in the mean time, but at least I’ll get the info out and in public).

The first question happened to deal with the AlwaysInstallElevated policy. This is not a policy anyone on the Windows Installer team recommends using (due to its security implications), but we certainly understand that there are those out there that do.

Q: Does the AlwaysInstallElevated policy guarantee that the installation is elevated?

This is actually a tricky question. As long as the AlwaysInstallElevated policy is set (in both HKLM and HKCU), the install transactions are elevated. However, this doesn’t guarantee that the subsequent install transactions are elevated when the policy is unset. Only managed applications have “sticky” elevation where all subsequent install transactions are elevated. There are two types of managed installations – per-machine and per-user. In fact, there are three types of installations that Windows Installer considers: per-user, per-user managed, per-machine. You can easily come to the conclusion that all per-machine installations are managed. However, the same can’t be said of per-user. The only way a per-user install becomes managed is if it was initially advertised via the MsiAdvertiseScript API in the manner documented here.

So, if you perform a per-machine installation with the AlwaysInstallElevated policy, you end up with a managed install. You can unset the policy and still have operations for that install run elevated. On the other hand, if you perform a per-user installation with the AlwaysInstallElevated policy, then that install’s operations are only elevated while the policy remains set. You can’t create a per-user managed installation with the AlwaysInstallElevated policy.

Q: How do I know if my installation is managed (and in what context)?

There are two API you can use to query for this information. The first is the unfortunately misnamed MsiIsProductElevated API which really should have been called MsiIsProductManaged since that’s what it tells you. The pfElevated parameter is set to TRUE if the product is managed.

To determine the context, use the MsiGetProductInfo API and query the INSTALLPROPERTY_ASSIGNMENTTYPE property. If the value of the property is 1, then the context is per-machine. If the value of the context is 0, then the context is per-user. Per-user and per-machine is determined by the ALLUSERS property setting.

Combining the two will tell you if you have a per-machine, per-user managed, or per-user unmanaged install.

Q: What does all of this mean in relation to source list modification?

There’s a set of source list API that allows for modifications such as the addition of new sources, removal of sources, and clearing of the source list (e.g. MsiSourceListClearAll). If the caller doesn’t have the privilege to complete the operation, the API returns ERROR_ACCESS_DENIED. Each of these actually have a small blurb in the remarks section that describes when this can occur, but here’s a closer look…

When MSI is evaluating this, it’s including several pieces of information:

· The caller (admin user or not)

· Product Elevation Context (managed or unmanaged)

· Product Install Context (per-user or per-machine)

· Which user

These bits of information combined with some of the source list control policies determine whether the operation will complete successfully.

Now, let’s consider the default scenario where the AlwaysInstallElevated policy is completely out of the picture. The following table answers the question, Is Source List Modification Allowed? The “x-axis” represents the product install context. The “y-axis” represents the caller’s context.

User	Per-Machine	Per-User Managed (Self)	Per-User Unmanaged (Self)	Per-User Managed (Other User)	Per-User Unmanaged (Other User)
Admin* / System	yes	yes	yes	yes	no
Standard User	no	no	yes	no	no

* Note that on Windows Vista, the admin would have to be the full (unfiltered) administrative token

You can summarize the table as follows: Only administrators (and local system) are allowed to access and modify source list information across users. However, this is restricted to only per-user managed applications for other users. The administrator cannot alter the source list for an unmanaged installation for a different user. The standard user can only update his/her own unmanaged per-user install.

So, let’s throw some source list policies into the mix – let’s say that the DisableBrowse source list policy is enabled and set to 1. The table above now becomes this:

User	Per-Machine	Per-User Managed (Self)	Per-User Unmanaged (Self)	Per-User Managed (Other User)	Per-User Unmanaged (Other User)
Admin* / System	yes	yes	yes	yes	no
Standard User	no	no	no	no	no

So the new summary is: Administrators (and local system) access and modification privileges are unaltered by policy setting. DisableBrowse always disables source list update for all standard users.

Now, let’s restore DisableBrowse to its default and instead set the AllowLockdownBrowse policy to 1. The table now becomes:

User	Per-Machine	Per-User Managed (Self)	Per-User Unmanaged (Self)	Per-User Managed (Other User)	Per-User Unmanaged (Other User)
Admin* / System	yes	yes	Yes	yes	no
Standard User	yes	yes	Yes	no	no

So now with AllowLockdownBrowse, we given the standard user the ability to modify the source list for all per-machine and per-user applications (managed or unmanaged) installed for that user.

The final change we’ll make is to throw out DisableBrowse and AllowLockdownBrowse and instead just set the AlwaysInstallElevated policy. The table now becomes:

User	Per-Machine	Per-User Managed (Self)	Per-User Unmanaged (Self)	Per-User Managed (Other User)	Per-User Unmanaged (Other User)
Admin* / System	yes	yes	yes	yes	no
Standard User	no	no	No	no	No

Note that per-user unmanaged installs for the standard user now become a No with the AlwaysInstallElevated policy set. This is because the AlwaysInstallElevated policy changes these products to acting as elevated.

Therefore, whenever you have the AlwaysInstallElevated policy set, you have to have the AllowLockdownBrowse policy also set in order to allow source list modification. This is summarized in this final table (below) representing AlwaysInstallElevated + AllowLockdownBrowse:

User	Per-Machine	Per-User Managed (Self)	Per-User Unmanaged (Self)	Per-User Managed (Other User)	Per-User Unmanaged (Other User)
Admin* / System	yes	yes	yes	yes	no
Standard User	yes	yes	yes	no	no

[Author:Carolyn Napier]

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.

Preview of Upcoming KB Articles: Windows Installer 4.0 on Windows Vista.

Windows Installer Team — Tue, 31 Oct 2006 01:48:00 GMT

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.

Windows Installer Appears Every Time a Program is Started

Windows Installer Team — Sun, 05 Feb 2006 21:13:00 GMT

Question

OS: Windows XP Home SP2 with Automatic updates every day at 3AM; Machine: Toshiba Satellite M35X-S311; 80% of hard drive free.

My trial version of Office 2003 expired 1/31/06 (no warning messages received prior). I couldn't access Control Panel (system32/CoPM.cpl error). No System Restore points prior to 1/31/06.

Ever since 1/31/06, windows installer pops up on every application (explorer, print, office). "Preparing to Install just hangs there for a couple of minutes -- for everything.

Spyware, adware and malware has been scanned and removed. I've also had my machine scanned by Hijack this, Norton SystemWorks and Registry Mechanic, and no problem can be found.

I've been to the MS support pages, and have tried

update installer (did not help)
Modify the Registry (article 265194; effective for Office 2000)
I've downloaded Windows Install Cleanup, but am not experienced enough to handle any problems that may ensue

I can't begin to tell you how much this affects my work. I've lost 5 days of writing -- which is how I earn my living -- and I'm obsessed with getting my computer back the way it used to be.

Please tell me how to fix this -- this is a major disaster for me.

Answer

I'm sorry to hear you're having these problems. It sounds like it's quite frustrating and you've run out of options. If the following information doesn't allow you to unblock yourself, I encourage you to call Microsoft Product Support Services.

I try and answer question in three parts:

why is this happening?
what is really failing?
how can I fix this?

Why is this happening?

Creating stable corporate computing platforms was a pillar for the Total Cost of Ownership initiative for the Windows 2000 generation of releases. Part of that effort was the Windows Installer Resiliency features. In the controlled environment of corporate computing, these errors do not occur because the accompanying infrastructure is maintained to automatically respond to these issues thereby reducing total cost of ownership for the corporate customer.

Generally, home computers are subject to much less supervisory oversight and assistance. Without the help of a professional administrator, the quality of the application experience on Windows is at the discretion of the software vendor. Software vendor do make mistakes with the Windows Installer Resiliency features and thus you have this experience.

This specific problem is frequently written about in periodicals user assistance columns. I noted this in the blog entry "Stop Installation Idiocy" PCWorld's Hassle Free PC article

What is really failing?

The Windows Installer Frequently Asked Questions has FAQ items titled:

Every time I launch my application, Windows Installer performs an installation. How can I determine the cause of the on-demand installation?

How can I figure out why my package fails to install?

These entries will allow you to turn on Windows event logging and Windows Installer package logging which enable you to determine the which executable (client) and application (package) are providing misinformation to the Windows Installer service.

Behind the covers, it kind of works this way

a client program is trying to assure the correct state of an application.

a client is calling a Windows Installer API (such as MsiGetComponentPath)

either

the system is in an inconsistent state and thereby unable to fulfill the request

two or more packages installed to the system are inconsistent creating a conflict on the system.

the sequence of system (Windows Installer system service) and application (client code and application packaging) functionality is unable to correct the triggering state thus the event is triggered again

How can I fix this?

Generally, start by contacting the Software Vendor(s) that is (are) causing the problem. The event and install logs enabled by the above should allow you to find the offending combination. As a PC is actually a commons, there may be more than one Software Vendor involved. The Software Vendor should be able to tell you how to repair their applications. This is a well traveled troubleshooting route traveled by corporate administrators.

Some home users will give up at this point because they don't have the time or geek-like persistence to work through all the details. Other home users will say they don't have media any more, the software company does not exist any more, or that was an unofficial copy of the application. Still others find their software provider unable to help them due to lack of knowledge, lack of experience, or a propensity to blame the other software provider.

Boiler plate suggestions from an ISV may include (in no particular order)

Repair (msiexec /famus ...)
Uninstall and reinstall (msiexec /x ... followed by msiexec /i ...)
Install again (msiexec REINSTALLMODE="famus" /i ... )
You should be able to try this on your own too.

MSIZap is the the Windows Installer tool that offers to disconnect the Windows Installer portion of the chain. MSIZap just operates on the Windows Installer store of information. MSIZap does not touch the the resources (files and registry keys) of the application. By using MSIZap to remove Windows Installer's knowledge of the application, the calls to the Windows Installer APIs will fail due to unrecognized parameters. The risk to removing the Windows Installer internal data is in how well the client that is calling the Windows Installer APIs responds to return codes (INSTALLSTATE_UNKNOWN for example). From the Windows Installer point of view, MSIZap is a tool of last resort as it eliminates Windows Installer from the equation.

As one will note in the "Stop Installation Idiocy" PCWorld's Hassle Free PC article, MSIZap is a choice user assistance columnists choose to call out.

Hope this helps...

[Author: Robert Flaming]

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.

What are the common reasons for error 1308?

Windows Installer Team — Thu, 03 Nov 2005 17:00:00 GMT

Question

Are there common reasons for error 1308?

Answer

Generally:

Bad Driver/Device, Bad Media, Bad Package are the most common sources. The most common path to eliminating the driver/device from the equation, is to copy to the local hard drive like the media copy instructions in this KB: http://support.microsoft.com/?id=307372. I do not know of general techniques to eliminate bad media other than having customers request new media. Bad packages are generally from poor production process and occasionally from incomplete designs.

Other Specific Instances

Consumption Issues

Share CD over Network: Visual Studio has posted Visual Studio .NET Readme (Part 2) which says folks sometimes try to share an install over the network

5.2 "Error 1308: Source File Not Found"

<snip>

IMPORTANT: Visual Studio .NET cannot be shared over a network by using a shared CD-ROM drive. For additional information about how to install Visual Studio from a network share, click the article number below to view the article in the Microsoft Knowledge Base: 312779 (http://support.microsoft.com/kb/312779/EN-US/) INFO: Visual Studio .NET Readme (Part 1)

Improper Admin Image Manipulation: Office servicing reports in "Error 1308: Source File Not Found" error message when you update your client computer to Office 2000 SR1/1a a problem with swapping SHORTFILENAMES in the admin image manipulation

The error message appears because the SR-1/SR-1a administrative update was performed without including the SHORTFILENAMES=TRUE command-line property. The Windows Installer (MSIEXEC.EXE) SR-1/SR-1a administrative update process automatically defaults to the long file name configuration, unless the SHORTFILENAMES=TRUE command-line property is used (that is, the default directory name is Program Files instead of PFiles).

The original administrative installation was created using Setup.exe /a, which defaults to short file names for backward compatibility; therefore, the update to Microsoft Office 2000 SR-1/1a also needs to include short file names. If the SHORTFILENAMES=TRUE switch is not used when the update to the administrative installation point is performed, the updated files are moved and installed into new long file name directories, and the original files in the short file name directories are not updated. Because the original installation of Office 2000 was performed from the short file name directories, the client update process tries and fails to locate the SR-1 updates in the short file name directories.

Improper Use of HTTP Location:

Office servicing reports in You receive an error message when you try to use a Radia Application Manager transform file to install Office 2003 on a Windows 2000 Professional-based computer support a problem with trying to retrofit http into a package that does not support it

Microsoft does not support the installation of Office 2003 from an HTTP location. Additionally, Microsoft does not support the use of third-party vendor customizations or utilities for the installation of Microsoft Office products.

Exchange reports an instance of the above FIX: Error 1308 When You Install a Program from an Internet Source Location

User Manipulation of Admin Image:

Problem: renamed a file. Solution: put renamed file back

Note, the failure I received is due to the fact that I renamed Setup.exe and Setup.ini so I could have multiple Admin images in one folder. Renaming files is where you'll see this problem. I'm editing the tile to reflect this information.

The workaround is to NOT rename Setup.ini, but to make a copy and rename it - leaving the original.

Problem: renamed a file and transformed wrong MSI. Solution: reverse wrong MSI change, manipulate correct MSI

The wrong setup.exe was renamed in the .msi, as the file attributes do not match the columns in the file table.

Production Issues

Poor admin image support for a MSP: You receive an "Error 1308: Source file not found" error message when you update the CD2 administrative installation to Office 2000 SR-1

This problem occurs because the Data2.msp update file was not specifically designed to update administrative installations. Consequently, the Data2.msp update file is unable to update the Microsoft Internet Explorer and Windows Installer files on your administrative installation for CD2.

Poor admin image support for a MSI: Error 1308: Source file not found" error message when you try to perform an administrative installation of Windows System Resource Manager

This problem occurs because the Wsrm.msi package contains references to the Msvcp60d.dll file and the Msvcrtd.dll file. These files are not included in the retail version of WSRM. Therefore, when you try to perform an administrative installation of WSRM, you receive the error message that is described in the "Symptoms" section.

Poor media labeling: BUG: "Source file not found" error message when you install Visual Studio .NET from a shared CD-ROM drive

This problem occurs when Setup has completed installing the source files that are located on the installation CD-ROM that is in your shared CD-ROM drive. Setup cannot locate the next source file that is required because the file is not located on the CD-ROM that is currently in the CD-ROM drive. This file is located on the next installation CD-ROM.

Poor use of self-extractor: You cannot create an administrative installation image of Office XP Web Components by using the Office 2003 Setup program

This problem may occur because of an interaction between the IExpress Deployment Kit (IDK) and the Office XP Web Components Setup program.

Poor localization of authoring: "Error 1308: Setupstd.exe cannot be found" error message when you run an administrative installation of the Japanese version of Office 2000 SR1 from the Select CD-ROM

This problem may occur if there is an incorrect entry in the Data1std.msi file.

Component Rules Violation and FASTOEM:

Installing <Product> with the following configuration will fail with a 1308 internal Installer error:
- Using the FASTOEM property (requires at least Installer 1.11)
- Specifying the Feature_Global and Feature_ENG features to be installed locally

This configuration fails because both of the above features install the same file: foo.txt. This causes a problem with FASTOEM because instead of copying the source files during the install, it moves the files. So, when the first component (the Component_Global component, which belongs to the Feature_Global feature) installs the foo.txt file, it moves it from the source to the destination. Then, when the second component (the Component_ENG component, which belongs to the Feature_ENG feature) attempts to install the foo.txt file, it is no longer available/present at the source.

OS or Chip Dependent Source Path referenced on Unsupported OS

There’s one bug that goes something like this: Say you parameterize x86 in your source path and set the parameter using an OS call. Now imagine a new chip comes along, ia64 for instance, and the setup program didn’t block attempts to install on unknown chips unknown at release time. I see there are reports on the web of the same problem in reverse for OSes where someone attempted to install a W2k or greater product on a Win9x box and the parameterized path failed.

Engine Domain Issues

bad local MSI file or configuration : I’m not entirely certain this is the correct diagnosis but I presume the fix works anyways

There is this report of a Picture It!: You receive an "Internal error" error message when you run the Setup program

This issue may occur if there are mismatched Installer files and (or) registry keys for the program that is being installed.

Other instances

You receive an "Error 1305" error message, an "Error 1308" error message, an "Error 2263" error message, or a "Windows Installer" error message when you try to install Money

Works 2000: Top Installation Issues

Bug: MSI 2.0 engine for HTTP FIX: Error 1308 When You Install a Program from an Internet Source Location

This problem occurs because of a bug in the Windows Installer installation service. Installing from an Internet source location is supported and should work as expected, regardless of the files in the IsolatedComponents table of the Installation .msi file.

Constraint: Use of Multiple Media Readers (Jukebox) not supported

Share Media on Network Not Supported:

[Author: Robert Flaming]

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.

"Stop Installation Idiocy" PCWorld's Hassle Free PC article

Windows Installer Team — Tue, 01 Nov 2005 17:00:00 GMT

While searching for news with "Windows Installer" in the subject, I recently came across the Hassle Free PC article Hassle-Free PC: Fix Stubborn Windows Install Errors where a reader asked for assistance with the Windows Installer dialogs under the subheading “Stop Installation Idiocy”. I thought I'd offer some deeper context on this scenario.

First, if this dialog happens during First Run of the application, this can be by design. Windows Installer encourages application to write their “user data” at first run of the application. This is particularly useful for applications that install to machines that will have multiple users such as home machines with Fast User Switching enabled or to business machines that multiple people will use.

Second, if the application is installing something “on demand”, this too can be by design. This Installation-On-Demand can be useful for a number of design reasons, particularly when an application has a feature that is less frequently. As a hypothetical, let’s say Word studied it’s features and discovered that Mail Merge was used quite infrequently save for holiday greetings times. The Office deployment developers could choose to expose the Mail Merge option on the menu but leave it on the CD until the user actually invoked it. At the point the user invoked Mail Merge, Word could recognize the bits were not installed and then call to the installation package (MSI) and ask for them to be installed. Given all this happens within the application context, the application can wait for the install to complete then load the functionality without the user ever having to leave their context. Admittedly, if a user is not aware that this is possible, this can be disorienting.

Third, if the application state has become inconsistent, this too can be by design. The Resiliency features of the Windows Installer are designed to both detect when an application is out of specification as well as provide actions to put the application back into compliance with the specification. From one point of view, one could say this is the Windows Installer way of addressing DLL Hell. Window Installer will be provide the file each application expects even if they are the same file path and file name. The only way to do this “correctly” is to swap the files out per application context. There are of course other solutions to DLL Hell from Microsoft including the Fusion technology and the Virtual Machine offerings each with it’s own strengths and weaknesses.

Though there are a number of by design cases for the Windows Installer dialogs occurring during application execution, there is the occasional break such as you cite in your article. A sophisticated user can differentiate these cases by following the FAQ entry Every time I launch my application, Windows Installer performs an installation. How can I determine the cause of the on-demand installation? That FAQ item reads as follows

Q. Every time I launch my application, Windows Installer performs an installation. How can I determine the cause of the on-demand installation?
A. An easy way to determine the cause of an on-demand installation is to look in the application event log for MsiInstaller log messages of the form:
Event Type: Warning Event Source: MsiInstaller Event ID: 1001 Description: Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example' failed during request for component '{00030829-0000-0000-C000-000000000046}' Event Type: Warning Event Source: MsiInstaller Event ID: 1004 Description: Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example', component '{00030829-0000-0000-C000-000000000046}' failed. The resource 'C:\Progam Files\example\example.exe' does not exist.

The first message (with event ID 1001) states which component was being installed. The component listed here is the component named in the Component_ column of the Shortcut table for the particular shortcut.

The second message (with event ID 1004) indicates which component failed detection. Improved event logging in Windows Installer 2.0 has updated the message so that in most cases, the message identifies the actual resource that resulted in the failed detection. The component with the missing or damaged keypath is the component that is triggering the reinstallation.

In the example above, the reinstallation is triggered because the resource 'c:\Program Files\example\example.exe' does not exist. You would then need to find out why the keypath does not exist—in this case, the user deleted it.

[Author: Robert Flaming]

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.

Affects of a Vista Upgrade on Existing Application Installs

Windows Installer Team — Fri, 21 Oct 2005 21:00:00 GMT

Context: Glimpse at an internal thread where Technical Evangelists were asking about Affects of a Vista Upgrade on Existing Application Installs

Question 1: What will happen to the installed programs at the time of OS upgrade?
Will the user be able to uninstall the program from vista if it is installed in XP?
Answer 1: During upgrade, no programs are installed or uninstalled via MSI. They will be present after upgrade, and upgrade design is for them to be uninstallable.

Question 2: What will happen to the files cached in the Windows\installer folder at the time of OS upgrade?? Will they be carried forward AS IS in upgrade Vista OS?
Answer 2: Yes.

Question 3: What about the program files\ folder which contains the binaries and some user settings which is present in the documents settings\user folder, will they be preserved at the time of OS upgrade?
Answer 3: Yes.

Question 4: What is the common way of handling the OS upgrade? If some user installs program in Xp and then upgrades the OS to Vista? What is the option given to the user.? Which one MSFT recommends in case of OS upgrade

uninstall the previous program and reinstall the new one
reinstall the new one
repair the previous one.

Answer 4: When a user upgrades, there are no options provided about uninstalling or repairing programs given. If a program is known not to run in Vista, the user will be messaged and in some extremely rare cases (where the program is known to cause Vista to crash, for instance) upgrade will be blocked until the program is uninstalled. The user will need to quit setup, remove the program and restart setup, however; uninstall does not occur within the context of setup.
For the vast majority of cases.

Question 5: Will the interface between MSI package and 'Add/Remove Programs' continue to be same (i.e., "Support information" that can be displayed in add/remove programs entry for this package, buttons like ADD, REMOVE, REPAIR, etc that are available in add/remove programs and after clicking these buttons the corresponding actions taken by MSI package, etc)?
Answer 5: Yes. Look for two significant changes in Beta2. First, there’s a switch from ARP to Software Explorer which will provide a different view on the same data. Second, the introduction of UAP (formerly called LUA) may alter the user access to the feature formerly known as ARP. In the end literal interface (meaning the API between Software Explorer and MSI) will remain the same but the view on the data will change between ARP and Software Explorer.

[Author: Robert Flaming]

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.