Best practice for IIS Application Pool renames and existing file permission references

  application-pool, iis, iis-8, windows

I’m trying to understand how Windows stores permissions in relation to object references, specifically for when IIS (8) application pools are the reference. Are they dynamic, or are they literal strings that can break under simple renaming circumstances? AKA, is there a unique identifier (GUID) behind the scenes for the friendly name displayed in the "Group or user names" list?

In rudimentary testing, I assigned a file an explicit permission for an application pool (using the object lookup "IIS AppPool{MyAppPool}"). I then renamed the application pool and reopened the permissions windows, and found it still referencing the old name.

While this does seem to answer my own question, I know that I’ve seen GUIDs appear in the permissions group lists before for broken references (particularly when viewing files over a file share), but in this case, it appears that the group list still considers the old app pool name valid (from a representation standpoint)

We had a case where an IIS application pool was renamed (of course after first being detached for its running application). This application pool was referenced as a permissions object in several areas, including the related website’s physical folder (Full Control) and some Personal Store certificates (Read). Consequently several things broke, and I’d like to understand both how this property storage works on an underlying level, as well as any best practices for how to safely make a rename like this and recursively impact all previous references (if possible).

Source: Windows Questions

LEAVE A COMMENT