So this is really a reminder to myself that when you configure a SharePoint on-premises environment for hosting SharePoint Apps, that when using different Application Pool accounts you need to set the permission correctly or any Apps that are installed just display a blank page.

As an example my environment currently has three web apps.

As you can see each one is running over SSL as I like to have it. Each Web Application also has its own Application Pool.

Each one is set to a different domain account also.

Web Application App Pool Name App Pool Account
Apps App DOMAIN\SP_AppPool
My Sites MySites DOMAIN\SP_ProfileAppPool
Portal Portal DOMAIN\SP_SiteAppPool

As you can imagine the permissions are set specifically to those account and those accounts only. This means that when I try to the run the App that I installed into the “Portal” site which runs over SSL from the “App” site it fails. If we now look into SQL we can see that the Application Pool account that is used for hosting Apps, does not actually have permission to anything within the two other site collections.

To resolve this I granted direct access to these database for that account. So this now looks like this in SQL.

Once this is set, the “App” should load, but you may get the following error I blogged about previously:

For me to fix it completely I had to make one more change which was to access the “App” website within IIS and set the “Anonymous Authentication” to the “Application Pool Identity” instead of the “IUSR” account.

This then made it work as expected. Of course you may not be able to do this in some secure environments.

NOTE: I did find that in reality as long as the “Application Pool Account” was the same as the root site you installed the “App” into, then it worked. However the last step I made to the application pool authentication did resolve some other issues I was seeing.

Key takeaway here is check your security policy before you start modifying things just because.