0

I've searched around here and found a couple of things to try but none of the other questions matches exactly what is happening with my IIS and application setup.

First, some background. A client of my company's wanted an internal application of theirs re-written bits at a time. I came into the project with no control over the initial IIS setup and there appear to be some funky things that aren't working correctly, but I'll get to that. The first bit is a custom label application that writes a file to a file share to be printed. In order to maintain parts of the legacy app that were needed, I created a separate site in IIS and moved all of the legacy label application code there. I also create a new sub-application under their default website. So the structure looks something like:

IIS

  • Default Site
    • New Labels app (currently exact same code base as the legacy app)
  • Legacy Labels app

The default site is running under an app pool identity called ASP.NET v4.0, not DefaultAppPool and the new app is running under an app pool identity named after the site - Labels.

Problem

The sub-application for the new labels can write to the file share without any problems, but the legacy site is getting Access Denied. This is the exact same code base and the only difference between the two is the app pool that is being used. I want to maintain these app pools separately, but currently they are set up identically. So this leads me to believe that something was set up in IIS prior to me getting involved where the ASP.NET v4.0 app pool identity somehow magically has access to the file share whereas the newly created Labels account does not.

The fileshare is open to the Everyone group so there shouldn't be any issues from the domain level, but from what I understand these IIS accounts that get generated are part of the virtual IIS AppPool domain anyways. So, how is it possible that one app pool identity has access and one does not? What are some steps I can take in the troubleshooting process?

1 Answer 1

1

This is just another manifestation of the IIS bug that I wrote about in this answer. You will find that a reboot fixes it. A hotfix is available.

The different behavior of your two sites can only be due to the two different application pool identities that they are running under. You didn't clearly mention the identities of the working and non-working pools. "Labels" is the name of the application pool. Check pool properties to see what identity it runs under and compare it to the identity of the legacy pool.

enter image description here

This bug has caused our production sites to go down on multiple occasions, with customer impacts. So I don't consider this IIS 7.5 patch optional - as Microsoft appears to be implying for the past 4 years by refusing to address this issue via the standard update channel. Forcing customers to "discover" this bug with production downtime is outrageous.

2
  • This is a very difficult bug to troubleshoot as well because a full server reboot is usually the last thing I recommend to clients. I recommended they file a complaint with Microsoft regarding this.
    – akousmata
    Nov 10, 2014 at 15:58
  • FYI, this patch will not work in IIS 8.0 Express. It will fail on installation.
    – akousmata
    Dec 11, 2014 at 15:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .