An interesting posting on the Microsoft career site: http://members.microsoft.com/careers/search/details.aspx?JobID=EBFD2E2F-594C-447A-972A-3EDF2B0E14AD

Having worked on the Windows Vista Software Logo program as the deployment technology consultant, the Logo PM role I witnessed offers broad access and rich interaction with a diverse spectrum in Microsoft experts as well as Microsoft's customers.

The deliverables from the Windows Software Logo PM role deliver key differentiated value to the broad Windows ecosystem.

Overheard an interesting discussion on SoftGrid.  Here's my spin on their talking points.

Q: Why is the q:\ drive needed?

A: Some applications write paths to the system in which they need a full path including the root.  Given migrating to SoftGrid in IT is principally done via repackaging (via a tool called a sequencer) the repackager needs to provide the application install a reasonable facsilime of the system.  With the Q drive provided by SoftGrid, the legacy application installer can then sprinkle a fully qualified path to settings locations such as the registry, ini files, and XML config files.

More SoftGrid specific detail is available in Knowledge Base article 931626: How to hide and to restrict access to the SoftGrid Client drive letter

The Group Policy specific ability to hide drives is described in Knowledge Base article 231289: Using Group Policy Objects to hide specified drives

Looking ahead, there are changes in the winds that will require advancing the capacity of the developer to deliver direct and indirect value in deployment.  Developer Division is growing it's investments in software logistics including key developer infrastructure such as task and bug management, source control, and test frameworks.  Investments that occur at the logistical hand-offs between developer (software producer) and user (software consumer) are not as strong as the internal logistical tools.

In moving to Developer Division, my aspirations are about doing things better together.  Better together is consistent with the end to end Windows Installer 4.5 experience across the multi-package transaction, the embedded UI handler, and the embedded chainer.  Better software logistical agility end to end would benefit many software producers and consumers.  Lots of opportunity to solve hard problems and deliver compelling value.

I'm still helping a bit with the Windows Installer 4.5 glide path.  As with any project, there have been choices and decisions made without formally writing them down and reviewing them broadly.  My remaining Windows Installer 4.5 role will be to pull those unwritten details out of my head and messaging queues.

For me it's been just about three years on the Windows Installer team.  As other Microsoft-ies will tell you, after three years on a team, it's common to take stock and look around.  After some reflection, it's time for a change.

The Windows Installer team has been great.  The technology itself is tough to own.  Being the Windows Installer PM, thus the face of Windows Installer, is tougher by yet another order of magnitude.

If you've read the book Moneyball by Michael Lewis, perhaps you remember the multiple stories around the "curse of talent". As with baseball, experts can look at Windows Installer, appreciate it's many talents and dream of what it could be. 

As Monday is the Martin Luther King, Jr. holiday in the US, his sermon titled "Unfulfilled Dreams" is an appropriate read. 

C?est la vie.

A useful little link is this filtered sort for top ranked links for Windows Installer on download.microsoft.com.

Windows Installer is listed as the 22nd most popular download.

There is also a stack rank for all downloads too.

For a view on Agile themes I'm working toward, check-out the Tech Ed keynote at http://www.microsoft.com/winme/0706/29992/teched_.asx.

A Gartner analysis talks for 13 minutes (between 20^th minute and the 33^rd minute) about Agility in the larger Dynamic IT context.

While there?s nothing specific to packaging, many of the aspirations of Agility covered in the presentation.

I like to think in metaphors. Comparative exercises don?t always stick but it?s an interesting to consider ?what if??. This entry will layout the grounds for a potential metaphor. Some later entry will consider the parallels with my day job.

Somewhere I heard about this book ?The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger? (the Discovery channel perhaps). Hmmm? I thought, what are the chances that Windows Installer packages and the distribution ecosystem it integrates with the evolutionary effects of the container on shipping.

When I saw the book in the MS Library, I pinged a few friends to see if anyone had read it. One had and said ?great book but expect to get funny looks when you start trying to tell people about how cool it was.? After reading it, it turns out it was a great book, and so it?s time try and tell the story.

Won?t be the first time I get funny looks ;^).

Chapter 1: The World the Box Made

If you?ve read ?The World is Flat? the premise of this chapter is nothing new. For myself, I?ve grown up in Seattle, a big container port, so I?d always just taken containers for granted. Even after reading Flat and growing up next to a big container port, I had no idea of these details.

This chapter mixes the books two strong elements, the high risk, high stakes narratives with tons of data to back up the story. This mix is somewhere to the data side of ?The Tipping Point? and ?Freakeconomics?. The weight of the data is right to make the weight of the story sink in. This data is measured where these other two book were more statistical exercises that economists like to play.

While this chapter describes today, it does a lot of work to foreshadow the intrigue and narrative to come. This chapter alone is not enough to set the hook the way Flat, Tipping, and Freak does but you can see this is going to be much deeper run at this story. There are so many different ties to contemporary issues it soberly dares you to read on.

Chapter 2: Gridlock on the Docs

Enter the hapless antagonist: I thought the seedy world of the longshoreman and unions were just a Hollywood exaggeration. With the minimal education and teaming masses of immigrants ready to take any job, this economic class had little to defend itself other than to unionize. At some point, not clear where, the abused turned into the abusers.

To be fair, the work was hard, took expertise, and had a relatively high risk of injury and death. The entire business was transient so abuses from any number of the transient players was all but certain. What was lost on labor while defending their life and livelihood, there was still intrinsic problem to the industry: the cost of freight handling.

The author starts to sink the hook here by positioning the solution to the cost of freight handling problems was known to just about everybody and their sister. Evidence was everywhere that better packaging changes the cost of handling. Unfortunately the methods and modes were so widely varied it would have been difficult to pick out the pattern and the intrinsic value in the without a relatively unique view.

Chapter 3: The Trucker

Enter the hero: Malcom McLean. Funny thing is that his heroism isn?t that much different that Microsoft founders; Bill Gates and Paul Allen. A son from a reasonably well off family uses a bit of entrepreneurial spirit to put together the parts of the system where innovations will thrive.

The other protagonist here is the regulatory authorities. The Interstate Commerce Commission has a constitutional authority to govern interstate commerce. To protect the national need for a viable interstate transportation system, they regulated rates (relative to costs) and regulated point to point routes (relative to providers).

So to finally set the hook to this story, the author drops the intermodal idea. Due to world war II surplus, ships were free but domestic port to port shipping was irrational for break bulk handling. McLean?s insight was to imagine the cost savings if you strapped trailers to the deck of the otherwise free boats and ran them down the coast rather than down the east coast highway.

Chapter 4: The System

In my vocabulary, this chapter would be called the method. First, the hero wasn?t the only one measuring costs and leveraging innovations to drive up volume. Second, the others had different techniques but they were all tweaking the numbers to optimize for their business. Third, when times get challenging, grow through acquisitions, innovations, and further leverage.

Chapter 5: The Battle For New York?s Port

As striking a story of the hero, the story of the hapless decline of New York as a world transportation hub. First, there must have been a lack of understanding of the factors that made New York vital as well as where it?s liabilities lie. Second, there was hubris all men?s minds that they had the market in their palm so they overplayed their positions. Third, the container enters from Jersey to finish ?em off.

Chapter 6: Union Disunion

With the previous balance between ports, shippers, and longshoreman now disturbed, the downward spiral of the unions was evident to their leadership. On the east coast, they fought all comers, even when the wiser views would have passed on at least a few of those fights. On the west coast, the pragmatics and protectionism (for the remaining good jobs), the Mechanization and Modernization Agreement was the watershed moment in turning the equations.

Chapter 7: Setting the Standard

With labor on board, more or less with the Mechanization and Modernization Agreement, the next gatekeeper was that shippers would not use the same standard. The vision to go from truck to train to ship across land and sea requires the world to agree to the same format. If you?re a policy wonk like me, these standardization games are fascinating.

Chapter 8: Takeoff

So with labor and transport companies having agreements in place, capital needed to shift their positions world wide. Domestic runs had proven the profitability of containerization so internal runs, unprotected by the United States government, was the next. For some reason, the Atlantic seems to inspire pursuit of retrenching countermeasures while the Pacific seems to inspire cooperation for everyone?s net benefit.

Chapter 9: Vietnam

When our country is at war, capital is no object. Half a world away, Vietnam required massive logistical efforts to get supplies to the front. Blame who you want for the failures, but Mr. McLean was the logistic hero of Vietnam.

Three game changing pivots came from this war. First, the government upped the scale of the game buy paying for massive ships, historically unheard of in the industry and ones that could have never been paid for by private capital. Second, the ships were coming home empty and paid for so anything that could get carried home was pure profit. Third, McLean showed he could build a container port on just about any piece of land a government would make available to him.

Chapter 10: Ports in a Storm

Previously minor ports, having seen increased the traffic of the Vietnam war, started to compete for full time container tenants. Capital was able to off load the costs of building container terminals to the ports that wanted to keep the traffic. Old break bulk ports that could not convert to container ports went the same way as New York. New ports sometimes took business from each other but they all grew.

Chapter 11: Boom and Bust

With everybody in the game and more clamoring to get in, the supply outstripped demand and the market crashed. Our hero, Mr McLean, had the vision to get out early. Overcapacity drove down prices and made freight trivially cheap. The pivot here is that goods from anywhere now had almost a free ride.

Chapter 12: The Bigness Complex

With a very low price point and very high volume, the market had to shift to figure out how to maintain those points without hemorrhaging money. The only solution is to get bigger and bigger. The new bigger sizes ended up obsolescing ports that couldn?t scale up and those ports were relegated to what they called feeder ports.

Chapter 13: The Shippers? Revenge

It wasn?t until intermodal containerization had been around for a decade until the shippers figured out how to play the system correctly. Prior to the end of the 70?s, only the large carriers and shippers could figure out whether taking a container across a continent via train was cheaper than taking it thorough the panama canal. Come the late 70?s everyone started to figure it out and the game changed.

Chapter 14: Just In Time

Now that everybody figured out the global trade-offs, the only remaining element to squeeze out was the capital held up in inventory. With shipping time and manufacturing time now heavily measured and mastered, smart capital squeezed the inventory time from transport. I believe the author intended this to be the glorious end of the story because it had the tone that every last drop of waste out of the system.

Finishing the story here because was sadly disappointing for me because I know of at least two more chapters: a longshoreman?s strike that almost stole Christmas and the strike insurance warehouses that are being built across farm fields in western Washington to create a buffer so the longshoreman can?t do it again.

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

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?
   8. Easier for my current custom installer to support UAC than switch to MSI?
   9. How do I get one credential dialog for a multiple package install?
   10. What are the Hurdles in Windows Vista Logo compliance related to UAC and MSI?

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.

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.

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

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?
   8. Easier for my current custom installer to support UAC than switch to MSI?
   9. How do I get one credential dialog for a multiple package install?

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.

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

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?
   8. Easier for my current custom installer to support UAC than switch to MSI?

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.