これらは2つの異なるものだからです。IIS_IUSRSは、IISワーカープロセスアカウントのグループです。これは、アプリケーションプール自体が実行されるIDを意味します。IUSRは匿名ユーザーIDです。これは、IISがサイトにアクセスしているユーザーであると考えるIDを意味します。
さて、あなたがそれを言わなかったとしても、私が推測させてください-このアプリは古典的なASPですか？（そうでなければ、それが.Netの場合は、偽装を使用している必要があります）。どちらの場合も、リソースは偽装されたID、つまりケースでは匿名ユーザー、つまりIUSRとしてアクセスされます。それがあなたにそれに権利を与えなければならない理由です。.Netでは、偽装をオフにすると、IIS_IUSRSが期待どおりに機能するようになります。クラシックASP（および静的ファイルの場合）では、選択肢はなく、偽装は常に「有効」です。したがって、常に使用されるユーザーIDであり、プールIDではありません。したがって、IIS_IUSRSはプールID用であるため、機能しません。
OPがさらに情報を追加した後に編集：
IUSRとIIS_IUSRSは、名前が違うため、混同しやすいです。それらが異なることを確認する方法は、IIS_IUSRSが、ワーカープロセスグループであるIIS6のIIS_WPGの代わりであることを覚えておくことです。これらのグループには、匿名のIDではなく、プールを実行するアカウントを追加します。匿名の特権はより制限されているはずです。例えば。場合によっては、ドメインアカウントを使用して、他のネットワークリソースへのKerberos委任用のプールを実行することができます。次に、そのサービスアカウントをこのグループに追加します。
偽装が有効になっている場合、プール/プロセスは、指示されたため、ユーザーであるように見せかけます。anon auth（あなたの場合）の場合、そのユーザーはIUSRです。Windows認証の場合は、ユーザーのWindows \ドメインIDになります。これは、プロセスがリソースアクセスのために別のIDに切り替える必要があるため、偽装によってパフォーマンスが低下する理由でもあります。
.NETと匿名認証を使用している場合は、偽装を有効にする理由がわかりません。偽装を使用していない、または必要がない場合は、IIS7の場合のさらに細かい点に注意する必要があります。IUSRを完全になくして、すべての混乱を終わらせることができます。私はあなたがそれを望んでいると思います、そしてそれは私の好みの方法でもあります。必要なのは、プールIDを匿名IDとして再利用するように指示することだけです。
したがって、この後はIIS_IUSRSグループのみを処理する必要があります。しかし、混乱しないでください。これは、これら2つが同じであることを意味するものではありません。プロセスIDがIUSRの代わりになる可能性がありますが、その逆はできません。
注意すべきIIS7のその他のトリック：IIS_IUSRSを見ると、空である可能性があります。これは、プールの起動時に仮想プールIDが自動的に追加されるため、これらのことを心配する必要がないためです。
この表は、スレッド実行IDがどのように決定されるかを明確にするのに役立ちます。
偽装匿名アクセスリソースとしてアクセス
有効有効IIS5 / 6のIUSR_computerまたは、
IIS7のIUSRまたは、
anonユーザーアカウントを変更した場合
IISでは、そこに設定したものは何でも
有効無効MYDOM \ MyName
無効有効NT Authority \ Network Service（プールID）
無効無効NT Authority \ Network Service（プールID）