This is the 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, I

  1. Introduced the series
  2. Introduced my view of the root problem
  3. Introduced the conflicting per-user definition
  4. Introduced it'll be just like Managed Installs
This entry will talk about the third hurdle for me in thinking about UAC support in MSI as comprehending how hard it was to get any mixed per-user and per-machine package right at all.

So after I figured out per-user changed definitions, the other elements of per-user started to break down as being fragile.

ALLUSERS property

The ALLUSERS property is supposed to be the selector switch for type of install. As this is a PUBLIC property, the choice whether to install for ‘just me’ or for ‘everyone’ can be made dynamically. With Vista altering the definition of per-user from the install definition to the security definition, ALLUSERS was unavailable to reuse for support of UAC in MSI..

Per-User in Package

Since the origins of Windows Installer, we have advised against containing per-user state in a package that's installing per-machine. This advice was represented in
  • Terminal Server Guidance:
    Under the SDK topic Component Guidelines for Terminal Server, we've tried to establish a set of guidelines for building packages that work on the toughest case of user instancing.  An underlying theme here is that a package is best when it it full switched between all per-user or all per-machine. 

  • FirstRun Guidance:
    Under SDK topics FirstRun Dialog, Installer.CollectUserInfo, MsiCollectUserInfo, Installer.ProductInfo, MsiGetUserInfo, and Initializing an Application, we've tried to establish the preferred way for applications to initialize. An underlying theme here is per-user data is better written by the application at initialization. 

  • Validation Guidance:
    Under SDK topics ICE38, ICE43, and ICE57, we explain the per-user and per-machine differentiate tests we provide for ISVs to run against their packages. An underlying theme here is not to mix per-user and per-machine content in the same component.
     
  • OEM Guidance:
    Under SDK topic FASTOEM property, we explain the parameters OEMs are guided to use to optimize the install experience for the applications. An underlying theme here that having per-user context causes friction in the OEM deployment process.

Though we've tried to give guidance, we continue hear from customers that the packages they are receiving are not following these guidelines.

.NET Era State Management Service

If you were watching closely during the run-up to the .NET framework in the early 2000's, you may have noticed the service side of .NET, called Hailstorm, came and went. Were you watching really closely, you may have noticed a state initiative (referred to as applications settings) whoosh by with the rest of the abandon .NET services. In that mix of technology, there was a state management service that got swept away.

One of the outstanding issues from the Windows Installer effort was a complementary service for doing user specific things. Generically the user specific things are called state and some of the talent that invented Windows Installer were enlisted to work on this effort as well.  Due to some dependencies on .NET services, the effort to build a complementary service disappeared leaving the problem unsolved.

The Jagged Edge

If you've stayed with this post to here, you're probably wondering: '...and how is all this connected?' If this is you, this response is exactly my intent. That this jagged edge exists is not intentional but it is real.