Tribal Knowledge in Software Logistics : UAC in MSI

Steven Sinofsky on Windows 7 disclosure principles: respect and responsibility

rflaming — Tue, 27 May 2008 18:54:00 GMT

If you've wondered why not much has been officially said about Windows 7, a blog on CNet posted today where Steven Sinofsky discusses his principles of deliberate disclosure.

These two excerpts had the most resonance for me

Respect

I think that we're just focused--the No. 1 goal we're focused on is really the responsibility that we feel, and the respect that we have for all of our customers and partners, and making sure that what we share with them is really accurate and actionable, and that we are focused, like I keep saying, promise and deliver.

Responsibility

The team feels this tremendous responsibility to working with IHVs and ISVs and OEMs (original equipment manufacturers), because they're running businesses, they have their own business challenges, their own business goals, their own aspirations, and when we speak about what we might do, they will take it seriously. So, we appreciate that and we respect that, and it's a great benefit. But if we're not accurate or the information we provide causes them to do one thing, and then we change our mind, that doesn't bring the ecosystem forward. A big set of challenges that we learned...is making sure that the information we provide legitimately reflects the promises that we're making to ourselves and to the team as a product.

As a big fan of modern superhero movies, Sinofsky's comments evoked this memorable movie line "With great power comes great responsibility".

UAC in MSI Notes: Answers to questions in comments from earlier blog posts.

rflaming — Mon, 02 Oct 2006 06:38:00 GMT

This is the twenty-seventh 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

The last entry marks the end of the document I had original written up and was converting into these blogs. This entry is a switch to an Odds and Ends section that will report the questions that still occur. For this entry in the Odds and Ends section, the topic is: answers to questions to comments from blog posts.

Megh's question under UAC in MSI Notes: Conflicting Definitions of Per-User

1. If we term "C:\Documents and Settings\UserName\Local Settings\Application Data" as the new Per-User location, where does "C:\Documents and Settings\UserName\Application Data" kicks into (based on XP)?

I'm not the shell folders guy but I'll offer you a few things.

First, there's a pattern you'll find in the OS that they move the root of the users directly relatively often. Can't tell you why but this isn't the first time it has moved and is unlikely to be the last.
Second, if you are using a CSIDL and the APIs, the shell will take care of you. I suspect the first point is to try and isolate those that are not following this point but I have no corroboration for this hunch.
Third, I've heard talk that the old directories may be hard linked to the new directories for app compat but I can't tell you how or where I heard that.

I know the app compat teams are planning to expand their documentation but I don't know if this is on the list.

2. When you say, "Setup programs ... can loosen ACLs on anything not Windows Resource Protected", are we talking with the installation package install arena except WRP?

Yes, I think we're saying the same thing.

3. With the File and Registry Virtualization in Vista, when the UAC users are in illusion at folders like Program Files, are they redirected to CSIDL_LOCAL_APPDATA at their profile? How does this help with the per user security if all we are doing is re-directing?

I'm in the same building as the Virtualization team that implemented this feature (not to be confused with Virtual Machine, Virtual Server, or Softricity). This is documented to be an application compatibility measure that will be pulled from a future OS and is not even on the 64 bit platforms. Given the intended shelf life is small, the expected effect is to prevent apps (doing the wrong thing) from blowing up. The accompanying expectation is that eventually they will be either updated for Vista or replaced by a program in better compliance.

Windows Installer has returned to the Windows logo program. UAC has occurred for the first time. The support of UAC in MSI has created the following questions related to Logo compliance.

RandomGuy's question under UAC in MSI Notes: The NoImpersonate Bit Mistake

Hmm... that works for everything except for custom actions which run after Installfinalize... Because they are not deferred custom actions and hence the noimpersonate bit cannot be set.

Yes, exactly right. This is because InstallFinalize is the edge of the Teal circle in the "Saw Tooth" diagram. Once you are outside of the circle, there is no elevation allowed. This is an intentional constraint on the system because it allows the system to be more secure and more deployable.

UAC in MSI Notes: What are the Hurdles in Windows Vista Logo compliance related to UAC and MSI?

rflaming — Mon, 02 Oct 2006 06:00:00 GMT

This is the twenty-sixth 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

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: What are the Hurdles in Windows Vista Logo compliance related to UAC and MSI?

Hurdles in Windows Vista Logo compliance related to UAC and MSI?

Windows Installer has returned to the Windows logo program. UAC has occurred for the first time. The support of UAC in MSI has created the following questions related to Logo compliance.

When I run my application at the end of the install, it runs as the administrative user. How do I stop that?

Like the correct user locations question above, there are a couple of solutions available.

First, start by consider not launching the application at all. The reason you would do this is that you can guarantee that 100% of the time the package would be running in the correct user context.
Second, minimally make sure the custom action launching the application is immediate. Immediate custom actions do not impersonate.
Third, the first two cases are vulnerable to the context before the MSI being elevated to an administrator who is different than the user. One can try to use WTSQueryUserToken to impersonate the root user but this is not guaranteed to work on 100% of the cases.

Why are my Internal Consistency Validator (ICE) checks failing on my LUAAware package?

The Windows Installer section of the Windows Vista Platform SDK contains an updated version of the ICEs for Windows Installer 4.0. You can get them by installing the new version of Orca.MSI or MsiVal2.MSI.

Unsigned Binaries are Getting Flagged when I run Validation on my Package. Is this required?

The Windows Vista Logo program does have a requirement for signed binaries but it is not part of the install section. This validator is actually coming from another source than the Windows Installer ICE validators. Some tools vendors have gone the extra mile to help you get your software prepared for Logo and are providing those validators are part of their value add.

If you are not interested in the Logo program, talk to your vendor about how to turn off the Logo portion of the validation. If you are interested in the Logo program but you can't sign these files (for example, they were provided to you by another vendor) please contact the Logo authority about their recommendations for handling this situation.

Logo References

The Innovate On Windows Vista site contains the information on both the Works With and Certified For Windows Logo programs. Windows Installer is specifically in the Certified For program. The available documents are the Requirements Document and the Test Document. I tell folks that if they are confused about what a requirement means, examining the specific tests for that requirement is usually a good step to figuring it out.

UAC in MSI Notes: How do I get one credential dialog for a multiple package install?

rflaming — Mon, 02 Oct 2006 05:31:00 GMT

This is the twenty-fifth 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

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: how do I get one credential dialog for a multiple package install?

One Credential Dialog for a Multiple Package Install

One of the increasingly common behaviors seen in the market is building up an install from a set of two or more packages. Producers of the multiple package installs note that with our default guidance, their user will need to provide credentials multiple times. This can be a non-ideal experience particularly if one is concerned about credential fatigue.

The recommend solution here is to have two bootstrappers, one inside the other. The external bootstrapper would have an application manifest with requestedExecutionLevel at asInvoker and the internal bootstrapper would have an application manifest with requestedExecutionLevel at requireAdministrator.


Setup.exe (with asInvoker)
 -> InternalSetup.exe (with requireAdministrator)
    + msiexec /jm <path to MSI 1>
    + msiexec /jm <path to MSI 2>
    + msiexec /jm <path to MSI 3>
 <-
 + msiexec /i <path to MSI 1>
 + msiexec /i <path to MSI 2>
 + msiexec /i <path to MSI 3>

The external bootstrapper calls the internal bootstrapper which displays the elevation prompt then advertises all the applications in the package. The external bootstrapper returns to the internal bootstrapper and the internal bootstrapper then completes the installs in the users context. The reason to run the advertising first followed by the user install is to ensure the user context is correctly initialized for any user specific settings that may be in the package. If user context is not properly considered the Over The Shoulder case will result in the parent receiving the user context from an install intended for the child.

UAC in MSI Notes: Easier for my current custom installer to support UAC than switch to MSI?

rflaming — Mon, 02 Oct 2006 05:05:00 GMT

This is the twenty-forth 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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
More Architectural Insights
Conversations with Customers

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: wouldn't it just be easier for my current custom installer to support UAC than switch to MSI?

Easier for my current custom installer to support UAC than switch to MSI?

Generally no. The answer we provide to customers is 'use MSI'. The answer should be ‘use MSI’ and the customer has the burden to say why MSI is unacceptable.

When we say ‘use MSI’ we are acting in the customers best interests.

First, customers building redundant services with the OS if the existing service in the OS provides all their needs is a waste of their resources.
Second, the security risks to doing what’s listed below are substantial. Providing a elevated service creates an attack vector target for the black hats. If they can compromise this service, their technology is a vector to own the box. Is this customer really structured to mitigate and respond to this risk?
Third, the ongoing maintenance of the experience is now borne by Microsoft so the one time cost in switching is made up for in Microsoft’s ongoing commitment to app compat.

Customers want a more secure experiance on their PC and it's our responsability to bring it to them.

In my experience, the idea that 'we are undertaking the burden of security on behalf the ISV by providing these secure services in the box' sells. This sells as Microsoft’s commitment to Trustworthy Computing and it sells as Vista’s commitment to delivering a more secure platform. By reminding customers of the value in aligning with initiatives from the platform, they are usually happier in the end as it allows them to increase their focus on their market differentiating value propositions.

What about Installer Detection? Isn't that an alterative to MSI based elevation?

For now, Installer Detection and security manifests do provide application compatability mitigation but it is not intended to be a permanent solution for deployment. For example, few programs get user state correct in the Over the Sholder cases. Generally elevated programs write to the administrator's profile that provided the credentials rather than the Standard User that invoked the program. Windows Installer is designed to handle this case correctly.

Updates and other maintenace operations will also require elevation if one is using Installer Detection and security manifests. The requirement to go get an administrator creates problems in enabling Standard Users to keep their software functional and secure.

But my needs are really special? Is there something you can recommend?

So the principle thing you are giving up are compelling packaging for corporate consumption. Windows Installer is a known quantity to IT departments so they trust MSI for their standard packaging format. When corporate IT departments get a package is not in the Windows Installer format, they repackage to MSI. You'll reduce the adoption costs of your software at scale if you use MSI.

When your application deviates significantly from the heuristics of the platform and you can't make the platform heuristics fit, the UAC currently recommends either:

write their own service that runs as local system. One needs to focus on building a secure service. One should also have a plan for the black hats attacking the service and how you'll build and redistribute updates.
ACL directories under All Users that only your application install, application itself, and application update that can touch the files.

Yes, there are ISVs that are geared up to get this done right. If you are one of these ISVs, all we ask is that you take the security issues seriously as you design and implement your service.

UAC in MSI Notes: How to Build Packages that work for both Standard User and Per-Machine?

rflaming — Mon, 02 Oct 2006 02:55:00 GMT

This is the twenty-third 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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
More Architectural Insights
Conversations with Customers

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?

How to Build Packages that work for both Standard User and Per-Machine?

While rolling out the User Account Control (UAC) support for Windows Installer (MSI), we’ve been having a common conversation about how to build a single install package that works for both broad web and managed corporate deployment. The thread below homogenizes the questions into an imaginary ISV and the common scenario that drives this particular conversation.

Imaginary Independent Software Vendor (ISV):

Tim is an ISV who provides both a remote browser only and locally installed client experience where both are coupled with Tim's server side backend. The locally installed Tim client harnesses the horsepower of the client node providing a richer Tim experience.

ISVs Market Realities:

Accessing the Tim client market, Tim needs an Install experience that installs to either all-Standard-User or no-Standard-User writable locations. The all-Standard-User-writable install maximizes for reach while accepting a user could mess with integrity of the binaries. The no-Standard-User-writable install maximizes integrity of the binaries while accepting there will be less reach due to some (perhaps many) unable to get their administrators permission.

ISVs Reduction of UAC Messages:

Tim has reduced the messages from the UAC evangelists to:

Microsoft expects the eventual response to any Over the Shoulder (OTS) UAC prompt will be ‘no’
Microsoft expects very few users will run as Protected Admin (PA) there by making almost all prompts OTS
Microsoft expects Protected Admin to be rare enough that it’s just a speed bump for highly savvy users

Tim expects UAC to be wildly successful thus they must design their software to install where no OTS prompts will be successful.

ISVs Derivation from UAC Messages:

Tim is willing to assume that a Protected Admin will always elevate and a pure Standard User (thus an OTS prompt) will never elevate.

Net Scenario:

From a single install package, Tim wants to figure out whether the person initiating the install is Protected Admin or plain Standard User. If Protected Admin, then the install package will configure itself to run as no-Standard-User-writable; else (a plain Standard User), the install package will configure itself to run as all-Standard-User-writable.

Initial ISV Ask:

Please provide me a way to query if the Standard User is plain Standard User or Protected Admin user so that I can execute on this scenario.

Initial Response:

A couple of things to consider

First, the official recommendation from the MSI team is that one should use multiple packages as this maps into the majority of the scenarios that were designed and tested for in MSI 4.0 development. We’ve found dual mode packages are difficult for ISVs to get right for all scenarios.
Second, it's by-design that UAC does not allow a way to query whether a Standard User is plain Standard User or Protected Admin user so that I can execute on this scenario. UAC encourages ISVs to provide users the maximum context so that they can make an informed decision at the consent prompt. UAC does also encourage ‘when you don’t know, say no’.

Second ISV Ask:

The Windows Installer team has actively encouraged ISVs not to use bootstrappers if they don’t need to and we’ve determined separate packages have no collisions so they can be easily merged as long as we have a decision point to chose between the paths. Isn’t there some way to make this work.

Second Response:

Assuming you’re willing to take the risks of the road less traveled, there is a mitigation path that involves

set bit 3 in the word count property of the summary information stream and set the MSIUSEREALADMINDETECTION property (not yet published in the online SDK, internal copy below) and author the package to use AdminUser to determine if the context is already admin. If AdminUser is true, install to the no-Standard-User-writable location; else (AdminUser is false), install to the all-Standard-User-writable location.
for non-corporate distribution, just provide the MSI and the general case will be all-Standard-User-writable install. Warning: you’ll need to figure out how to account for the potential for user tampering of the binaries.
for corporate distribution, provide the MSI along with instructions on how to invoke the plain .MSI in common corporate deployment systems (Group Policy, SMS, Altiris, Tivoli, OpenView, etc) that may require the plain .MSI. The secret sauce to this scenario is that most corporate deployment systems invoke the package from a client running as Local System on the client node.
for the occasional home administrator that does not have corporate distribution tools, provide a bootstrapper (commonly called a setup.exe) that is manifested to run as admin <requestedExecutionLevel level="Administrator" /> that will invoke the MSI.

This is not the majority case for software distribution today so we are unable to provide the same assurances we would provide were you to follow the recommended path.

Third ISV Ask:

Is there a way to avoid the setup.exe bootstrapper in the home administrator case?

Subsequent Response:

You could recommend folks run the install from an elevated command prompt.

Preliminary SDK page:

MSIUSEREALADMINDETECTION Property

Set the MSIUSEREALADMINDETECTION property to 1 to request that the installer use actual user information when setting the AdminUser property. When running on Windows Vista, the Privileged and AdminUser are the same. Authors should used the Privileged property in new packages. Legacy packages that require distinct Privileged and AdminUser properties can restore the difference by setting the MSIUSEREALADMINDETECTION property.

UAC in MSI Notes: Is "this" intentional? If so, why?

rflaming — Mon, 02 Oct 2006 02:30:00 GMT

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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
More Architectural Insights
Conversations with Customers

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:

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

UAC in MSI Notes: Do I need to consider "this" when I'm designing for UAC in MSI? Generally, no.

rflaming — Mon, 02 Oct 2006 01:18:00 GMT

This is the twenty-first 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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
More Architectural Insights
Conversations with Customers

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: Do I need to consider "this" when I'm designing for UAC in MSI?

Do I need to consider "this" when I'm designing for UAC in MSI? Generally, no.

As folks load context from Microsoft's documentation there is a point of synthesis at which they start to ask how does this relate to that. Ideally we could say that 'we've not written anything about this relating to that so one does not relate to the other'. Unfortunately there's history where we've either documentation being wrong or incomplete OR we'd didn't put those two components together to see if they relate.

I like talking to customers about boundaries and relationships because it means they've done their homework. Those customers that are asking because they are experiancing behavior that they are trying to understand are even better. Customers that are already committed are the ones that have most invested and I like helping investors.

What follows is a set of questions that I get about customers "this" list to which I respond generally no.

If I sign my Windows Installer packages, can I register the certificate so that no credentials are required ever (similar to the way Credential Free Patching works)?

(note: "this" == certificates as handle for authorization model)

No. This feature is under consideration for future versions of Windows.

Customers are also asking for this type of feature for the rest of the UAC credential prompt situations. Today there is a technology called SAFER that is designed to allow a corporate authority (IT department via active directory) to deny rights to run programs.

The pre-Vista logic underlying SAFER was everything gets to run unless it's denied. The mindset of Vista inverts this polarity, nothing gets to run unless it's allowed. If Vista's inversion of polarity sticks in the market, it begs the question of whether SAFER's polarity should be inverted.

Is MSIExec manifested to requireAdministrator?

(note: "this" == manifesting of dependent system binaries)

No. MSIExec.exe runs asInvoker when run as a client, as Local System when run as a service, and per custom action attributes when run as a custom action server. Generally, system binaries are under the protection of Windows Resource Protection so there would be nothing a customer could to do a the manifested system binary was "wrongly" manifested.

Do I get a prompt for each custom action that runs elevated?

(note: "this" == heuristics behind credential prompts)

No. There is a single elevation dialog for an entire install. After receiving correct credentials, the msiexec service manages the elevation context per the attributes of the custom actions. If a custom action is marked NoImpersonate, which custom action is run in the elevated sandbox.

We have heard sproratic cases of EXE custom actions triggering a credential prompt. If an EXE custom action is causing a credential prompt, there are two cases 1) the Installer Detection heuristic thinks the binary is a setup bootstrapper that needs to be elevated or 2) the binary was manifested to requireAdministrator. To prevent either case, explicitly manifest the binary asInvoker.

Given Windows Installer runs as Local System, can the Windows Installer now install files and registry keys that are protected by Windows Resource Protection (WRP)?

(note: "this" == capacity to update WRP)

No, the files and registry keys under the jurisdiction of Windows Resource Protection (WRP) are only modifiable by the Trusted Installer. The Trusted Installer is a new service for Windows Vista which does not talk to the Windows Installer. Trusted Installer updates are controlled entirely by Windows so an update to those resources must be done through the Windows servicing system.

Does the UAC Virtualization Technology affect the install behavior from Windows Installer?

(note: "this" == UAC Virtualization Technology)

No, the UAC virtualization technology works during the execution of the applications to mitigate some of the application compatibility problems Windows has seen with pre-Vista applications. Please see the User Account Control documentation for further information on how the virtualization technology affects running applications.

I’ve noticed some shortcuts on the start menu enable a context menu item for Run As Administrator. Can I do this with an advertised shortcut from the Windows Installer?

(note: "this" == UAC user experiance mitigation RunAs)

No. The work in the shell to support Run As Administrator for an advertised shortcut was not performed for the Windows Vista release.

With all the focus on security for Windows Vista, has the Windows Installer made any improvements to the LockPermissions table?

(note: "this" == capacity to write ACLs during install events)

No. Many tools vendors provide their own library that is richer than the existing LockPermissions standard table and LockPermissions standard action. We recommending considering those solutions.

Can I alter the appearance UAC credential prompt dialog either from the native Windows Installer UI tables or from an External UI Handler?

(note: "this" == creating fully custom experiance using External UI Handler)

No. The UAC credential dialogs are from a low level system service and can not be modified or superseded.

Are there regressions to the behaviors of Group Policy, SMS, or non-Microsoft deployment technologies after the Windows Installer changes for User Account Control under Windows Vista?

(note: "this" == corporate deployment technologies)

No. Corporate deployment technologies use a service running as Local System on each client thus will be unaffected.

Group Policy software distribution dependency on Windows Installer is unchanged for Windows Vista.
SMS client runs as Local System so the context it provides for Windows Installer is no different

Can Windows Installer figure out when to add the shield automatically to my authored UI?

(note: "this" == shield ui construct)

No. We do not have enough data about what follows a UI control to know for certain what the last UI control is before switching to the service where the elevation prompt will occur.

UAC in MSI Notes: How do I troubleshoot UAC in MSI via the log?

rflaming — Sun, 01 Oct 2006 02:57:00 GMT

This is the twentieth 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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
More Architectural Insights
Conversations with Customers

This entry continues a section specifically focused on Question and Answers that often come up in the UAC in MSI dialogs. For this topic, the question is: how do I troubleshoot UAC in MSI via the log?

Troubleshooting Windows Installer Packages via Logs

Generating verbose logs for a Windows Installer package are often the best troubleshooting technique to determine what went wrong for an install. With the UAC in MSI functionality, there are a lot of lines in the logs to help you understand what happened. Here's a list....

How can I troubleshoot when the call to a custom action has failed due to lack of access to a machine?

Custom actions vary in their quality and proper handing of errors. The underlying error the custom action will receive from their Windows API call is 0x80070005 (Access is Denied). Assuming the custom action has not written errors to the log indicating Access is Denied, the best guess method is to

Determine the problem occurred in a custom action by searching for Return Value 3 in the verbose log and looking immediately before the error to see of a Custom Action as the source of the error.
Run the same install from an elevated command prompt and check to see if the same custom action was successful.

Generally this indicates the custom action was the problem. The body of the document contains the most frequent custom action errors under UAC and their mitigations.

How can I troubleshoot when a Custom Action attributes do not include the NoImpersonate bit?

The Windows Installer verbose log will contain the following fragment (in bold) when launching a custom action. The number to the right (in bold italics) is the value from attribute table. For this case, this number should have been

CustomActionSchedule(<snip>,ActionType=1025,<snip>)

What is the source of the log message “MSI_LUA: Credential prompt functionality not available on this operating system”?

This message will occur if the operating system is not Vista.

How can I troubleshoot whether the Windows Installer was run from an elevated context?

The Windows Installer verbose log will contain the following line when the caller to the Windows Installer is already elevated.

MSI_LUA: Credential prompt not required, user is an admin

How can I troubleshoot whether the Windows Installer was with the AlwaysInstallElevated policy set?

The Windows Installer verbose log will contain the following line when the AlwaysInstallElevated policy is set.

MSI_LUA: No credentials required as all installs will run elevated due to AlwaysInstallElevated policy setting

How can I troubleshoot whether the Windows Installer saw the LUAAware bit on a package?

The Windows Installer verbose log will contain the following line when the package contained the LUAAware bit.

MSI_LUA: Package is marked as LUA installation capable with no elevation required

How can I troubleshoot whether the Windows Installer opted out of prompting for credentials because the install was silent?

The Windows Installer verbose log will contain the following line when the package was run in silent mode and therefore could not prompt for credentials.

MSI_LUA: Installation UI level is silent, no credential elevation is possible

How can I troubleshoot whether the Windows Installer did not prompt for credentials because the install was already managed?

The Windows Installer verbose log will contain the following line when the package was already managed therefore did not require a credential prompt.

MSI_LUA: Credential prompt is not required at this point, product is managed

How can I troubleshoot the difference between the inability to access the UAC policy and that the UAC policy disabled the credential prompt?

The Windows Installer verbose log will contain the following line when the attempt to access the UAC policy failed.

MSI_LUA: Credential prompt unavailable, LUA policy detection failed with %d

The Windows Installer verbose log will contain the following line when UAC policy disallowed the credential prompt.

MSI_LUA: Credential prompt disabled due to LUA policy settings

How can I troubleshoot when the Windows Installer has received an Over The Shoulder elevation rather than an Admin Approval Mode elevation?

The Windows Installer verbose log will contain the following line for an Over The Shoulder elevation.

MSI_LUA: Detected that session token differs from user token, will use session token as effective token

How can I troubleshoot when the call from Windows Installer to the credential dialog service failed?

The Windows Installer verbose log will contain the following line when there was an error returned from the credential dialog service.

MSI_LUA: Failed to obtain credentials. Error = 0x%X

Does Windows Installer credential dialog when UAC has been turned off by policy?

No. The Windows Installer respects the UAC policy and terminates the install due to inability to get credential prompt. If the install is run with under verbose logging, the following log entry is added.

MSI_LUA: Credential prompt disabled due to LUA policy settings

How can I troubleshoot whether Windows Installer fakes the AdminUser property?

The Windows Installer verbose log will contain this line when AdminUser is faked.

MSI_LUA: Setting AdminUser property to 1 because this is the client or the user has already permitted elevation

Additionally the log will not have this line

Property(C): MSIREALADMINDETECTION = 1

How can I troubleshoot whether the Windows Installer package has enabled UAC patching?

The Windows Installer verbose log will contain this line when UAC patching is not available due to a missing MsiPatchCertificate table.

LUA patching is disabled: missing MsiPatchCertificate table

The Windows Installer verbose log will contain this line when UAC patching is not available due to the fact that the original package was installed per-user (ALLUSER is not defined)

LUA patching is disabled: not available for per-user installs

What does the LUASetting value from the log mean?

Example (in bold): Executing op: ProductInfo(<snip> LUASetting=0 <snip>)

LUASetting reports whether the Windows Installer considers the package is authorized for UAC (0 meaning not authorized and 1 meaning it was).

How can I troubleshoot whether the Windows Installer prompted for credentials?

The Windows Installer verbose log will contain the following line when prompting for credentials.

MSI_LUA: Elevation required to install product, will prompt for credentials

How can I troubleshoot what was returned to the Windows Installer from the successful credential prompt?

The Windows Installer verbose log will contain the following two line the prompt for credentials has been successful.

MSI_LUA: Credential Request return = 0x0

MSI_LUA: Elevated credential consent provided. Install will run elevated

Why does the Installer.InstallProduct call in my web page fail in Internet Explorer 7 on Windows Vista?

Internet Explorer 7 on Windows Vista has a new security feature called Low Rights Internet Explorer. Through this feature, the sandbox that the browser operates from has had its rights lowered to the lowest level possible. As Windows Installer service has the capacity to elevate all the way to Local System, the Windows Installer refuses to accept calls from Low Rights processes (as IE7 now is).

You can detect this case by searching for fragments in the verbose install log. The first is the initial line in the log that tells you what the calling process is. This line will contain the binary IExplore.exe and look something like the following (in bold):

=== Verbose logging started: <snip> Calling process: <snip> \iexplore.exe ===

The second is the line in the log that tells you the connection to the server failed. This line will contain the error code 0x80070005 (Access is Denied) returned from the call:

Failed to connect to server. Error: 0x80070005

UAC in MSI Notes: How do I get the shield on the advertised shortcut?

rflaming — Sun, 01 Oct 2006 02:28:00 GMT

This is the nineteenth 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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
More Architectural Insights
Conversations with Customers
1. Should I write my installer as a Standard User install? If yes, how?
2. When General Custom Action Mitigation Fails

This entry continues a section specifically focused on Question and Answers that often come up in the UAC in MSI dialogs. For this topic, the question is: how do I add shield to my advertised shortcut?

My application is advertised. How do I get the shield on the advertised shortcut?

If you are a developer of an Administrator-Only Application, you will need to manifest your application itself to get the credential prompt appropriate to the users’ rights. If you install supports advertised shortcuts you will also need to manifest your icon. Here's a quick walkthrough for what you need to add a Shield to your shortcut.

Base Generation of an Icon EXE for your Advertise Shortcut

Here's how one generates the icon only exe for advertised shortcut

Generate an icon.ico file.

Generate the icon.rc file

//

// base resource script.

//

#include "resource.h"

/////////////////////////////////////////////////////////////////////////////

//

// Icon

//

// Icon with lowest ID value placed first to ensure application icon

// remains consistent on all systems.

IDI_ICON1               ICON                    "icon.ico"

Generate the resource.h file

// Used by icon.rc

//

#define IDI_ICON1                101

Build the icon.res file

c:\icon>rc icon.rc

Build the icon.exe file

c:\icon>link icon.res /noentry /machine:x86 /dll /out:icon.exe

And now you have your initial icon.exe

c:\icon>dir /o:d

1,078 icon.ico

  421 icon.rc

   71 resource.h

1,912 icon.RES

2,560 icon.exe

that you have been referencing with the Shortcut table Icon_ column

Shortcut	Directory_	Name	Component_	Target	Arguments	Description	Hotkey	Icon_	IconIndex	ShowCmd	WkDir
AdministratorTool	AdminToolsDirectory	Admin.exe	AdminTools	AdminTools				icon.exe

foreign key to the Icon table

Name	Data
icon.exe	[Binary Data]

Generate an icon.exe.manifest file.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

  <assemblyIdentity version="1.0.0.0"

     processorArchitecture="X86"

     name="Icon"

     type="win32"/>

  <description>Description of your application</description>

  <!-- Identify the application security requirements. -->

  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

    <security>

      <requestedPrivileges>

        <requestedExecutionLevel

          level="requireAdministrator"

          uiAccess="false"/>

        </requestedPrivileges>

       </security>

  </trustInfo>

</assembly>

Augment the icon.rc file

//

// Tweaked resource script.

//

#include "resource.h"

/////////////////////////////////////////////////////////////////////////////

//

// Add Shield - per http://msdn.microsoft.com/library/en-us/dnlong/html/AccProtVista.asp

//

#define MANIFEST_RESOURCE_ID 1

MANIFEST_RESOURCE_ID RT_MANIFEST "icon.exe.manifest"

/////////////////////////////////////////////////////////////////////////////

//

// Icon

//

// Icon with lowest ID value placed first to ensure application icon

// remains consistent on all systems.

IDI_ICON1               ICON                    "icon.ico"

Rebuild the icon.res file

c:\icon>rc icon.rc

Rebuild the icon.exe file

c:\icon>link icon.res /noentry /machine:x86 /dll /out:icon.exe

And now you have your manifested icon.exe

c:\icon>dir /o:d

1,078 icon.ico

   71 resource.h

  421 icon.rc

   600 icon.rc

   657 icon.exe.manifest

 1,916 icon.RES

3,072 icon.exe

Why the second manifest anyway?

The way the Windows Installer enables advertised shortcuts is by pointing Windows the shortcut icon to a cached EXE and putting a Darwin Descriptor in the target path. Dividing a package this way enables the CreateShortcuts action in the AdvtExecuteSequence table to populate the Advertised shortcut. When the user clicks on the shortcut, the Darwin Descriptor is decoded by the Windows shell into parameters that are passed to the Windows Installer.

Windows Installer will evaluate if the thing pointed as is present locally and install it if it's not. Due to the caching of credentials with Windows Installer 4.0 support for User Account Control, the Windows Installer will not prompt for credentials. The good news is that even with the dual manifesting one will get just one credential prompt at the launch of the target EXE.

UAC in MSI Notes: When General Custom Action Mitigation Fails

rflaming — Sun, 01 Oct 2006 02:20:00 GMT

This is the eighteenth 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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
More Architectural Insights
Conversations with Customers
1. Should I write my installer as a Standard User install? If yes, how?

This entry continues a section specifically focused on Question and Answers that often come up in the UAC in MSI dialogs. For this topic, the question is: what do I do when the general mitigation for custom action fails?

What do I do when the general mitigation for custom action fails?

Earlier in this series, I'd written about the general mitigation for custom actions under the topics Modify System with InstallUISequence Custom Action, Modify System with InstallExecuteSequence Custom Action Outside of Script, and The NoImpersonate Bit Mistake. These don't always work and problems are difficult to run down. Here are the cases we've found...

When I switch my immediate custom action to deferred and noImpersonate I can no longer access the source image on a network share. How do I adjust for this?

The fact that you can’t access the network when running as Local System (meaning of noImpersonate bit) is a security feature. There are two tracks to work within this security feature.

The one track is to cut your dependency on accessing the source image by embedding the needed files in the binary table of the package or installing the files and then running the custom action from the installed copies of the files.

The other track is to access the network using an immediate custom action which can then communicate to a deferred custom action via setting the CustomActionData for that action. If the CustomActionData pipe is not big enough, then some will create a temporary directory on the disk and use that as a working dir, however care should be taken to mitigate the security implications of this approach.

When I switch my immediate custom action to deferred and noImpersonate I can no longer write the correct user locations. How do I adjust for this?

In the case of an Over The Shoulder elevation, the fact that you have access to the admin users’ account is as expected in the design. There are two tracks to mitigate for this problem.

One of the tracks is to eliminate the user state from your package. Windows Installer has since inception guided package providers to write their user state during the first run of the application. If one were following this guidance, there should be fewer (and possibly no) instances of the deferred, noImpersonate custom action writing the wrong users profile.

The other track is to use WTSQueryUserToken to try and get the identity of the person that launched the program so that you can write their profile. This technique requires code to then use the token to impersonate a user. This technique is not guaranteed to work in 100% of the cases.

No matter how I adjust the position or elevation level of the custom action, the custom action continues to fail. How do I adjust for this?

These instances usually are calling an underlying API that is not UAC compatible. From here you need to debug into your custom action and check the different return codes from the APIs between the XP and Vista experience. How to debug your custom action depends on the type of action.

My custom action is triggering another UAC prompt. How do I adjust for this?

This can happen with an EXE custom action which Installer Detection heuristically evaluates to bootstrapper that need elevation. One fix for this is to add a security manifest to the EXE. The other fix for this is to move to a non-EXE custom action such as a DLL custom action.

UAC in MSI Notes: Should I write my installer as a Standard User install? If yes, how?

rflaming — Sun, 01 Oct 2006 01:51:00 GMT

This is the seventeenth 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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
More Architectural Insights

This entry will start a new section specifically focused on Question and Answers that often come up in the UAC in MSI dialogs. First up, should I write my installer as a Standard User install? If yes, how?

Should I write my installer as a Standard User Install?

It depends. The dependencies include

Whether the architecture of the application being installed will work from a Standard User installed location. There are places in the system that will always require admin rights to install to. If your application must go there, there's no use in going any further.
If you're going to have an application that needs administrator's permission to run, you don't want it in a per-user location. An application that is going to be elevated should install to a location that is not Standard User tamper-able. Were a program that ran elevated tamer-able by the user, a black hat could modify the binary in the per-user context and then elevate to compromise the entire machine.

When talking to customers, package producers (generally ISVs) have told me they don't want per-user for these reasons

Installing to locations the user has the ability to alter might reduce the confidence the package producer has for the integrity of the install. This can affect support costs as well as computational correctness under a regulatory environment (lawyers, accounts, food and drug companies, government agencies, etc)
Multiple instances of an install means there is duplicate copies of binaries on the machine which wastes disk space. A per-machine install creates a single copy of common binaries for all users thus saving space.
Software is less secure because updating behavior has to be done for each user on the machine. In other words, the occasional user on the machine can made the machine vulnerable because they are not on the machine often enough to keep the software they use up to date.

When talking to customers, package consumers (generally corporations) have told me they

Want programs in locations users can't tamper with. User tampering is a major source of support costs.
Centralized install, servicing, and uninstall from a central IT department are all more challenging when the apps are just in the users profile. There are numerous conditions where it is known not to work at all.

The one case Standard User makes the most sense is viral applications that are being distributed via the web. Even for these applications one has to ask the question: do you want to eventually grow-up to be distributed inside a corporation?

How do I build a Standard User package?

This takes a bit of work to make a package install only to the locations a Standard User has permission. Some of the requirements are

Use a Type 51 Custom Action in the InstallUISequence to always unset the ALLUSERS (the per-user option)
Files must be written only to folders that Standard User has access to. Assuming the ALLUSERS is always set to the per-user setting, you can use the redirectable folder properties but not ProgramFilesFolder as it does not redirect on per-user.
Install app to a location under LocalAppDataFolder.
All registry settings should be written to HKCU which is 1 in the Registry Table’s Root column.
Flip bit 3 of the word count property in the summary information stream to signal no credential prompt is required.
If you have a bootstrapper (typically named setup.exe), manifest the requestedExecutionLevel to run asInvoker.
Pass ICE Validation as the ICEs have checks for incorrectly mixing per-user and per-machine state.
Test both from a Standard User account and from an elevated command prompt to confirm behavior.
Provide your users’ documentation of the user specific nature of the package as this is atypical in today’s application installs.

UAC in MSI Notes: Read the Friendly Manual

rflaming — Sun, 01 Oct 2006 00:46:00 GMT

This is the sixteenth 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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
More Architectural Insights

This entry will talk about the next step to understanding the broader architecture in play for understanding UAC in MSI: please take the time to read the SDK.

Read the Fine Manual (RTFM), an old acronym

If you are already deeply involved in this topic, I don't have to tell you the following. For most Windows Installer experts, a large part of providing their expertise to others Windows Installer is being a human index to the Windows Installer portion of the Platform Software Development Kit. While there are more rude versions of RTFM, Read The Fine Manual is tried and true advice from many generations of computing. You'd be surprised how just understanding the manual makes you an expert.

Inevitably I run into those who, like me honestly, have only partially consumed the manual. These Windows Installer journeyman

get stuck in translating the intent behind a topic
synthesizing the full insight needed to understand
find the topics are insufficiently rich or verbose
point out to the rich mix of mixing documentation

To these journeyman I am sympathetic. I've personally tried to help by opening hundreds of documentation bugs in the six months I was focused on documentation for Windows Installer 4.0. Some of those bugs came back "By Design" or "Won't Fix" so I've learned there are constraints to the SDK document format.

The SDK is focused on explaining "What?". "How?" and "Why?" questions are not the domain of the SDK. Some of the "How?" and "Why?" around the Windows Installer can be inferred from the "What?" BUT not all things. Other technologies in the Windows motivate shelves and shelves of technical books. Other technologies in Windows motivate whitepapers and rich tool environments on top of the base "What?" that comes from the platform SDK. Windows Installer does have a small market but for these secondary sources but it's still small on a relative basis.

Still, if you aspire to go beyond the journeyman to attain architectural mastery, you're going to need to have the "What?" on hand as you work outward toward the "How?" and "Why?".

Quick Introduction to Topics in the SDK

So the journeyman say "I'm under some pressure so could help me pick out the important items?". Absolutely. Here you go:

Let's start on the What's New in Windows Installer Version 4.0? page.

Using Windows Installer with UAC
Our professional SDK writers introduction to what UAC in MSI means. Chock full of goodness. Tight writing. (Wish I could write like that. ;^)

User Account Control Patching
An update to the 3.1 feature that enabled home users get patch even if they were Standard Users in the precursor to UAC called Least Privileged User. A full forensic account of UAC in MSI would report this as proof MSI could help deliver the UAC scenarios.

User Account Control glossary entry
Functional definition of UAC in the MSI SDK. Also provides a bridge to the UAC portion of the SDK.

Per-User and Per-Machine
Stuff you need to understand to see the difference between Install per-user and per-machine. Compare this with the way UAC defines per-user and the gaps and seams will start to appear for you too.

Biggest explanation comes for the topic Using Windows Installer with UAC and it's sub topics.

Guidelines for Packages
This topic was generated from one of the first bugs I opened against the SDK to respond to the top customer issues. The dialog I remember around this time was: sure, these topics are all already covered in other topics in the SDK but customers are having a really hard time putting these all together. As you read this, contrast this with what I've tried to say in the blog series and you may get a sense of the difference between going from "What?" to "How?" in the format to the SDK that is distinct from going to the "Why?" to "How?" I'm trying to built out via the blog.

Authoring Packages Without the UAC Dialog Box
Again another "how" topic that was based off a bug that said: sure, these topics are all already covered in other topics in the SDK but customers are having a really hard time putting these all together.

Installing a Package with Elevated Privileges for a Non-Admin
To me, this reads like a family tree in the thinking behind how users and elevation are managed in the Windows Installer. Were I our SDK writer, this topic would have been the hardest topic for me to write. This is a synthesis topic that covers a number of generations of the Windows Installer and the Windows platform. Hurts my head to think about all these generations simultaneously.

Advertising a Per-User Application to be Installed with Elevated Privileges
This topic hasn't changed for Vista but Vista makes this increasingly important. As a Windows Installer user (before I got my current role), I've always considered this topic cryptic. I still see it as cryptic but I now have a path I could walk someone through the context if I had to. I walked a UAC PM through the context behind this once to which he said: "that would be a great whitepaper. Can you write that down?". It's on the list.

Outside of the Windows Installer portion of the SDK, the User Account Control team is still building their docs. Today, this contains...

Getting Started with User Account Control on Windows Vista
Pretty intro to the user experience from Vista Beta 1. This is much friendlier writing that later writing because UAC was optional in Beta1. Ideas are still relevant but lots of context has changed.

Getting Started with User Account Control on Windows Vista
Post Beta 2 draft of the above. Subtitled: discover how to get started with User Account Control.

Understanding and Configuring User Account Control in Windows Vista
Index page that provides a jumping off point. In that this was authored post Beta2, it's much more relevant.

Windows Vista Application Development Requirements for User Account Control Compatibility
Downloadable word doc that you can place next to your development environment as a desktop reference.

Developer Best Practices and Guidelines for Applications in a Least-Privileged Environment
Bible for working with UAC between Beta 1 and Beta 2. This is the doc I used to understand UAC.

Lots to read. Some believe understanding the manual will tell you everything you need to know. Honestly, the manual isn't enough for me but maybe simply RTFM it'll work for you.

UAC in MSI Notes: O Whitepaper, Where Art Thou?

rflaming — Sun, 24 Sep 2006 09:26:00 GMT

This is the fifteenth 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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
More Architectural Insights
1. My "Four Square" Diagram
2. Challenges for a Beautiful Custom Action

This entry will talk about the a common architecture request when discussing UAC in MSI: white papers on these larger design issues would really help.

Where's the Whitepaper on This?

Walking customers through deep architectural and design context in person and on the whiteboard has brought up a fair number of questions from customers. These explanations are ones that engineering managers need to take back to their developers or testing managers need to incorporate into their quality assurance plans. As a six year customer of the Windows Installer before my current stint on the Windows Installer team, I too would have been a much more successful engineer with the Windows Installer had I comprehensive architectural and design papers at my disposal.

Ideas for Whitepapers Derived from Customers

At one point during the Vista customer engagement cycle, I sat down and wrote out the list of whitepapers customers had asked me for or that I wanted since the time I was a customer.

Designing Per-User Applications for Windows Vista

Possible Abstract

User Account Control in Windows Vista is a paradigm shift in computing. Many applications will use this opportunity to reexamine their architecture. Some applications will need to reexamine their architecture as the black hats are starting to shift their attacks from the platform to applications. When an application architect redesigns their application, they should consider the writing their applications into per-user form as per-user is necessarily more secure than an application that requires administrator permissions to run. Below we aggregate the per-user guidance from Windows for applications.

Possible Table of Contents

Per-User is More Secure
- <standard UAC justification>
Per-User Resources
- which folders are OK to write under UAC
- which hives are OK to write under UAC
- others?
Per-User Applications
- general application guidance for per user
- specific recommendations
  - services
  - tray programs
  - drivers
  - runtimes
  - activex controls
  - games
  - updates
  - client-side of muti-tier solution

Windows Installer Architecture

Possible Abstract

Windows Installer architecture is designed to operate in a corporate lockdown or Vista User Account Control. The Windows Installer server is built to run as a Windows service that runs as Local System and Impersonates the user in necessary cases. The Windows Installer client is built to run as the User and thereby only has the rights allowed for that specific user. The Windows Installer is built to support both user only and requires administrator installs. When the Windows Installer package requires administrator permission, the Windows Installer is conditioned to respect the administrator permissions whether from the token on the users account, group policy installations via Active Directory, and new for Vista User Account Control credential prompts.

Possible Table Of Contents

Client Server Architecture
- Client Server Partitioning
- Building the Transaction Script
- Transaction and Rollback
- Binaries, Settings, and User State
User and Administrator Contexts
- Per-User vs Per-Machine Packages
- Managed vs Non-Managed Packages
- Differentiating User, AllUsers, Administrator
Resource Classes
- Base Resource Types: Files, Directories,
- Standard Resource Types
- Extending MSI for Custom Resources

Designing High Quality Custom Actions for Windows Installer

Proposed Abstract

The resource types that need to be addressed during to setup and the standard action infrastructure of the Windows Installer has stabilized. Purveyors of resource types need to are slowly learning reliable and consistent install and management increases their customer satisfaction with their resources. Custom actions run in a specialized environment which results in particular design requirements for the setup and management domains. Below we discuss how to design and build a high quality custom action as well as how to account for the setup and management needs in the base resource.

Proposed Table of Contents

Install and Management Paradigm
- Transacted and Rollback
- Repair and Resiliency
- Online and Offline
- Binaries, Settings, and User State
Blocking out Packaging
- Data Driven Organization
- Binding to Features and Components States
- Dividing Elevated and Non-Elevated Functionality
Effort in Custom Actions
- Costing Custom Actions
- Marshaling Data From Database To Custom Action
- State Changing Custom Actions
- Patching and Uninstall Custom Actions
- Documentation for Authors and Administrators
Don’t Make These Mistakes
- Setup Time Dependency on Bits Being Installed
- Direct Call to EXE Custom Action
- Script Custom Actions

Designing Auto-Updating applications for Windows Vista

Proposed Abstract

With the advent regular security bulletins, wide spread broadband connectivity, and lengthy beta/Customer Technology Preview cycles Personal Computer customers have become used to receiving updates from the web as never before. With the sophistication to expect maintenance over the web, customers are asking why not all my apps? Some applications are ahead of the curve and already provide some auto-update functionality however the advent of User Account Control in Vista has broken a number of those auto updating applications because they required administrator context. Whether you're new to Auto Updating or you've had Auto Updating for some time, this paper will discuss a standard approach for building Auto Updating into your application.

Propose Table of Contents

Release Strategies
- Patches vs Updates
- Per-User vs Per-Machine
- Feature vs Security Changes
- Updates as Subscription Value
- Pointer to Release Planning and Management Paper
Publishing Process
- Web Publishing Basics: trust and privacy
- Production process functionality
- Server side functionality
- Stage side functionality
- Client side functionality
- Management process functionality
Packaging Process
- Use of Windows Installer 4.0 credential free patching
- Corporate Considerations for packaging
Application of Auto Updates
- yet another another toast popup?
- settings control?
- ask once or ask always?
- cache local or apply from remote?
Commercial Services
- Choosing a update service provider
- Migrating between services
- Discontinuing service

Software Life-Cycle Management with the Windows Installer

Proposed Abstract

Perhaps you're just starting your software enterprise or perhaps you've been at this from some time, this is not your mother's software environment. Users are more sophisticated in their expectations and there are more technologies to account for and manage. Smart release management along with the technologies from the Windows Installer can help you deliver high quality software through out your products software-lifecycle.

Proposed Table of Contents

Software Lifecycle Stages
- Dependencies
- Pre-Release to Manufacturing (or the Web)
- SKUs, Standalones, Suites
- Language Packs
- Add-ons and Redistribution
- Shipping
- Small Servicing: patching
- Medium Servicing: service packs
- Large Servicing: Upgrades
- End of Life
Windows Installer and the Software Lifecycle
- Builds and product testing
- March to shipping
- Localization
- Preparing for servicing
- Staging Service Releases
- Migrating to the newer version
- Stopping service
Outside of Windows Installer Scope
- Bootstrappers
- Package RefCounting
- Update Services
- Packaging tools
- Corporate Management
- Licensing
- Channel Differentiation
- Localization
- Add-ons and redistribution

The Other Titles Ideas

...that I didn't get time to work out abstracts and table of contents for

Data Center Deployment: How Microsoft Runs It’s Data Centers on Windows Installer
Beyond the Perimeter of Windows Installer: Chainers, External UI, and Dependency Management
The Windows Installer Cookbook: Recipes for Setup
Shipping Localized Software with the Windows Installer
Troubleshooting Windows Installer Packages and Install Events

UAC in MSI Notes: Challenges for a Beautiful Custom Action

rflaming — Sun, 24 Sep 2006 08:03:00 GMT

This is the fourteenth 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

Introduce...
Architecture Insights
1. The "Saw Tooth" Diagram
2. Credential Prompt and Permissions
Common Package Mistakes
Deeper Architecture Insights
1. My "Four Square" Diagram

This entry will talk about insights that I use to explain to customers the UAC in MSI functionality: custom action challenges for a beautiful custom action.

Why are Custom Actions so Difficult?

When talking about UAC in MSI, customers often remark at the complexity of writing a high quality custom action relative to other code on Windows. These customers will point to the dot net framework or the UI investments and say over time, it's much more simple to write code in other parts of the platform. These customers are not wrong but they are also looking at the programming darlings. There are difficult areas in the spectrum of Microsoft technologies that are difficult to work with. Drivers and MSN services are two I'd found particularly finicky were you a programmer used working with a programming darling such as the dot net framework.

That being said, setup does present some real challenges. First, you have to be diligent with your dependencies as lack of prerequisites can blow-up the simplest custom action. Second, a data driven world does not directly map to a procedural programmers experience or training. Third, more than likely the underlying stores you are trying to address during setup didn't think through the constraints the way you are going to need to. Forth, security and robustness are an unavoidable consideration and these are programming qualities it's tough to get right. These conditions make programming custom actions challenging.

I sometimes go into a diatribe about the perceived value of solving this problem and that most businesses do not invest but usually I just sound cranky as it's not something anyone has a magic bullet to fix.

Where's the Whitepaper with Custom Action Guidelines?

Eventually customers that are trying to understand how to write high quality custom actions ask: where's your whitepaper with Custom Action Guidelines? Regretfully I say we don't have one. Windows Installer development will tell you that what you need to know is in the Windows Installer SDK. Read it carefully, follow it's guidelines, and you'll do fine.

Customers reply: how can it be that the SDK is complete if so many people are having problems writing custom actions? If a customer has relied on one of the Windows Installer partner tools vendors, they usually have little problems. The tools vendors have done a great job creating easy to use products that one can ramp up quickly and feel proficient in no time. The challenge comes when they traverse from the comfortable confines of the tools vendors environment and go it alone. Few take the time required to load all the context they need out of the SDK to step up to the challenge.

Customers then wonder: shouldn't this be a stronger concern from the Windows Installer team? We are a highly leveraged technology team. We have about 10 engineers between dev, test, and PM on a technology that installs about 90% of the corporate ready software and above 40% of all PC software. We have a lot of strong concerns and, yes, quality of custom actions is very high on the list. By and large, we focus on features in the core of the technology and we rely on our partner tools vendors to take those core features to the masses. There are a number of vendors that have made a nice little business out of tools on top of Windows Installer and we are very grateful to them for joining package developers and consumers through our technology. If you believe you will need custom actions in your package, we advise you add a set of criteria you will use to choose your tools vendor.

A Beautiful Custom Action

Given we haven't produced definitive documentation, I will sometimes rattle through the aspects of high quality custom actions. Given this is not engineering guidance, I'll borrow a phrase from art and call these my top tem qualities of a Beautiful Custom Action.

Data Driven: all the behavior in the custom action should be transparent given the a view on the data
Component Grouped: all the data operated on by the custom action should be grouped in a component as components are the unit of reasoning for Windows Installer.
Feature Selected: all the components operated on by your custom action should be connected to features that the user can select and deselect
Respect Existing User Choices such as Install Location: the selected features connected to the component grouping of the custom action data should respect the existing user choices.
Provide for User Choice: where appropriate enable the user to make choices relative to the custom action data.
Integrate with User Feedback: existing actions provide prerequisite checking during initialization, disk costing during feature selection, progress while action is executing, and logging of events from action.
Provide Developer and Administrator Guidance: standard actions make their behavior transparent for both developers that are providing the package and administrators that are using the package.
Data Marshaled Based Off Selections: selections are analyzed, active data is derived, and actionable data is marshaled from the database into the custom action through the CustomActionData property
All System Changes Occur in Transaction: all changes that occur to the system occur in the transaction such that they can be rolled back.
All State Transitions Have Behavior: state transitions beyond install have behavior such as uninstall, repair, admin install, advertising, patching, and patch uninstall.

The White Box Standard a beautiful custom action will make it easy to make connect the data to the behavior and integrated to the existing user touch points already used by standard actions.