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:

Chris,
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=http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=904&SiteID=1]). 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 (http://microsoft.mrmpslc.com/InnovateOnWindowsServer/redirect.aspx?u=http://download.microsoft.com/download/7/9/5/7959e7ea-f788-41cb-8b57-67bd122eb9b4/WindowsServer2008SoftwareLogoTestFramework.doc) 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:
http://microsoft.mrmpslc.com/InnovateOnWindowsServer/Resources.aspx

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.

CAPICOM ... UGH!

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:\ProgramFiles\CommonFiles\Microsoft Shared\CAPICOM 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!