Doctor Deploys Blog

I skipped the progress report for the WiX toolset last week and had a couple people ask about the count. So I guess a couple people are finding this data useful. Anyway, the short answer is that the bug count is down from 26 two weeks ago but steady from last week at 22.

Despite treading water, there are two big positive trends I see on the horizon. First, one of the hard open issues I’ve been worried about for a long while is seeing traction. In this case, I’m talking about handling fallback languages with .wxl files in MSBuild. Hopefully next week the solution will be functional.

Second, Jason has turned his attention on the Votive backlog and we’re starting to see those bugs drop. We even had a surprise visit by Justin tonight and he’s started looking into the VS2005 integration issues. If all continues, Votive will be in very good shape in a month or three.

Sadly, this was likely Bob’s last meeting with us in Redmond before he heads off to Boston. While his presence here will definitely be missed, I am excited to see how "WiX East" develops. I’m also hoping with Bob remote we can get a bit more data about how to distribute culture.

In the meantime, keep coding… you know we are.

Original post by Rob Mensching

We had another good night of bug fixing in the WiX toolset. We started well above 30, with a couple more bugs in the MSI 5.0 implementation and some fallout from the large heat changes. The worst of those are fixed and we’re back under 30 with 26 open bugs.

As you can see in the graph, pretty much everything except Votive and Votive related MSBuild bugs are getting near zero. So soon there will just be that and WiX v3.5 to focus on. Votive work will get very interesting after the VS team finishes the integration work for the next version of Visual Studio. We’ll be trying to support three different versions: VS2005, VS2008 and VS2010 (or whatever they call it). Interesting indeed.

Again, things look good as you can see in the graph below. I really like that we keep dropping below 30 bugs.

Original post by Rob Mensching

Last night I was looking around to see how ASP.NET MVC was doing and noticed Phil Haack posted that ASP.NET MVC RC2 was available. I was disappointed that the RC2 was basically all setup work. My immediate thought was, "Why didn’t they get that stuff right in the first public release?" My second thought was, "Does that mean that previous releases have a poor setup that might be messing up machines?" My third thought was, "Hmm, I installed ASP.NET MVC Preview 4, Preview 5, and RC1… I might have one of those messed up machines."

I went to sleep and woke up this morning to find Phil Haack had a new post titled Troubleshooting Windows MSI Installers. My immediate thought was, "A product waited until the last possible moment to focus on their setup and now there are problems. Color me surprised." My second thought was, "MSIZap? WTF!?!"

Note: I’m picking on Phil a little here because he leads with some poor recommendations on his very popular blog with a generic title of "Troubleshooting Windows MSI Installers". It could really lead people down the wrong rabbit hole and misses an opportunity to actually improve the ecosystem.

MSIZap? WTF!?!

My visceral reaction to Phil’s post kicked in when I saw him recommending MSIZap at the top of his blog post. Phil has most of the right disclaimers in place by basically suggesting that MSIZap is a last resort tool. Unfortunately, he puts it up front as the first and most effective option to get unblocked.

There are three major issues with MSIZap and the poorly named Windows Installer Cleanup Utility:

1. MSIZap nukes the registration of the product from the machine but does not actually remove anything the product installed. That means all the stuff you installed is still there and there is now no way to uninstall it (except by hunting it down manually). That left over debris leads us to issue number two.
2. Your machine is now in an unknown state. The information about what is installed has been surgically eviscerated and when you install the next version (assuming you do that) it will be dealing with debris that it was not designed to encounter (due to issue number one above). Way back when in Office, I’d sometimes get a tester saying that the new build failed to install and they were blocked. After looking at a very bizarre error case for entirely too long, I’d ask exactly what steps they took to get into this state. They’d say, "Oh, I just MSIZapped the previous install." I would nod and say, "Cool, you invalidated your machine. Format and start over." I was nonchalant about it because MSIZap removed our ability to debug the root issue, which brings me to the third point.
3. You have lost the ability to figure out what went actually wrong. Debugging Windows Installer failures is a matter of analyzing a verbose log file captured from the failed setup operation. As noted above, MSIZap removes the ability to do that. Now, Phil actually provides the information how to do that (msiexec /l*v or the Logging policy). Unfortunately, rather than asking people to send failed logs to his team for diagnosis, Phil proposes people MSIZap when uninstall fails thus moving into a non-debuggable unknown state.

Orca? FTW!?!

Now I love Orca as much as the next setup developer but I would never recommend that users (even if those users are developers) open my MSI package with the editor and start cutting out pieces. That’s like suggesting that a user go in with an assembler and edit a compiled binary to work around a crashing bug.

Phil even suggests that "Editing the MSI is not really encouraged since it may cause other problems such as failing to uninstall properly." That or failing to install the product correctly or pretty much anything else. In my mind this is just another way to get into a completely unsupported state. I don’t know why Orca is listed as a solution to the problem.

Windows Installer? NO FAIL!

Typically, when this sort of things happens I see everyone pointing at the Windows Installer as the root of the problems. To his credit, Phil does not blame the Windows Installer and there is only one comment on his blog at the time of my writing that does. I make this point because based on the information presented it appear that the root of ASP.NET MVC’s failure issues are all in systems developed by Visual Studio: NGEN and devenv /setup.

That means Phil should be able to walk across the hall or across the street and pass along a whole lot of "FAIL" to one or more teams. A follow up blog post today suggests that Phil has already started doing that which is fantastic. My hope is that he will go further and help Visual Studio fix two pieces of the deployment world that I’ve also found (in my experience with the WiX toolset) to be fragile. The devenv /setup is of a particularly poor design.

What would I have done differently?

Phil’s heart is clearly in the right place. He wants all developers to be able to experience the glory that is ASP.NET MVC and doesn’t want its installation to deter from that experience. I can get behind that desire so here’s what I would recommend doing differently:

1. Ensure setup is ready from the beginning and that everyone uses it. As Phil is discovering, there are lots of different machine configurations to take into account. Get your setup testing started as soon as you have a build to hand out. I know a lot of developers like to have a "batch file" setup that has all kinds of special ways to get things installed on their machine. They do this to be "faster" or just to "avoid setup". That approach ends up being detrimental to the product because you are now maintaining two ways to install and the one that gets used the most (by the developers and testers for day to day stuff) isn’t the one that gets shipped. Finally, when setup is done at the last minute (like RC2) those design decisions that were made early may come back to bite you.
2. When you have a problem, make a plea to have anyone with a setup failure to send in log files. ASP.NET MVC is built for technically savvy people so it should be easy to post instructions on how to capture those logs. ASP.NET MVC also seems to have a pretty strong community built around it, so I believe they would have flooded the team with data.
3. With the data build a solution. I expect that a new MSI could be built to address the problems. Then you send the fix and instructions out to all of those with the problem.  It would probably be something like a recache/reinstall (msiexec /fv, a supported switch) over top the problematic install then uninstall. That way the machine stays in a known state and the setup incrementally improves.
4. With the data go improve other parts of the platform. ASP.NET MVC isn’t alone in their installation woes with NGEN and devenv /setup. By turning their installation problem into an opportunity to learn they can help improve other parts of the system that are shared with many products. Then everybody wins.

Original post by Rob Mensching

This was the week I was waiting for. Tonight we finally dropped the WiX toolset well under 30 bugs. Almost all of the bugs that have been "just about fixed" came in tonight and we killed double digit bugs.

First of all, several heat issues went away because Brian implemented a new id generation system that hopefully will make far more stable. You can read about the changes on his blog. Second, Jason is back from his honeymoon and put a serious dent in the DTF bugs. I expect that we’ll see most of these single digit areas all bounce zero bugs regularly now.

That leaves Votive. The Visual Studio team, who is now primarily responsible for Votive work, has been busy with internal integration work. Hopefully, we’ll see them pop in the next few weeks so that number starts dropping.

In any case, we’re at 25 bugs tonight and that feels good. I can’t wait to see what next week brings.

Original post by Rob Mensching

It’s been a few months now since the Windows Installer 4.5 redistributable was released [link]. Over the past couple months I have received several questions (quite often similar in nature) that warrants this blog post <grin>. In this post, I will attempt to answer some of the most frequently asked questions with regards to adoption & deployment of MSI 4.5.

1.       I’m considering taking a dependency on MSI 4.5 for my next release. I would like to know how prevalent MSI 4.5 might be in our target environments. Do you have any data on this?

We are pleased to hear that you are considering taking advantage of the new feature set and functionality provided in MSI 4.5. We have some data that may help you understand the current penetration of MSI 4.5 in the ecosystem.

a.       Statistics from the Microsoft download center:

As of March 2009, there have been over 5.6 million downloads of MSI 4.5 (combined across all supported platforms & OSes).

b.      Other ways in which MSI 4.5 is being deployed to users machines:

Yes, besides the fact that users are downloading MSI 4.5 from Microsoft download center, there are also other mechanisms via which MSI 4.5 is being deployed to users machines. For example;

-          SQL Server 2008 (both full server as well as express version) requires MSI 4.5 as a pre-requisite.

-          This dependency in turn has a cascading effect on other products that are already dependent on SQL Server 2008 or will be in the future.

c.       Future Windows service packs:

MSI 4.5 will be natively included in all future service packs of Windows. It is already included in Windows Vista and Server 2008 SP2. Release candidate for this service pack is presently available from the Microsoft download center.

2.       When will MSI 4.5 be deployed via Windows Update?

MSI 4.5 will be on Windows Update as part of future service packs to Windows (see #1, part c). It will not be available independently as a required mandatory update like Windows Installer 3.1 v2.

3.       Is it true that there is a forced reboot required on Windows Vista and Windows Server 2008 with MSI 4.5? Unlike Windows XP and Windows 2003, this reboot can’t be deferred?

Yes, it is true that servicing Windows Installer always requires a reboot on Vista and above. The new changes made to the Windows Vista servicing stack in combination with the change made by Windows Update to always have the Windows Installer loaded, causes the update to be “pended� until a subsequent reboot thus generating the mandatory reboot requirement when servicing the Windows Installer. We understand that a reboot can be difficult to absorb for applications taking a dependency on MSI 4.5. Unfortunately, none of the solutions that could be pursued were low cost and low risk enough to be acceptable at that point in the Windows Vista SP1 and Windows Server 2008 ship cycle. However, the growing prevalence of MSI 4.5 (details provided in #1), is mitigating the reboot issue to some extent.

4.       We are considering the possibility of bootstrapping Windows Installer 4.5 with our product’s setup. Is there a single 4.5 redistributable that can cover multiple OS versions and CPU architecture that is of a smaller size?

No, there is no single redistributable package to install MSI 4.5. There exist different installation technologies to install a Windows component like Windows Installer on Vista and above OSes versus down-level OSes (Windows XP and Server 2003). Additionally, the binaries itself are different based on OS version and platform architecture.

[Author: Zainab Hakim]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

Setting appropriate permissions for an object is one of the core operations in creating an application installer. One of the most frequent pieces of feedback has been to provide enhanced capabilities around securing resources installed on the system. MsiLockPermissionsEx Table in Windows 7 enhances the functionality over LockPermissions Table. With MsiLockPermissionsEx table, users now have the ability to set access permissions on objects impacted by the application install that previously required using custom actions or other methods outside of Windows Installer.

·         Expanding the set of permissions that can be applied to a resource by incorporating the Security Descriptor Definition Language(SDDL) in Windows Installer. This allows the security settings for an object to be more flexible, including;

o   Ability to apply Deny ACLs to objects

o   Indicate inheritance properties for permissions

o   Expand the set of well-known SIDs

o   Ability to set Owner, Group, and SACLs to the objects in addition to the regular access permissions

·         Security settings can be applied to services as well in addition to Files, Folders, Registry keys

·         Ability to apply permissions specific to user accounts – including accounts that are newly created on the system during the course of installation

FormattedSDDLText is a new column data type used by the SDDLText field of the MsiLockPermissionsEx Table to secure a selected object.

Q: How does new MsiLockPermissionsEx table change the semantics or behavior of the older LockPermissions table? A: Packages using the older LockPermissions table will continue to work as expected. However, we encourage you to author your packages targeted for Windows 7 and above to use the new MsiLockPermissionsEx table to take advantage of the power and flexibility provided by SDDL while customizing security settings for your resources.

Q: Can I author both LockPermissions and MsiLockPermissionsEx tables in my package?

A: No, in the interest of simplifying authoring and avoiding collisions, it is not allowed to have both LockPermissions and MsiLockPermissionsEx tables in the same package. If both tables are present, the installation will fail. ICE 104 verifies that only one of the two tables: MsiLockPermissionsEx or LockPermissions is present in the package.

Q: What happens if two conditions in different rows evaluate to true for the same LockObject/Table pair in MsiLockPermissionsEx table? Which SDDLText will be applied?

A: If a LockObject/Table pair has multiple conditional expressions that evaluate to true, the installation will fail. So, be careful while authoring your conditions: if you have more than one security setting in your package for an object – make sure the corresponding conditions are mutually exclusive.

Q: What happens if the SDDL specified in MsiLockPermissionsEx is incorrect, or if the user does not have permissions to apply the security settings described by the SDDL?

A: The installation fails if Windows Installer is unable to resolve the SDDL specified in the MsiLockPermissionsEx table into a valid security descriptor, or if the user doesn’t have the permissions to apply those settings, unless the package is blessed by an administrator.

Q: When is the resolution of SDDLText into the binary security descriptor done?

A: Unlike the older LockPermissions table, the resolution of permissions into the binary security descriptor for MsiLockPermissionsEx is done during the execution phase, at the time when an object is actually being installed. This is important because it means you can even set security settings referencing a new user account that is being created as part of the installation as long as the account creation is scheduled before the object is installed.

Q: Now that I can set security attributes on a service installed by a package via the MsiLockPermissionsEx table, can I do so with the LockPermissions table as well?

A: No, if you wish to set security attributes on a service, you will have to use the MsiLockPermissionsEx table. The behavior and semantics of the LockPermissions table will not change.

Q: My product has already been released. Can I use MsiLockPermissionsEx table to secure objects that are already installed? Can I use this feature to secure objects via a patch?

A: Similar to the LockPermissions table, you can use a patch to secure objects that are being installed on the machine with MsiLockPermissionsEx table, including objects that replace existing ones on the machine as part of the installation. If an object is not installed as part of the current installation, security settings specified in MsiLockPermissionsEx will not be applied to it. It should be kept in mind that a patch that includes either of these two tables – MsiLockPermissionsEx or LockPermissions – will be marked as not uninstallable.

Q: Will there be an ICE validation test to help me author the new table?

A: Yes, ICE 104 is being introduced to help validate the MsiLockPermissionsEx table.

 Q: Will this feature be available on down-level platforms?

A: No, as of now, this feature is being introduced only in Windows 7. Down-level platforms will ignore MsiLockPermissionsEx table, if present. See the table below for behavior on various platforms:

*“Default security settings� mean that if an object does not replace an existing object, it receives no explicit security descriptor: the access to the new object is based on the attributes of its parent or container object. If an object replaces an existing object on the system, the replacement gets the security settings of the object it replaces. If the replaced object had no explicit security descriptor, the access to the new object is based on the attributes of its parent or container object.

 [Author:  Ashish Awasthi]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Original post by Windows Installer Team

In Windows 7, Windows Installer provides enhanced native support for setup authors to configure services as part of an application install.

Starting with Windows Vista, Windows provides a powerful set of configuration options to configure services. These enhancements result in better security, performance and reliability for services. For example, the least privilege and resource isolation principles for services address security related issues by minimizing the vulnerabilities in a system. At the same time, delayed auto-start helps system startup performance by speeding up system boot time. Similarly, preshutdown notification for a service and improved failure detection and recovery options increase system reliability and a better end user experience.

MsiServiceConfig table provides options for configuring a service that is being installed or one that already exists on the machine by specifying the type of configuration as well as the parameters needed for that configuration. MsiServiceConfigFailureActions table is used to document failure actions that need to be invoked in the event of a service failure. This change takes effect the next time the system is started. Both these tables will be processed during the MsiConfigureServices action. The MsiConfigureServices standard action should be scheduled in the following order:

1.       StopServices – From ServiceControl table

2.       DeleteServices – From ServiceControl table

3.       InstallServices – From ServiceInstall table

4.       MsiConfigureServices – From MsiServiceConfig and MsiServiceConfigFailureActions tables

5.       StartServices – From ServiceControl table

Q: Can I configure a service already installed on the system with this table?

A: Yes, as long as the corresponding component is being acted upon (installed/uninstalled/re-installed), you can configure an existing service. This is similar to stopping an already existing service via the StopServices standard action. Make sure the user has the privilege to configure services.

Q: When will the changed configuration take effect?

A: Generally the configuration options take effect when the service is restarted. An option like delayed auto-start will be manifested when the system restarts.

 Q: Will this change the behavior of packages not using the new tables or the new standard action?

A: No, all existing tables and standard actions retain their current semantics. Packages not using the new standard action or the new tables will continue to work as earlier.

Q: My product has already been released. Can I use this feature to configure my services via a patch?

A: Yes, service configuration can be done via a patch. However, a patch that includes either of these two tables will be marked as not uninstallable.

Q: What happens if MsiConfigureServices action encounters an error?

A: The installation fails if MsiConfigureServices standard action fails. So, be extra careful while authoring these tables and ensure that the user has privileges to configure services if the package is not blessed by an administrator.

Q: Will this standard action work on down-level platforms?

A: No, as of now, the standard action MsiConfigureServices is introduced only in Windows 7.

Q: Will there be an ICE validation test to help me author these new tables?

A: Yes, ICE 102 is introduced to validate the two new tables.

[Author:  Ashish Awasthi]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

It might not look like it but we made progress on WiX toolset bugs tonight. There is a fix inbound for the remaining candle and pyro bugs. The documentation bug is actually something on the MSDN side of things, I believe. Votive and DTF still are not seeing progress due to missing members. Net we’re up 3 bugs from last week with 35 as the total.

The most interesting news on the bug front is that Brian has almost completed the mission I sent him on to apply everything that we’ve learned over the last couple years about generating MSI identifiers to heat. It changes a lot but I believe the changes will address the core weaknesses in heat that are the focus of the bugs. Brian said he’d do a detailed write up after he gets everything checked in… which hopefully is next week.

Finally, one of the reasons the resolve rate was lower this week was that Eric tracked down a second performance issue in the WiX toolset. I already knew there was a performance problem in the smart cabbing feature but Eric found a slowdown in the .wixpdb generation introduced in the last month. There have been a couple random mentions of performance degradation but this was the first time we had a repro that we could dig into. We’ll have fixes for those performance issue soon.

In the meantime, keep coding. You know we are.

[Sorry, this is delayed, been having server issues.]

Original post by Rob Mensching