IIS Worker processes & windowstation/desktops
Back to fire after some good & sunny holidays and a cool team offsite in Lisbon with my european colleagues Tess, Doug, Carlo, Johan and all others.
My today's take will be related to IIS6 and the logical execution context of its worker process, especially its related windowstation and desktops
First as quick terminology remind quoted from About Window Stations and Desktops:
"A window station is a securable object that is associated with a process, and contains a clipboard, an atom table, and one or more desktop objects
A desktop is a securable object contained within a window station. A desktop has a logical display surface and contains user interface objects such as windows, menus, and hooks."
When talking about those objects, we have to keep in mind we are dealing with secured objects that have dedicated ACLs.
Each process is running within a window station that might contain one or several desktops
When talking about the “identity stamp” of a process, we are talking about a security token,
Those tokens contain group membership, privileges, and relate to a logon session that is the “atomic materialization” of a user identity logon.
If you’re interested I can only recommend digging into Keith Brown articles: first MSJ 99 and if you want to try to write your own first Logon Session Broker MSJ 2000
The security context of an IIS6 worker process will be basically built from your application identity settings.
By default, IIS6 worker processes are running Network Service identity, within a single non-interactive windows station (created by the WWW service) and sharing the same desktop.
If you configure a specific identity for your application pools, then each worker process will rely by default its own desktop object.
If you are using several applications or important web gardens, you might experience desktop heap exhaustion, with various symptoms like Q217202 or Q870655
To fix that kind of desktop heap exhaustion issue, you have 2 point of views:
· Try to tune the desktop heap settings
· Configure IIS to share a single desktop object for all worker processes running the same identity by using UseSharedWPDesktop registry key
Since tuning desktop heap is a machine wide setting and can be hard to correctly evaluate, I personally prefer sharing a single desktop.
Paranoiac administrators might see a security issue by sharing anything between processes, but as David Wang explains (quoted):
“The following are the interesting combinations and consequences:
1. If UseSharedWPDesktop=0 and all application pools launch as Network Service, then there is exactly one Desktop (of Network Service) shared by all the application pools.
You have no isolation of desktop nor process identity between application pools.
2. If UseSharedWPDesktop=0 and all application pools launch as unique user identity, then there is a unique Desktop for each user identity, which is obviously not shared.
This is limited to a number around 60 due to Desktop heap limit in Windows Server 2003. This means that you can only have ~60 application pools perfectly isolated by desktop and process identity simultaneously running.
3. If UseSharedWPDesktop=1 and all application pools launch as unique user identity, then there is one Desktop that is shared by all the user identities.
This removes the limit of 60 at the cost of not perfectly isolated application pools. You have no desktop isolation but retain process identity isolation between application pools.
4. UseSharedWPDesktop=1 and all application pools launch as Network Service is pretty much a degenerate case that is not interesting. :-)”
Vista and IIS7 shouldn’t really have those desktop heap exhaustion issues, because of Vista’s Dynamic Memory Architecture (but that's here also a very long story).
You should anyway continue taking care of your application pool identities, since it will have many impacts on the way your code will be housed by Windows.
Another possible kind of issue is because of some applications to fail on IIS6 is that they need an interactive execution.
IIS creates its window stations as non-interactive, and to be honest I didn’t find any supported way to change it (but maybe there is...).
That means you could potentially experience issues with components like GDI/GDI+ (get a look at Carlo’s blog), or using some printer drivers (using WMI or prnadmin.dll), etc…
I even have to admit I saw couple of times some ISAPI filters having debugging spies shown using a MessageBox...
I think we sometimes have to remember that IIS is a web server, designed to host scalable application servers, that is IMO *not* something’s really compatible with interactive actions.
IIS is designed to process in a timely optimized fashion *silent* server application, and using graphical & printer related things is normally not (again at least from my experience).
Then the right design to allow that kind of interactive features is to have a separate process running within interactive window station.
It can for sure communicate with IIS process by any supported IPC manner (COM interfaces, namedpipes, MMF, sockets, etc..)
Also an easy design to do things like printer management might just be using interactive scheduled task in order to avoid any driver related issue...
Comments
Anonymous
January 01, 2008
PingBack from http://msdn.blogsforu.com/msdn/?p=2948Anonymous
August 11, 2008
This is an interesting question I have to admit I had not thought to until we got a case from a customer