Vlad Hrybok's Tech Notes

If your ASP.NET 1.1 or 2.0 application throws "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms" exception, the easiest way to fix is to add 
      <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>
line to the <system.web> section of the web.config file of your application.

FIPS compliance is required for software installed on US government computers. The compliance requirement can be turned on and off.

Source: http://support.microsoft.com/kb/911722

I went through the exercise of setting up Microsoft Team Foundation Server 2008, and needed to do group-level-only rights assignment, so that IT folks could manage security by simply moving people in and out of the Active Directory groups to grant/revoke TFS access rights, instead of setting up individual user rights in TFS, Windows Sharepoint Services and Reporting Services. Initially I created some groups for TFS with the "Domain local" scope, which allowed me to nest other, "Global", groups in them. But I noticed that with WSS and RS, assigning rights to "Domain local" groups does nothing - WSS and RS act as users are not members of the group, while TFS services were working properly. I had to re-create AD groups and make them of "Global" scope to make WSS and RS working properly.

In Windows XP one could just double-click an .MSI (Windows Installer) file to start package installation: MSIEXEC.exe is associated with the .MSI extension and if user had administrator rights installation would go forward. Clicking .MSI file was functionally identical to running Setup.exe bootstrapper, provided Setup.exe didn't have additional functions other than starting the installation.

In Windows Vista things are different. When Vista's User Account Control (UAC) is turned on, launching Setup.exe is not quite the same as running MSIEXEC.EXE /i mypackage.msi. The difference is that when Setup.exe is started, Vista runs it in "elevated" mode, which gives the process more privileges. MSIEXEC.EXE does not seem to run in elevated mode and therefore behavior of the installation may be different.

The issue seems to be manifesting itself most often when an MSI setup package made using Visual Studio executes custom action steps implemented as an Installer class. I am not sure what exactly happens but I noticed that MSI error 2689, which is a common result of failed custom action, will go away if installation initiated using Setup.exe instead of just clicking on .MSI file.

Bottom line: On Vista always start installations by launching Setup.exe instead of double-clicking .MSI file.

Another possibility to consider: if you were not a victim of computer virus attack in the last five years (Windows XP lifetime), then you are may want to simply turn Vista UAC off.

When security experts get together with lawyers we end up with security features that shield software publishers from liabilities and don't do anything to improve security - just think of all the overly complicated, impossible-to-remember passwords forced upon us, with passwords end up written on the post-it note stuck to your monitor. So much for security. The same thing is Vista's User Account Control. UAC pops up so many security warning that after just one day of using Vista I stopped reading them altogether. After one more day of playing whack-a-security-warning, I decided that time is right to turn User Account Control off for good.

To turn UAC off start with launching Control Panel: Start -> Control Panel, and then type "turn user" in the search box and then click the "Turn User Account Control (UAC) on or off" link:

Then UAC screen will appear. Just clear the check box and hit OK button. Vista will probably require rebooting.

Once you have rebooted, your life will be back to normal, except the nagging red shield icon in the icon tray reminding you are truly extreme person living on the edge.