I was talking with @fyip on Twitter yesterday, and he told me that he installed the Geneva Framework and Server on a Windows 2003 Server machine. I asked what he had to do to get the installer to work on a non-Vista, non-Longhorn OS. He said that he installed Orca, changed the LaunchCondition VernsionNT value from 502 to 501 as show in the following screenshot:
I did the same thing on XP, and it installed great:
Next came the fun part: spelunking through batch scripts to figure out how to configure things, so the samples could run and the install could be verified. To this end, I installed the Windows Server 2003 Administrative Tool Pack which includes the only version of certutil that runs on XP. I also had to download choice.exe from the Windows 98 Resource Kit (yikes!) which one of the batch scripts depends on. Then, I opened a Visual Studio 2008 command prompt, CDed into "C:\Program Files\Microsoft Geneva Framework\Samples\Utilities\Scripts." I then popped open SetupCert.bat that's in that directory, and changed line 80 from this:
pushd "%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys"
Then, I ran that script passing localhost as the name of the cert's subject and root as the store name like this:
SetupCert.bat localhost root
I was prompted to overwrite the existing cert that had a subject of localhost (which got there IINM by running the script a couple of times as I tried to get it working).
Next, I had to setup the SSL configuration in IIS. I did this by opening the IIS management applet, selecting properties from the context menu of the default web site, and clicking the Server Certificate button on the Directory Security tab. In the wizard, I opted to assign an existing certificate and chose the one issued to and by localhost.
Finally, I ran iisreset.
Running the Samples
I tested out the "Simple Claims Aware Web Application" sample included with the SDK. To start with, I needed to create the virtual directories. I took a chance and ran the CreateSampleVdir.bat in that sample's directory fully expecting it fail. To my surprise, it seemed to work. Then, I popped open the 2008 edition of the solution and compiled it. I alt-tabbed over to my browser and entered in https://localhost/PassiveRedirectBasedClaimsAwareWebApp/. This resulted in an error saying that The current identity (MyMachineName\ASPNET) does not have write access to 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files'. I fixed this by running this command:
C:\WINDOWS>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -ga MyMachineName\aspnet
I then was presented with this error:
Parser Error Message:
ID1024: The configuration property value is not valid.
Error: ID1039: The certificate's private key could not be accessed. Ensure the access control list (ACL) on the certificate's private key grants access to the application pool user.
So the changes that I made to the SetupCert.bat script above didn't seem to work. To fix this, I opened "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys". Which of these was the private key? Luckily, I still had the console window open where I previously ran SetupCert.bat. At the end of that script, it said which one was the private key. I opened the properties dialog box for this file, and granted the ASPNET user read and execute permission. Once I applied these settings and hit the Relying Party (RP) in my browser again, I was prompted for my Windows credentials. I entered them, and was logged into the STS who shipped me back to the RP where my correct identity was displayed!
This was a heck of a lot of work just to run on XP. I sincerely hope that Microsoft ends up supporting XP when the Geneva Framework RTMs. If you have an IT department that won't support anything but XP or have customers that require this older OS, but want to develop with Geneva, please let Microsoft know. Go to the connect Web site, and provide them with feedback saying so and/or post a comment on the Geneva forum.