This is the twenty-second in a series of notes about UAC in MSI. Per the earlier caveat, these are just my notes and not an official position from the Windows Installer team. The previous entries

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.

This entry continues a section specifically focused on Question and Answers that often come up in the UAC in MSI dialogs. For this entry the topic is: was "this" intentional? If so, why?

Is "this" intentional? If so, why?

As folks load context from Microsoft's documentation there is a point of synthesis at which they start to wonder why did they intend to do that. Some topics are harder than others to connect to the underlying intent. From what I've experianced in conversations with customers, there are always places in the picture that are difficult to see clearly.

What follows is a set of questions that I get where customers wonder if "this" is intentional and if so why?

What about maintenance mode beyond patching?

(note: "this" == operations other than install and patching)

Maintenance mode operations such as repair or feature state changes do not require credential prompts. This is principally due to the legacy of Windows Installer running on lockdown systems on operating systems prior to Vista. Windows Installer remembers that an application install was ‘blessed’ by an administrator (technical term is for a ‘blessed’ install is a managed install) when running in maintenance mode. Uninstall is different in that it’s a substantial change to the system so administrator authorization via a credential prompt will be required. This is also consistent with the legacy behavior of Windows Installer on locked down systems.

 

Have tools vendors updated their tools to support UAC functionality?

(note: "this" == tools used on top of Windows Installer)

The Windows Installer team has contacted the major tools vendors about the changes coming with Windows Installer 4.0 on Windows Vista. Some tools have more work to do than others. Most will need a new release to completely account for Windows Installer 4.0 on Windows Vista.

 

Please contact your tools vendor for more information on their support plans.

Do I have to sign my MSI and MSP files?

(note: "this" == value of signing)

There are three main reasons to sign MSIs and MSPs.

• First, the Windows Shell is going to differentiate the user experience for signed MSIs and non-signed MSIs in an effort to make the non-signed MSIs seem more concerning.
• Second, a signed MSP with the associated certificate populated in the MsiPatchCertificate table will enable users to apply patches without UAC credential prompts. Less friction in patching will enable the application users to stay more secure.
• Third, signing is part of the habits one should have to create secure setups.

See the Windows Installer SDK topic “Guidelines for Authoring Secure Installations” for more information.

 

Can I have a single package that works with both the old Windows platforms and Windows Vista?

(note: "this" == compatability of packages

Yes. Since Windows Installer 2.0, the Windows Installer has committed to forward and backward compatibility for the packages. This means that each of the engines will look data specific to a feature for that engine and will only provide ‘new’ functionality of the data is present. Given the engines look for specific features, the older engines do not see the data for the newer engines and thus it does not interfere. Finally, where the old behavior and the new behavior intersect, we respect the legacy behavior until unless there is data suggest the package author opted into the new behavior.

Does the credential dialog prompt mean that unattended or quiet installs are no longer supported?

(note: "this" == silent behaviors for automation)

It can but it doesn't have to

• For corporations, there is rich tools market to provide client side services that have the capacity to run as Local System and communicate with a central server to proxy admin rights. This is true for Microsoft products such as Group Policy and SMS as well as products from our partners.
• For home users, look for software that does not require administrator rights to install.
• For testing, the UAC team recommends building a testing service that runs as Local System and has the capacity to take commands and elevate them.
• For administrators, running from an elevated command prompt will also allow for the install it self to be run silently.

Is Windows Installer 4.0 for Vista only?

(note: "this" == lack of downlevel redistributable)

Windows Installer 4.0 is different than previous Windows Installer releases in that we are not planning any down-level redistributable. This is because of three reasons:

1. The big-ticket features we targeted for Windows Installer 4.0 (UAP, Restart Manager, MUI, etc...) were all Windows Vista-specific, and those features would not be supported down-level.
2. We designed all the features to be backwards-compatible with previous versions of the Windows Installer (so there is no need to target Windows Installer 4.0, specifically -- you can create a package that installs perfectly fine on Windows Installer 2.x or 3.x and the new features will "light up" on Windows Vista).
3. We realized that many people redistribute the latest Windows Installer engine without actually needing the new features, so we decided this will be a safe way to save people the reboot down level.

 

My application install requires a driver install. Can I do driver installs with a MSI package?

(note: "this" == unified install package with application and driver)

There is a mixed answer today: no, maybe, and yes.

• No, driver installs are not supported with the standard tables and standard actions.
• Maybe, there is a class of driver installs supported by the DiFX functionality. Please search the web for background on which class of driver installs is supported by DiFX. Most major tools vendors have DiFX support in their most recent versions of application.
• Yes, a driver install can be called from a custom actions in the Windows Installer.

If calling the driver install from a custom action, please be sure to include the NoImpersonate bit on the deferred custom action that is making the call so that the executable runs in the Local System context.

 

Are the Windows Installer APIs affected by the UAC?

(note: "this" == Windows Installer APIs dependencies)

Some are. Any Windows Installer API that can provide a different result if you are an admin (such as MsiEnumProducts) or takes a UserSID as a parameter (such as MsiSourceListAddSourceEx). If you have an application that uses these APIs, consider using the UAC guidelines for ISVs to determine how to best adjust and partition your application.

One of the tried and true troubleshooting techniques for Windows Installer is to re-register the service via a call to msiexec. Has this changed under Windows Vista?

(note: "this" == re-registering service)

Yes, but not due to UAC. As a Windows feature, the Windows Installer registry keys have come under the jurisdiction of Windows Resource Protection. Please refer to the Windows Resource Protection guidance for how to reregister a service from Windows.