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.
