IIS 7.5 ApplicationPoolIdentity Permissions

I am having some difficulty setting the permissions for the AppPoolIdentity correctly.

The error shown in the Failed Request Logs is:

ModuleName="IIS Web Core", Notification="BEGIN_REQUEST", HttpStatus="500", HttpReason="Internal Server Error", HttpSubStatus="0", ErrorCode="The I/O operation has been aborted because of either a thread exit or an application request.
 (0x800703e3)", ConfigExceptionInfo=""

I believe this is a permissions issue because changing the AppPoolIdentity to LocalSystem for the Application Pool makes everything in the website work. When the AppPoolIdentity is set to ApplicationPoolIdentity the error shown above is what I receive. I have named the application pool identity using the following syntax:

IIS APPPOOL\<app_pool_name>

I have confirmed that:

1. I am using the correct app_pool_name when setting permissions. (Using check names when setting the permission works which means that Windows is finding the user.)
2. The wwwroot and the oracle client directory have permissions which allow the Application Pool identity to read and execute files.
3. Anonymous Authentication is enabled in IIS and is set to use the Application Pool Identity.

Do permissions need to be granted other directories that I have missed? Or is it some other problem that I am completely missing?

For some extra background I am using Windows Server 2008 R2 with IIS 7.5.

Thanks in advance!

EDIT: I have done some tracing, thanks to the advice that Peter gave and found that I was missing some permissions. The permissions I was missing were:

• Full Control to HKLM\SOFTWARE\Microsoft\SystemCertificates\
• Full Control to HKU{GUID}\Software\Policies\Microsoft\SystemCertificates\
• Full Control to HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\
• Read to HKLM\System\CurrentControlSet\services\eventlog\Security\
• Full Control to C:\Windows\SysWOW64\config\systemprofile\AppData\

After modifying these permissions my application is now logging to the Windows Event Log with custom application errors. (Basically the custom application error is telling me that it was not able to establish a connection to the database.). Keep in mind if I run as LocalSystem and not the AppPoolIdentity user in IIS everything works. Using the Process Monitor again I found that the Oracle Client was logging to a sqlnet.log file. In this file it is showing:

Fatal NI connect error 12631, connecting to:
 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=[DB IP ADDRESS])(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=[SERVICE NAME])(CID=(PROGRAM=C:\Windows\SysWOW64\inetsrv\w3wp.exe)(HOST=[WEB APPLICATION SERVER NAME])(USER=[APP POOL IDENTITY USER]))))

  VERSION INFORMATION:
    TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
    Windows NT TCP/IP NT Protocol Adapter for 32-bit Windows: Version 11.2.0.1.0 - Production
  Time: 21-JUL-2015 16:28:00
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12631

TNS-12631: Username retrieval failed
    ns secondary err code: 0
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0

Any idea on why it is using the AppPoolIdentity as the user it is trying to connect with?

I have finally solved this issue.

In the EDIT made above I added the necessary permissions which solved issue number one.

In order to get this working I modified my SQLNET.ora file to look as the following:

# sqlnet.ora Network Configuration File: E:\Oracle_client\product\11.2.0.1\client_x32\network\admin\sqlnet.ora
# Generated by Oracle configuration tools.
#SQLNET.AUTHENTICATION_SERVICES= (NONE, NTS)
SQLNET.AUTHENTICATION_SERVICES= (NONE)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

Note that the original SQLNET.AUTHENTICATION_SERVICES is now set to NONE only.

(I believe this change did not take affect immediately, but after a couple of minutes it did. Restarting the machine might be overkill, but sufficient).

I had also switched the AppPoolIdentity to LocalService and then back to AppPoolIdentity. After doing this it worked, but I don't think switching the AppPoolIdentity back-and-forth had any influence on getting it to work.