Summary
By default, adTempus does not allow users to schedule programs to run under the Local System account because of security concerns and problems caused by the limitations of that account (see below).
However, it is possible to use the Local System account if you absolutely need to.
More Information
Enabling use of the Local System account requires several steps:
First you must activate the options related to the Local System account. To do so, run the Registry Editor and find or create the key HKEY_LOCAL_MACHINE\Software\Arcana Development\adTempus\options. Add a string value (it must be a string value) called "AllowLocalSystem" and set this value to "1". Stop and restart the adTempus Service.
Next you must grant permission to use the Local System account to the appropriate users. Run the adTempus Console and select Server Options, then Security Settings from the Tools menu. On the Server Security tab you will now see a "Use Local System account" right listed. Assign this right to the appropriate users (first see Security Concerns below).
When you edit a job, you will now see a Use Local System account option under the User Account settings. This option will only be enabled for users to whom you have granted the "Use Local System account" right.
Security Concerns
Programs running under the Local System essentially have full access to the computer on which they are running. You must therefore exercise care when granting users permission to schedule jobs under this account. If a user can schedule jobs to run under the Local System account, that user can do anything he or she wants with/to the computer.
Problems with Programs Run Under the Local System Account
In most cases you should not use the Local System account for jobs. Using this account can cause many problems, due to the restrictions discussed below.
The Local System account is not the same as the "Local Administrator" account. It is not a user account at all. The Local System account is intended for use by the operating system, and by applications (such as services) that essentially act as a part of the operating system and are specifically designed to work when run under that account.
Most applications that you schedule are not designed to be run under the Local System account. If they were, they'd probably be running on their own, as services, not under adTempus.
The Local System account is by design limited in what it can do. Most significantly:
- It has no user profile. Many applications expect to be able to load settings from and save settings to the user's profile when they run. They're not built to handle the possibility that there won't be a profile, so they fail. This is particularly true of VB applications.
- Because it has no profile, it has no printers (because printers are defined in each user's profile). Applications run under this account won't be able to print.
- It has none of the many other things that are associated with a user profile. Like a MAPI profile, so your application can't use MAPI to send e-mail.
- It only has access to resources on the local system (hence the name). It does not have access to network resources.
Other Issues
When you schedule a job to run under the Local System account, you are actually telling adTempus to run the job under the account that the adTempus service is running under. Normally this is the Local System account. However, if you have changed the adTempus service to run under a user account instead (see article K00000215), using the "Local System" option will cause the job to run under that account, not the Local System account.
