Access Network Resources

When your agent runs as a Windows service, you can schedule Windows workload that accesses network resources. For example, you can specify UNC names and share names in your job definition.

Usually, when running Windows programs as a service, you are restricted to how you can access data on remote computers. For example, to access data on a remote computer as a specified user ID, you must run the Windows service with that user ID.

With the agent, however, those restrictions do not apply. Instead of running the agent service with a specific user ID, you can specify the user ID with the USER statement in your job definition. To use the USER statement, your agent must run as a Windows service under the local system account (the default configuration).

To access Windows network resources

Verify with your agent administrator that the agent is running as a Windows service under the local system account.
Ask your scheduling manager administrator to define a user ID and password on the scheduling manager that has access to the file on the remote Windows system.
Specify the file name using the CMDNAME statement in the job definition.
Notes:
- You can specify UNC (Universal Naming Convention) names. A UNC name is the name of a file or other resource that begins with two backslashes (\\), indicating that it exists on a remote computer.
- You can specify share names. A share name is an alias for the path the resource exists in.
- You can specify the share names C$ and ADMIN$ if the agent service logs on to a remote Windows server as a user with administrative authority. The agent can then access remote resources that are not marked as shared.
Specify the user ID and the domain the user ID belongs to using the USER statement in the job definition.

Notes:

Before accessing network resources with your agent, verify that you are complying with the terms of your agent license agreement. In most situations, you are permitted to access data on remote computers; however, scripts or executable files run by an agent should use the CPU and memory of the computer where the agent resides.
Although not recommended, your agent administrator can run the agent as a Windows service under a local user account (the This Account option). When you run the service under a local user account, when the service starts, it runs using the security context of the specified user account. If the user account and password are valid, the service process has access to network resources.
When you access a remote computer from an agent on Windows, the user ID defined in the USER statement or in the This Account option is a domain user. If the local and remote servers are standalone servers, you must have the same user IDs and passwords defined on both servers.
Some Windows 2000 applications do not run correctly when they are run remotely from the Windows NT 4.0 operating system.
For more information on configuring and running the agent as a Windows service, see the CA Workload Automation Agent for UNIX, Linux, or Windows Implementation Guide.

Example: Run a Command on a Remote Server

In this example, the path c:\WINNT\Profiles\Visitor\Desktop\ has the share name MyDesktop. The command notify.cmd is in that path on the CYBNT server. JDOE is a user ID in the CYBDOM domain and has access to the notify.cmd command. JDOE's password is defined on the scheduling manager.

AGENT NT20
CMDNAME \\CYBNT\MyDesktop\notify.cmd
USER CYBDOM\JDOE

Example: Run an Executable in Public Folder on a Remote Server

This example runs calc.exe on the CYBNT server. CYBUSER is a user ID in the CYBDOM domain. CYBUSER is defined on the scheduling manager and has access permission to the public folder.

AGENT NT30
CMDNAME \\CYBNT\public\calc.exe
USER CYBDOM\CYBUSER

Example: Access a Remote Resource Using the C$ Share Name

In this example, drive C is accessed by an administrator over the network through an agent. The agent is running under the System Account option. The agent runs the test application in the c:\working directory on the server CYBNT. The directory c:\working is not a shared resource. The user admin1 is a valid user on both the local and remote computers and belongs to the Administrators group. admin1 is also in the CYBDOM domain.

AGENT NT30
CMDNAME \\CYBNT\C$\working\test
USER CYBDOM\admin1