Where do the Windows to a scheduled task go when the server runs them

Changing my answer since you changed the tag from Server 2008 to 2003... and I wasn't really accurate with my first answer.

Whatever account is configured to run the scheduled task, a logon session is created for that account every time the task runs, a window station is created for that logon, and the windows are created in that window station/logon session. When the task is done, the user account is logged off... with the exception of the system accounts of course. They never log off.

Also, Server 2003 doesn't have the session 0 isolation that 2008+ does. It's worth noting that this works much differently in 2008+ than it does in 2003. In 2008, scheduled tasks are spawned by taskeng.exe, which is spawned by svchost.exe, meaning the scheduled task runs in Session 0 regardless of whether the task runs as SYSTEM or as a normal user. But if the task is set to run as SYSTEM on 2003, it works almost the same as it does in 2008 where the task is created by svchost.exe in Session 0. In Server 2003, Session 0 is simply the "console" session, and you can access it over RDP with the /console (/admin in Vista/2008+) and you will log in to Session 0, but it generates a new window station for you, so you won't be able to see that scheduled task's windows that were launched by System.

In Vista/2008+, this sort of activity would likely trigger the Interactive Services Detection service, which is meant to transfer you to Session 0's desktop when an interactive dialog box pops up, but not unless another user was logged in at the same time for the ISD service to alert.

So keep that in mind when it comes time to migrate off of your 10 year old OS.

From the NTDebugging blog:

What are all these window stations and desktops in Session 0 anyway?

Now that we know how to tweak the sizes of session view space and the various desktops, it is worth talking about why you have so many window stations and desktops, particularly in session 0. First off, you’ll find that every WinSta0 (interactive window station) has at least 3 desktops, and each of these desktops uses various amounts of desktop heap. I’ve alluded to this previously, but to recap, the three desktops for each interactive window stations are:

· Default desktop - desktop heap size is configurable as described below

· Disconnect desktop - desktop heap size is 64k on 32-bit systems

· Winlogon desktop - desktop heap size is 128k on 32-bit systems

Note that there can potentially be more desktops in WinSta0 as well, since any process can call CreateDesktop and create new desktops.

Let’s move on to the desktops associated with non-interactive window stations: these are usually related to a service. The system creates a window station in which service processes that run under the LocalSystem account are started. This window station is named service-0x0-3e7$. It is named for the LUID for the LocalSystem account, and contains a single desktop that is named Default. However, service processes that run as LocalSystem interactive start in Winsta0 so that they can interact with the user in Session 0 (but still run in the LocalSystem context).

Any service process that starts under an explicit user or service account has a window station and desktop created for it by service control manager, unless a window station for its LUID already exists. These window stations are non-interactive window stations. The window station name is based on the LUID, which is unique for every logon. If an entity (other than System) logs on multiple times, a new window station is created for each logon. An example window station name is “service-0x0-22e1$”.

From an old MS KB:

A Microsoft Windows NT, Windows 2000, and Windows XP service has a Window station and Desktop combination associated with it. This is based on which account the service is running in:

•If the service is running in the LocalSystem account and is not interactive (that is, the service type does not include the SERVICE_INTERACTIVE_PROCESS flag), the service will use the following Window station and Desktop: Service-0x0-3e7$\default where "Service-0x0-3e7$" is the name of the Window station and "default" is the name of the desktop.

This is a noninteractive Window station.

•If the service is running in the LocalSystem account and is interacting with the desktop (that is, the service type includes the SERVICE_INTERACTIVE_PROCESS flag), the service will use the following Window station and Desktop: Winsta0\default This is an interactive Window station.

•If the service is running in the security context of a user account, the system will create a unique noninteractive Window station and Desktop for that service. The name of the Window station will be based on the Logon Security Identifier (SID) of the user:

Service-0xZ1-Z2$\default where Z1 is the high part and Z2 is the low part of the Logon SID. Additionally, two services that are running in the same security context (same service account name) will not receive the same Window station and Desktop because Logon Security Identifier's(SID) are unique to that logon session.

There's no way to pass a process and all of its windows into another user's session or somehow inject it into their desktop... at least not without some major programming... that would be a very interesting program to try to make.

Lastly, the comments on this post on Mark Russinovich's blog are quite interesting and relevant:

The question was whether a thread could call SetThreadDesktop after it had already been assigned to a desktop by the window manager. I wrote some test code just now and it confirmed my recollection. If a thread has ever created a window on one desktop, even if that window has since been destroyed, it will never be allowed to SetThreadDesktop() to a different desktop and create windows there.