When a user has logged in, its user profile is loaded (whether it’s a local or roaming profile) and used locally. This implies the user has its own registry key under HKEY_USERS and its own subfolder under the “Documents and Settings” folder.
One day there is a problem with a .NET web application published in IIS 6. The application runs in its own application pool, so with its own worker process (w3wp.exe). Some user account is used as the application pool identity. The problem is some user-specific setting should have been retrieved from the registry, but the application doesn’t seem to do this. So let’s have a look at this setting: it’s stored under HKEY_USERS\SID (with SID being the SID of the application pool user).
Something seems very wrong!! There is no node under HKEY_USERS for the application pool identity, so we can’t check the setting’s value! Let’s take a look at the file system: nope, no folder for this user under “Documents and Settings” either… What’s going on here?
Don’t panic, all this is very normal! First of all, there are different kinds of logging in. A few ways of logging in is of the “Interactive” type (the name speaks for itself). The most classic way of logging in is an example of this type. In IIS though the application pool identities have to log in too, but not in an Interactive way (of course not!). In IIS the logon type is called “Service” (service should be interpreted here in a broad sense).
Some logon types do more than just the actual logging in. For instance, they also load user profiles (which happens through the Windows API function LoadUserProfile). If we log in the most classical way we can think of (like everybody does), those extras occur, including loading of our user profiles. When a Service logon takes place, those extras are not always occurring. IIS 6, for example, doesn’t load user profiles for the application pool identities. IIS 7 on the other hand loads them by default, although this behavior can be changed through the LoadUserProfile setting.
If such a user needs something from the profile, the default user’s profile is used instead. For the “missing” application pool user this means we have to take a look at the setting under HKEY_USERS\.DEFAULT (remember we had a problem related to some setting?).
Probably some of you would tell me their application pool user does have a user profile loaded, because they see the HKEY_USERS\SID node in the registry (with SID the SID of the user). Well, this is perfectly possible. Despite my explanation about the Service logon type and user profiles, it is still possible ofcourse to log in the Interactive way as that user. As a result a user profile is created. So such a profile could exist, but at the same time subsequent Service type logons of the user still don’t load the user profile. This is no contradiction at all.
Oh yes, perhaps you wonder how to tell if your user is available under HKEY_USERS with all those SIDs appearing there? You can use the tool getsid to determine the SID of your user and then check if that SID appears under HKEY_USERS. Or, you can use a tool like SidToName (from Joe Richards) and convert all the SIDs you see to a user name (one by one, that is).
I hope this information has helped.