Monthly Archives: January 2008

Another Trying Day

Sadly, this has become an all too common occurrence…. I have to ask for your prayers again. Tomorrow my wife will be having yet another surgery as part of her war against cancer. This time the goal is to remove a tumor from her right lung. We won’t know which procedure the Doctor will ultimately choose until he’s had a first hand examination, but right now it looks like she’ll be in the hospital for 3-5 days and possibly as many as seven.

So please forgive me as go offline for a few days. Perhaps Aaron will say a few words in my absence. Maybe something like “VBScript CA’s Don’t Suck, CANCER SUCKS”.

Development Tools Diversity

I’m curious as to the ecosystem diversity of my readers so please take the new poll over on the right.

I’m interested in truthfulness here please! You may select as many as you like, but I ask that each one you select be truely represented as a tool you use to ship a production install. If you’ve only played with a tool but don’t otherwise ship product with it, please don’t select it.

Mailbag: Adventures In Server 2008 Logo Certification

A recent blog article about Server 2008 Logo Requirements generated some interesting feedback from Colby. I asked him if he minded if I reposted it here and he approved so here goes:

I’m not really responding to any of your comments directly. I’m just throwing stuff out there as someone who is currently going through the Windows Server 2008 Logo Certification for my product.

Most of the problems I’ve had to date actually come from the application code side rather than from the install/MSI package. For example, all binaries (executable files, activeX controls, dynamic link libraries, etc.) must be digitally signed as well as have the appropriate requestedPrivileges attribute set in a manifest (either embedded or external manifest). This can be quite annoying if you have a lot of legacy applications to distribute. We actually have legacy binaries compiled using Borland, Delphi, and a couple of other non-Microsoft compilers and those binaries don’t accept a digital signature. Other issues relate to kernel mode drivers not being properly authored to meet Microsoft standards (all drivers installed by a logo certified application must be signed by Windows Hardware Quality Labs [WHQL], pass all WHQL tests, and pass all driver tests in the certification tests). That requirement can also be a problem for companies that compile their services to run on different platforms (in my experience, those are the ones most likely to ignore the Windows standards – whether intentionally or not). These have been my two biggest problems so far. The installation requirements for certification (Chapter 2 of the Windows Server 2008 Logo Certification Framework document, see link below) are pretty easy to follow if you’re using MSI [and I agree w/ you that Robert can’t be blamed for not knowing that MSI was dropped as a requirement – the latest framework document was just released on 1/8/08!, which is another annoying part of this process: MS keeps changing the rules before 2K8 even ships!). Evidently, we’re not the only ones having these problems (as Application Compatibility for Windows Vista forum shows [RSS=]). In fact, our VeriTest contact has mentioned that a only a very low number of applications have actually been certified thus far.

If anyone is considering Windows Server 2008 Certification, I HIGHLY recommend installing the Certification Tool and using it to do all your Vendor testing. It is the exact tool that VeriTest will use to run the tests and is quite easy to use. In fact, I created a VM for our employees to use that has everything installed for testing and includes recommendations for how to set up the Certification Tool (requires a SQL database to connect to). A copy of the readme is below and shows all the applications and tools necessary to run the certification tests. Most people start by downloading the Microsoft Certified for Windows Server 2008 Application Test Framework document ( and struggling through it (currently 230 pages). But if you just download the Word doc and then install the Certification Tool, the tool will pull in all the requirements from the document and is a MUCH easier way to start the in-house Vendor testing required prior to certification submission.

Basically, anyone doing this should START HERE:

I hope this helps your readers who may be looking for Windows Certification!!

How do I add the elevation shield to my Vista install?

I have had people ask me this question a couple of times, and I figured I would post a quick note on how to do this. You could start by looking at the SDK article devoted to the PushButton control. You will notice that the PushButton control has an ElevationShield attribute.

By setting this flag in the PushButton control’s attributes, it will cause the elevation shield to display on Windows Vista systems. Generally, your install will have a “Ready to Install” dialog with a Next or Start button on it. This is a good place to have the elevation shield. You would set the attributes flag as such:
1 – Visible
2 – Enabled
8388608 – ElevationShield

The total for the attributes column would be 8388611. Most of the recent versions of the commercial setup products will set this attribute for you with a simple checkbox producing a dialog similar to the following on Windows Vista:

Vista Server Logo Requirements Revisited

Recently I was watching a video on Channel 9 called Application Compatibility – MSI Installer ( re: Vista / Server 2008 ) where Robert Flaming of the Windows Installer team made a brief opening comment that the windows server logo has a requirement for MSI for the first time.

Now I’m sure Robert didn’t think this opening remark would attract so much attention because it really isn’t the focus of the video. Still it jumped out at me since back in September I blogged about a friend sent me an email detailing that MSI was dropped as a requirement for the Vista Server Logo program. I was really curious to find out if Robert had simply misspoken or if my information was wrong our out dated.

Recently Robert communicated via the Windows Installer team blog:

In recent multi-blog conversations between Windows Installer experts Aaron Stebner, Christopher Painter, and Stefan Krueger, it was noted that my statement that ‘Windows Server 2008 logo would require Windows Installer’ in the Channel 9 video Application Compatibility – MSI Installer Issues was out of sync with the published requirements.

Sure enough, the Windows Server 2008 Logo team demoted this from a requirement to a recommendation. Unfortunately the Windows Server 2008 Logo didn’t let me know they had decided to do this.

Robert also went on to accept responsibility but I feel this is completely unneeded as it isn’t his fault that a requirements change wasn’t communicated back to him. Regardless, the question is now answered and I’m very grateful to Robert for doing so. More importantly though he gives very good perspective into the `why` so I highly encourage you to read the blog.

I only have two additional comments related to the `why`. First is I’ve seen many times in my career that developers/managers grasping at straws to put together a installation requirements or design document together will reference the logo requirement by proxy. From Roberts comments the logo program is a marketing program not a standard program so this association may be incorrect. Still it’s sometimes difficult to put installation requirements to paper so I doubt that this practice will end.

The second comment is somewhat a question: For those of you in IT organizations, what attitudes do you see towards server care and feeding versus workstation care and feeding?

The reality is, from perspectives, a server is just a glorified workstation. You would think that MSI would automatically be good for both. In my current role at an ISV I have adopted MSI for my server installs as well as my client installs.

However, I remember at Continental Airlines that many people were very skeptical of automating server side deployment. Sure there were a few visionaries like the Sr. Director of Technology that I worked for who wanted to be able to use a graphical designer tool to cause the provisioning and configuration of a brand new blade through tools like ADS, DSI, GPO, AD, SMS and MSI. But many people who otherwise adjusted well to client side automation would get very defensive when you started talking about changing server side processes. If you suggested replacing an old, incomplete, outdated manual process with a zero touch automated process they would be practically afraid to death of the change. If you suggested using GPO, SMS or WSUS to manage these servers they would freak! I don’t know if it was inexperience or just protectionism, but the moment you started mentioning production servers everything had to be done by hand.

So perhaps the server community isn’t really ready for MSI yet anyways. What does your experience tell you?

A New(er) Look

I was looking at my profile the other day and I realized that my pictures were really old and somewhat misrepresenting of my appearance. I’ve never really spoken about this online… last summer I shaved off all of my hair.

This is the second time I’ve done this in my life. The first time was at a little place called Marine Corps Recruit Depot Parris Island. The second time was when I found out that my wife’s cancer had returned. When she was first diagnosed we were told that the drugs she would be taking would not cause hair loss. However, the second time around was a different story. There was just no way I’d let her lose her hair all alone so off it came. I only wish that baldness actually bothered me so that it would be more of a sacrifice.


I’m working on an install that requires me to write some custom actions to interact with the certificate stores. I seems there are four different ways to do it out there:

certmgr.exe : The way the developer suggests doing it. Of course it’s a .NET SDK utility with redist rights.
cryptoAPI : Win32 API
CAPICOM : Scriptable COM
System.Security.Cryptography.X509Certificates : .NET Framework

After a whole lot of digging I decided ( for now ) to settle on CAPICOM. I found the CAPICOM SDK and example VBScript file that shows how to load a certificate into the store. I quickly ported that over to InstallScript and bingo, it all worked.

Of course there is a catch. This has added a dependency to CAPICOM.dll to my install. This wouldn’t be so horrible except the Microsoft team that created CAPICOM obviously doesn’t have the first frigging clue about how Windows Installer works. They seem to think that xcopy to system32 regsvr32 is the appropriate way to deploy this ActiveX control. There are tons of references that say CAPICOM is redistributable but the only MSI available is for the entire SDK. There is no merge module or prereq package containing just the ActiveX runtime control.

So I do some googling and I find an old thread from WiX-Users with a good discussion on the component rules and why this is a problem. Finally I stumbled across a Windows Installer log file that indicates Visual Studio C# Express deploys the file to C:ProgramFilesCommonFilesMicrosoft SharedCAPICOM as ComponetID {9504EA7B-206D-4178-8E37-EF70AE544903},.

Ugh, Can we say DLL HELL?!?!?

Well I suppose since the application I’m deploying targets .NET 3.5 that I could just go ahead and use the x509Store class that’s in the .NET BCL but 1) I haven’t tested that yet and 2) Microsoft employees keep trying to convince me that managed code custom actions are evil while at the same time they compain that other infrastructure API’s don’t target the CLR. ( Yes, notice even Rob Mensching joining in wishing that Windows Error Reporting supported .NET! )

Finally I found a Code Guru project using CryptoAPI writtten in C++. I tried running the sample exe but wouldn’t you know it…. it was a debug EXE with a dependency on MFC42D.dll.

The cryptoAPI example is probably the purist way to go in terms of eliminating the dependency but jeesh, it shouldn’t have to be this hard. What’s 3 lines of script becomes pages of C++.

I once mentioned capicom in a previous post and now I know why I get so many hits for it on my statcounter.

Someone please slap me and remind me that I actually LIKE setup!

Good, Bad or just Different?

Aaron Stenber has a rather interesting article discussing a novel approach used to author recent Microsoft packages such as Silverlight 1.0 and the .NET Framework 2.0SP1/3.0SP1.

Basically these setups are authored as fake MSI’s that then get Major Upgrades applied as patches. The UI is outsourced to an external UI handler and the whole thing is packaged up into a custom self-extracting bootstrapper.

I have to admit, when I first read the article my first reaction was something along the lines of `What the heck???`. The design is so different to other servicing stories that I’ve seen that I had to email a trusted friend of mine for his reaction. His answer to me was:

I don’t think you’re missing anything. My initial reaction is a mix of “wow, what a hack” and “does this mean they admit MSI’s model is too limited?” The empty MSI + patch is cute, because it gets around InstallShield’s lingering cache-web-download file problem, but it just highlights that MSI should have had better options for caching the original MSI rather than wasting one of your patches as a workaround. A custom bootstrapper, custom external UI code, etc., are the only way to make installs like this bearable.

I want to be honest, I’m trying to keep a very open mind with this design. I am somewhat saddened that it has come down to this. I sometimes find myself wishing that merge modules and concurrent installs worked. It would be so nice if you really could isolate and package all of your third party dependencies into a nice, clean, single MSI package that could be loaded into a GPO advertisement. It would also be nice if GPO could understand how to apply transforms and/or set public properties. It would be nice not to have chainers and external UI handlers and to not have to decide how our servicing strategy would be in advance.

A Look at the Windows Installer Tao Part 4 shows:

Rule 41: Design and Test Your Servicing Strategy Before You Ship the Initial Product

Rule 42: Author Packages to Avoid Source Requirements During Patching

I guess in a sense this latest design is the ultimate expression of these two rules. For example the .NET 2.0SP1 performs a Major Upgrade of the 2.0 RTM and in effect calls a mulligan. For clean installs it basically accomplishes the initial deployment by using the expected servicing strategy thereby eliminating the potential pitfall of being in production before you figure out what your strategy will be. Furthormore by not deploying components in the base MSI you avoid running afoul of rule 42.

Still, a part of me is still scratching my head thinking “Wow, is this really how MSI is meant to be?”. After all, these packages look and feel to a Systems Administrator a lot more like legacy setup.exe packages then MSI packages. For example the Microsoft Silverlight Deployment Guide makes no mention of GPO advertisements using MSI. Instead they mention wiring a batch file up to a machine starup script to fire the exe from a UNC path.

I sure would love to see a follow up discussion from various parties including the Windows Installer team. Is this just an ad-hoc approach used by certain teams from within the Microsoft firewall or is this the future best practices that tools like ISHNMET should be supporting?

PatchWiz Kaboom!

Recently I was reading a thread in microsoft.public.platformsdk.msi where Jim Keir stumbled into a whopper of an MSI bug:

I’ve found a huge, steaming bug in PatchWiz 4.0.6000 . Under some circumstances, sadly those described in the SDK patching example, it can erase all writeable files on your drive.

To reproduce (carefully):
– Provide suitable PCP and source/target folders
– Call UiCreatePatchPackage with the optional hWnd parameter set to NULL and RemoveTempFolderIfPresent set to FALSE. Harmless, right?

Internally (I’ve debugged this) the ascii version convert the strings to wide-char and then pass them to UiCreatePatchPackageW . This unconditionally sets 0x8000 in the flags field, then it passes it all to UiCreatePatchPackageExW . That bombs because the UIALL flag (0x8000) is set and the window parameter is null. The error-handling then kicks in but it appears that some internal defaults haven’t yet been overwritten. It tries to delete the temp folder despite being told not to both in the function call *and* the PCP, and also hasn’t yet set the temp folder location. It seems that another internal call fails (code 87) with the result that it deletes
every writable file on the drive.

The corresponding logfile line is:
ERROR: During cleanup, could not delete the temporary folder: .

Rather annoyed. As you might imagine. Don’t believe me? Go ahead and try it 😉

Furthor posts seem to confirm that this bug is real. Fortunatly I still develop on Windows XP with InstallShield 2008 so fortunatly I’m still on PatchWiz.dll3.1.4000.2049.

Still, something to watch out for, especially if you are tools developer or roll you own kind of guy.

Fighting Windows Installer

The other day a simple question was asked on the WiX-Users mailing list:

…I would like to Create a “major” upgrade installer, even when only the
fourth field of the Product Version has changed.

To which Windows Installer defender and Microsoft employee Bob Arnson proclaimed:

“Doctor, it hurts when I do this.” You know the rest. It might be possible
to make it work but you’re fighting Windows Installer, which doesn’t support the
fourth field in a product version for upgrades.

Well considering the number of doctors that I’ve been to in the last year I know how I’d respond to that one. Time for a second opinion!

Sometimes working with Windows Installer is all about fighting Windows Installer. Don’t believe me? Check out the LockPermissions table for starters.

For some reason Microsoft decided that when following an a.b.c.d versioning pattern that a change of d just doesn’t qualify as a major upgrade. Why? It’s just a version number for heavens sake. That business logic is entirely too coupled. The decision to go with a major upgrade should be driven by the change in components and feature structure and servicing experience desired not by the version. If a minor upgrade won’t do the trick and SCM/Program Management says you are going from to well that’s that. You need a Major Upgrade.

As an aside, I never agreed with the definition of a Small Update. A Small Update is basically a Minor Upgrade ( change of PackageCode but not ProductCode ) with the exception the ProductVersion does not change. What?? The SCM practices of everywhere I’ve ever worked would never allow that. Once is fielded it’s immutable. You must increment the version to show uniqueness. The only reason I can think of doing this is when you are trying to sneak a fast one under the radar.

Anyways, back to the question at hand: This is actually pretty easy to do. You just have to understand how FindRelatedProducts and RemoveExistingProducts work together. The former reads the upgrade table to know which products are to be searched for and which ActionProperty to put the data in. The later reads the table to know which property to expect to find the data in. The real work is performed by RemoveExistingProducts. A Type 51 custom a CA scheduled between the two would easily allow you to bend the business rules implemented but not exposed by FindRelatedProducts.

BTW, stay tuned to a future blog post where I point out how the .NET Framework install is a complete hack ( sorry, clever WiX based solution invented by Microsoft employees who should be worshipped ) that works against Windows Installer .

Seriously, what else could you call an empty MSI that is then patched with a full MSP and serviced by a bootstrapper and external UI handler just to get around the nasty database caching story that Windows Installer has. You know the one that strips out cabs and invalidates digital certificates causing annoying dialogs like “Please Insert The Stupid Media” and “Unkown Publisher”.