Summary

Beginning with Windows Vista and Windows Server 2008, Microsoft made changes to the login session model for Windows. These changes affect the "console" login session and as a result affect the "Console" user interaction mode in adTempus.

More Information

When a user logs in to Windows, Windows creates a login session for that user. That login session has its own Windows desktop, and all programs run by (or on behalf of) that user in that login session are displayed on that virtual desktop. Other users cannot see these programs running on their desktops.

Prior to Windows Vista/Windows Server 2008, Windows featured a special "session 0." Session 0 was the "console" session, meaning that a user who logged in at the computer's physical console was assigned to this session. Additionally, all service applications run by Windows were also assigned to session 0, meaning that if a service displayed a user interface, it was visible to the user who was logged in to session 0. It was also possible for a remote user to connect to session 0 using Remote Desktop, allowing that user to view applications running in session 0.

Because it runs as a service, adTempus itself runs in session 0 and can therefore run programs that appear in session 0. This was the behavior if you specified the "Console" user interaction mode for a job.

This behavior was convenient to system administrators because they could configure a job to execute in session 0 and then connect to session 0 remotely at any time, from any Administrator's user account, to view the user interface for the programs run by the job, and this was a common workflow implementation. Even if the job was running under user account UserA, it was possible for user UserB to log in to the console session to view the program.

Beginning with Windows Vista and Windows Server 2008, Microsoft made changes to provide greater security and session isolation.

Under the new model, session 0 is still used for services, but it is no longer the "console" session. Windows still has the concept of a console session, but the session number is not fixed, and it is the "console" session only when the user is logged in at the physical console. It is no longer possible to connect to the "console" session using Remote Desktop.

As a result of this, choosing the "Console" user interaction setting for a job means that the programs run by the job will be visible only to a user at the physical console, which is of limited use in most implementations.

More importantly, it is no longer possible to have a job running under one user account and then connect to the same session from a different user account to view the user interface for the program. Therefore the scenario described above, where scheduled programs are run in the "console" session and can be monitored from remote login sessions, is no longer possible. The only way to view the user interface for a program run by adTempus is to connect to the same session (under the same user ID) that the job is using. This can be accomplished as follows:

  • Assume that the job is configured to run under account UserA.
  • The job's User Interaction setting must be set to "User's Session."
  • Someone must log in to the computer interactively (either at the physical console or remotely) using account UserA to establish an interactive logon session. This login must be performed before adTempus attempts to run any jobs under the account. Each time the computer is restarted, it will be necessary to re-establish this login session afterward.
  • Once the user has logged in interactively, the session must not be terminated by logging off (though the session can be locked).
  • When adTempus runs the job under under account UserA, it will locate the existing logon session and run the job in that session.
  • As a result, the program will be visible to the person who is logged in interactively as UserA.
  • The logon session can be "transferred" to another Remote Desktop connection: if a user starts a second Remote Desktop connection under the UserA account, the original Remote Desktop connection will end, and the new Remote Desktop connection will be connected to the logon session, where it will still be able to view the user interface for any program being run by adTempus.

Implications and Recommendations

These changes make it more difficult to monitor "interactive" programs run by adTempus. However, such programs have always been a poor match for automation systems such as adTempus, which are designed to run unattended applications that do not require a user interface.

If your organization is building applications or scripts that are going to be automated, they should be designed so that they are (or can be) run without a user interface. Any error messages or other output should be written to the system Event Log or to application-specific log files to allow it to be monitored independent of an interactive user interface. The application should never display dialog boxes or other prompts.

More Information

See article K00000294 for more information on the User Interaction settings for a job.