The other day we were experiencing the same issue as described in OpenAM issue 308: when using the policy agent on multiple IIS sites, the agent configuration of the site serving the first request "wins". The great thing of open source software is that you can look at the source code!
We learned from the agent source code that it uses a global variable readAgentConfigFile to flag if it has already processed the agent configuration file or not. We had a feeling that this could be causing the issue but weren't certain until our co-worker Thomas from Exsertus explained to us that if sites share an Application Pool, they run in the same process. This means that there will be only one global variable in C and C++ code per process but this variable will be shared between multiple sites and thus OpenAM policy agent instances. This explains why every OpenAM policy agent shares the "winning" configuration file.
And now for the solution? We assigned every site its own Application Pool, a practice which the customer was already applying on its production IIS servers. But in my humble opinion, that's only a workaround.
Identifying with your business
