Many IIS applications require resources provided by other software components. For instance, an ISAPI extension DLL may call an Automation server from a third-party software company, or a CGI application may launch a program built with Microsoft® Visual Basic®. These components may have persistent information stored in the registry that they require in order to execute properly. For standard desktop use of these components, the registry information is read from the profile of the user currently logged on a computer with Windows. These applications often have problems when launched by IIS because the profile made available to an IIS application is that of the default user. The default-user profile is filled with information generic to all users, but is specific to no users. Therefore, a component may run as expected when User1 executes it on his or her desktop because it is reading information from User1's profile in the registry. The same application may not run at all from IIS because it will not have access to User1's profile. This is true even if IIS is impersonating User1's account by using Basic or integrated Windows authentication.
Windows NT 4.0, and Windows 2000 uses the concept of having multiple desktops on the same computer. A desktop can be thought of as the screen that you view when you are logged on your computer. Your desktop receives all the mouse and keyboard messages that you send as the user at the computer, and it allows for applications to interact with one another to a certain extent. For instance, one application on a desktop can post messages to other applications on the desktop. Support for multiple desktops implies that there are other desktops running; you just can't see them and you have no way of sending keyboard or mouse messages to them. This may seem like a futile concept, but, in fact, many applications that run as Windows services require the capabilities that a desktop provides but don't want to interact with the interactive user's desktop. Therefore, each service gets its own desktop that won't be interfered with by the currently logged-on user.
If your IIS application interacts with a desktop in any way (for instance, if it displays a message box), then it will display that message box on a desktop that cannot be seen on the computer's monitor. Similarly, an IIS application will not be able to send or post messages to an application on the interactive desktop. If your IIS application needs to interact with the interactive desktop, then you should use another form of inter-process communication such as Named Pipes. For more information see "Interprocess Communication" in the Windows Base Services section of the Platform SDK.
ISAPI filter DLLs, not to be confused with ISAPI extension DLLs, run in the original context of the IIS service. All services run by default under the Local System account of the computer on which they are installed. The Local System account has access to almost all resources on the local computer not specifically denied to it, and no resources on any other computers on the network.