Freigeben über

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

  • Artikel

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

  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

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

Comments

  • Anonymous
    September 24, 2006
    PingBack from http://blog.devinstall.com/?p=6

  • Anonymous
    September 26, 2006
    Visual Studio 2005 works for the most part on Windows Vista, but there are some known issues being addressed...

  • Anonymous
    October 02, 2006
    Windows Vista introduces a security concept called User Account Control (UAC) which has multiple impacts

  • Anonymous
    October 04, 2006
    Visual Studio 2005 works for the most part on Windows Vista, but there are some known issues being addressed