To understand network access problems in Automate it is important cover briefly the security architecture of Windows and how it relates to Automate

Windows Services
A Windows “Service” is a special type of program which, unlike a traditional application, starts automatically when the computer starts before the user logs on. Because of this unique behavior, services are useful in software that performs operations in the background such as server applications and system automation software.

Because services start before user logon, they do not run under the same user-context as applications that are started after logon. Rather, most services run under a special system account called LocalSystem. LocalSystem is a built-in account that has a high level of access rights in that system.

Programs that run under the LocalSystem account have full access to the entire system. It is important that Automate runs under this account so that important system-related tasks such as pressing CTRL-ALT-DEL when needed can be performed.

The drawback to this approach is that LocalSystem does not have the same access rights to the network that are normally associated with standard user accounts.

The Automate Task Service
The Automate Task Service is a component of Automate that runs as a true Win32 Service and logs on as “LocalSystem”. The Task Service is responsible the following:

  1. Opening the task list and initiating tasks
  2. Monitoring for most trigger events
  3. Running tasks when they are triggered.
  4. Logging Events
  5. Responding to requests from the Task Administrator

Because the Task Service runs under the LocalSystem account, special configuration may be required to allow it to access network drives. If this configuration is not performed, any of the previously listed operations can fail if they require network access.

This situation can manifest itself in a variety of ways, including:

  1. Folder Watcher trigger cannot monitor network drives.
  2. Tasks fail to invoke and show a broken link symbol when the AML file resides on a network drive
  3. Logging fails when log file is located on a network drive
  4. Unable to run Automate when installed to a network drive

For example, if a user builds a task and attempts to configure the Folder Watcher to watch a network drive, at design-time, the user is able to browse to the folder to the network drive. However, when the user attempts to put the task into production, the task is unable to see the network drive. The reason for this lies in the fact that at design time the various design-time components of Automate were started and are running under the User-context of the currently logged in user, whereas the Task Service started before the user logged on and continues to run under the LocalSystem account. Automate has special settings located on the Default User tab in the System Options tab that allow the user to specify the user context that the task should monitor and run under. Without configuring the Default User in the system options, the trigger will not have network access and the following message will appear in the log: "Folder "\\Server\Share" cannot be found. Waiting for folder to be accessible"


Run Automate on the target system that contains the resource to be monitored.

If it is possible to run Automate on the server that is to be monitored, this will result in faster, more efficient operation for the Folder Watcher trigger as the event will not have to traverse the network. Furthermore, permissions will not need to be modified.

Configure the Service User tab of the System Options to a valid network user account.
Automate uses the "Service User" account as a user context for triggers such as the file trigger and others. To change this setting, open the Automate Task Administrator then click on System | Options, then select the Service User tab. Be sure that the user account you enter is a valid network user with access to the resources that you want the trigger to have access to.

Grant privileges to the computer account on the domain for the share that needs to be accessed.
In order to grant network permission to the LocalSystem account of a given machine the Computer object (not the user object) must be granted privileges to the network resource. If the system group “Everyone” already has access, this step is not necessary because the “Everyone” group includes computer objects. To configure a network resource to have access for a computer: from an administrative account on the server, browse to the folder in question, right click the folder, select Sharing, the sharing dialog box will be displayed, click "Permissions", tab and click the button “Add”.

Browse for the Computer (the computer on which Automate is running) and add it to the list. It is only necessary to grant “Read” privileges if being implemented for the Folder Watcher trigger.

IMPORTANT: The security must be modified on the actual share on the server via sharing properties and not by simply accessing the properties of the folder and modifying its security settings.

Additional Caveats

Even if the computer has access to the network resource, to ensure proper functioning when logged out it is critical that mapped drive letters not be used. Folders should always be specified using UNC (Universal Naming Convention) paths. For example: X:\pathname\ should be \\servername\pathname\ This is because mapped drives are connected and created when the user logs on, and this does not occur for LocalSystem services.

Applies To: Automate 5, Automate 6

Still have questions? We can help. Submit a case to technical support

Last Modified On:
You don't have the appropriate permissions.
No, open a new Support Case