Alterando minha resposta desde que você alterou a tag do Server 2008 para 2003 ... e não fui muito preciso em minha primeira resposta.
Qualquer conta configurada para executar a tarefa agendada, uma sessão de logon é criada para essa conta sempre que a tarefa é executada, uma estação de janela é criada para esse logon e as janelas são criadas nessa estação de janela / sessão de logon. Quando a tarefa é concluída, a conta do usuário é desconectada ... com exceção das contas do sistema, é claro. Eles nunca fazem logoff.
Além disso, o Server 2003 não possui o isolamento de sessão 0 que o 2008+ faz. É importante notar que isso funciona de maneira muito diferente em 2008+ do que em 2003. Em 2008, as tarefas agendadas são geradas pelo taskeng.exe, gerado pelo svchost.exe, o que significa que a tarefa agendada é executada na Sessão 0, independentemente de a tarefa ser ou não executada. funciona como SYSTEM ou como um usuário normal. Mas se a tarefa estiver configurada para executar como SYSTEM em 2003, ela funcionará quase da mesma forma que em 2008, onde a tarefa é criada pelo svchost.exe na Sessão 0. No Server 2003, a Sessão 0 é simplesmente a sessão "console", e você pode acessá-lo através do RDP com o / console (/ admin no Vista / 2008 +) e você irá logar na Sessão 0, mas ele gera uma nova estação de janela para você, então você não será capaz de ver que janelas da tarefa que foram lançadas pelo sistema.
No Vista / 2008 +, esse tipo de atividade provavelmente acionaria o serviço de Detecção de Serviços Interativos, destinado a transferi-lo para a área de trabalho da Sessão 0 quando uma caixa de diálogo interativa aparecer, mas a menos que outro usuário estivesse logado no mesmo tempo para o serviço ISD alertar.
Portanto, tenha isso em mente quando chegar a hora de migrar do seu sistema operacional de 10 anos.
Do blog do NTDebugging:
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$”.
De um antigo 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.
Não há como passar um processo e todas as suas janelas para a sessão de outro usuário ou de alguma forma injetá-lo em sua área de trabalho ... pelo menos não sem uma grande programação ... seria um programa muito interessante para tentar fazer .
Por fim, os comentários sobre este post no blog de Mark Russinovich são bastante interessantes e relevantes:
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.