I've nearly given up blogging as you can probably tell by the gaps between my posts these days and am uncertain whether I'll ever get that going again or not.  Who knows?  However, something weird happened today related to ADFS that I thought might be worth a post that I decided to document for posterity.

Essentially, a colleague of mine at work was trying to install the ADFS Web Agent on a Win2K3 R2 server using the standard method of "Add/Remove Windows Components".  The OS was running on a VM with the image built through some mechanism that neither of us had any firsthand knowledge of.  Essentially, when he tried to run the install, he got an error saying basically that the install failed.  In the event log was something similar pointing to a log file that showed the command line used to run MSIEXEC which in turn included a command line option to provide additional logging in another file.  That file was very short by MSI logging standards and basically recorded the error "1620" which translates to "not a valid intaller package":

C:\>err 1620
# for decimal 1620 / hex 0x654 :
  ERROR_INSTALL_PACKAGE_INVALID                                 winerror.h
# This installation package could not be opened.  Contact the
# application vendor to verify that this is a valid Windows
# Installer package.
# 1 matches found for "1620"

This is weird!  The file c:\windows\adfs.msi is not a valid installer package?

So, I grabbed the file and copied it to a machine that has Orca installed.  Orca is a tool used by MSI developers to examine the contents of MSI databases (you can get it for free with the Platform SDK tools).  When I opened the database, it was clear that this was not actually an MSI database at all but instead an MSI patch database (usually a .MSP file).  Strange.  When I went back to the server and looked, there was also a file called ADFS.MSP in C:\windows with the same size.  They turned out to be the same file with different names!  So, something had dorked up the file images associated with the ADFS component.

• To solve the problem, I first did a file search for adfs.msi and found a copy in an R2 source directory locally
• I then copied this file into the c:\windows directory (after renaming the other file "just in case")
• Then, upon running Add/Remove Windows Components, the installer started to work correctly.  I WAS reprompted to provide the location of "adfs.msi" and put in the file path to the R2 source where I found it.  After that, all was well.  Hopefully the patch got applied correctly as well (I didn't check). 

I have no idea how the box got dorked up or if this affects anyone by my colleagues on our servers, but I thought it was worth mentioning. This is the first time I've ever had any success troubleshooting an ADFS installer issue, so it seemed worthy of a post.  :)