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

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

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.