The matter is most likely related to issues with metabase.xml cloning.
You could find the following reply from one of our clients helpful:

"
Based on our investigation, it didn’t even seem to load the Isapi filter, but it did not error, and the process ran the page, just not the
Isapi filter.

You mentioned that you were seeing an error from aspnet that it was unable to see the private bytes. That was attributed to the fact the
IIS_WPG group was copied from another server, and therefore not recognized in the AdminACL property on the servers that had copied the
metabase.

You re-copied the working NLB1 metabase to NLB2.

You then used metabase explorer<http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17275>; to check AdminACL - and you found
it in a few different places without the local IIS_WPG group. You removed the unknown SPID from the list and then added the local IIS_WPG
group.

You added the correct IIS_WPG group to these levels, with the appropriate permissions - and after that the Isapi filter seemed to be running.

Like I was telling you, this is very likely never an issue if you’re not running in an IIS6 web farm environment and not using IISSYNC to copy
metabase settings across servers. However, if that is the case, then this issue will almost certainly exist unless the administrator is
explicitly guarding against it. In fact, Microsoft no longer recommends using the IISSYNC command because of these very issues.

Here’s a screencast of me using MetabaseExplorer to examine the permissions that are listed above.
http://screencast.com/t/nykPuQx8F1Qq
"

If it's not your case, please give some details on how you perform cloning, whether ISAPI filters load etc.