Consider whether you really need hot failover. If you're worrying about price at the level of an entry level SAN then consider whether you really have a business case for that recovery model. How expensive is your downtime for an outage?
If the cost of an outage justifies the cost of a decent SAN, buy it and don't penny pinch. Otherwise, consider other failover models. If your downtime is not so valuable, you can probably tolerate a hot standby model where the database is replicated to another server with local disk. This takes longer to recover but does not need shared disk storage. If this works for you then you don't need a SAN and the local disk on the servers will probably be much cheaper.
Another option would be the secondhand market. You can get a re-certified second hand Clariion CX200 or CX300 (which would probably do what you're after) for just a few thousand dollars. Re-certified hardware qualifies for vendor support and can be purchased through various outfits such as www.berkcom.com or www.bltserv.com.
(Disclaimer: I have no affiliation with either vendor but am a satisfied customer of BLT Services. Berkcom was recommended to me when I needed something that BLT didn't have).
Associating the files with patches.
The "WINDOWS\Installer\" folder has several key sub-folders.
You can search for the sub-folder name (without the braces {}) in the registry.
The key can be searched within the "HKLM\SOFTWARE\" tree
to get the Software association.
The key would be placed in the Installer sub-tree on the name ENU_GUID.
Similarly, in the registry path "HKEY_CLASSES_ROOT\Installer\Products\",
The key will usually match in a subtree against the "ProductIcon" name.
There will be a "ProductName" field next to it that will give you an association.
This search should be script-able with a dir WINDOWS\Installer /d output
stored to a text file that is processed with a registry search.
The .MSP files have a level of indirection in the registry.
You should search for the MSP name first in,
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\
That will give you a Patch number (the sub-tree name string) which is to be then searched again in the same path as above. The associated registry sub-tree will give you details for the patch.
Meanwhile, the mouse-over context in my Windows XP explorer also gives basic information on the patch. Have you checked that already?
Older data:
Use msizap to remove orphaned cached Windows Installer Data Files to increase free disk space.
Msizap is a command-line tool that can delete the configuration data that Windows Installer maintains for products that it installs, including the directories, files, registry subkeys, and registry entries in which Windows Installer stores configuration data.
Running msizap.exe with the G parameter removes orphaned cached Windows Installer data files for all users
The article discusses up to Windows Server 2003.
Update: This Microsoft KB description also limits at Server 2003.
It should work for Server 2008, or there would be another version for it.
The article describes existence of two versions.
There are two versions of MSIZAP.EXE:
MsiZapA.exe (for use in Windows 95, Windows 98 and Windows ME), and
MsiZapU.exe (for use in Windows NT, Windows 2000, Windows XP, and Windows Server 2003). The appropriate executable should be renamed MsiZap.exe.
Download references -- in case that link goes dead.
Msizap can be downloaded as a part of the Microsoft Windows Server 2003 Support Tools or the Windows Installer CleanUp Utility (EXE). I was unable to find the Windows Installer CleanUp Utility by searching Microsoft’s download site, so note that as of today the file’s name is msicuu2.exe if you the above link goes dead in the future.
If you don’t want to install the Windows Installer CleanUp Utility, use a program such as Universal Extractor (aka UniExtract) to extract the individual files. Once you extract the files, you’ll notice msizap.exe does not exist, but you will find MsiZapA.exe and MsiZapU.exe.
Best Answer
I would agree that 40 GB would be the minimum C: partition. I prefer 50 GB.
The reason for this is the escalating disk usage of the Windows side-by-side folder (%systemroot%\Winsxs). This is currently 10 GB on my R1 server, and it continues to grow over time. I would allocate 20 GB just for this folder for the lifetime of the server.