I have a few older ASP .Net Framework (web forms and mvc) sites on an IIS server which run in an app pool which uses a custom AD account. Serving any static files (images, js, css) from the Content folder of the site has always worked fine – but this began failing a few weeks ago. All requests for static content return a 500 error. The dynamic content still runs fine. When I switch the app pool to use the built-in ApplicationPoolIdentity, then the static content is returned fine. I verified that the custom AD account has read access to the static files on file system. There are no messages in the event log and the IIS logs only show the 500 response with no details. As this works fine using the built-in account, I am assuming the static file handler is still installed and running as expected.
Any thoughts on what may have changed, what would cause static files to fail for custom accounts only, or where I can look for more details on the error IIS is encountering?
EDIT: After further testing, I find that using my personal AD account for the app pool allows the site to serve static files. So guessing the issue relates to the custom account’s privileges in some way?
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
So, thanks to the link from Lex Li above, I was able to enable failed request tracing and this pointed me to an authentication error – “Either a required impersonation level was not provided, or the provided impersonation level is invalid. (0x80070542)” By adding the custom AD account for the app pool to the local Admin group on the server, the issue was corrected.