The .NET Framework SDK ships with a MMC Snap-In which enables you to, among other things, avoid using caspol to modify your local security policy.
Since each runtime installed on your machine has independent security policy, the MMC Snap-In will only modify policy for the version of the CLR it is running against, and you may need to have multiple MMC sessions to change the various versions of policy on your machine.
This is pretty obvious when it comes to changing the v1.1 policy vs changing the v2.0 policy, you just choose the correct link from Control Panel. However, things get a lot trickier when it comes to configuring v2.0 32 bit policy vs v2.0 64 bit policy.
The snap-in only modifies the security policy of the runtime that it is running against. Since the snap-in itself is running within the MMC process, this means that the policy that is being changed depends on the bitness of the MMC process. (Remember a 32 bit process cannot load 64 bit components, and vice-versa). Since the snap-in is processor neutral, it will happily load in both a 32 and 64 bit MMC -- leading to the surprising result that running the version of the snap-in that ships with the 64 bit SDK in a 32 bit MMC will result in changes to the 32 bit policy, not the 64 bit one.
Further muddying the waters is the fact that MMC has somewhat surprising behavior when launching it from the command line. One of our testers put together this table to help figure out which bitness of MMC is being launched:
MMC will actually occasionally terminate the version that you stared and relaunch a verison with a different bitness (details can be found here). What this means is that it doesn't really matter if you launch the 32 or 64 bit version directly when using the .NET Configuration Snap-In. Instead, you should be sure to pass the /32 or /64 command line switch to MMC in order to ensure that you get the version that you intend.