Agentless Job Servers

An agentless Job Server lets you run Jobs and Workflows on a Windows or Unix server inside the your network without having to install a Platform Agent on that server.

Note: Agentless Job Servers are only necessary if you cannot install a Platform Agent on a given server.

A normal configuration for running native OS processes consists of two separate parts:

• A Job Server in the central RunMyJobs server, where OS processes are represented by Jobs.

• A Platform Agent on the computer where the OS processes run.

With an agentless Job Server, a Platform Agent installed on one Unix or Windows server runs Jobs on the target server by sending commands to it via SSH (Unix) or WMI (Windows). The following diagram compares a normal scenario with a Unix server with an agentless scenario with a Unix server.

As the diagram shows, you need at least one Platform Agent running on a server (Unix Server 2) with the same OS as the agentless server. (Unix Server 3). You also need at least two Job Servers: an agentless Job Server, and a proxy Job Server.

Prerequisites

A UNIX proxy Job Server must have an ssh client, and must be able to reach the target agentless server on port 22. Its target system requires an ssh server running on port 22.

Note: UNIX proxy Job Servers that use key-based SSH authentication are supported with no additional configuration.

A Windows proxy Job Server must have access to the target agentless system on RPC and WMI ports. Note that WMI uses port ranges. A temporary SMB network share will be created on the proxy Platform Agent and accessed on port 44.

Configuring an Agentless Job Server

To make a Job Server agentless, set the following parameters in the Parameters tab.

If the ProxyProcessServers field is empty, the list of valid proxy Job Servers is populated with the list of all non-agentless Job Servers that provide the Definition Type of the Job. If ProxyProcessServers is NOT null, its value is used as the list. In either case, the first Job Server from the list that is running will be used as the proxy.

The following Job Server Parameters are supported for agentless Job Servers.

• RemoteHostName
• EndPoint
• LowVolume
• DefaultRunAsUser
• CygwinInstallPath (Windows only)
• LocalInterpreter_XXX
• InterpreterWhitelist_XXX

All other parameters either do not apply or have their values supplied by the proxy Job Server.

Special Considerations for UNIX Processes

If you want to use an agentless UNIX Job Server, consider the following.

• The server where the Platform Agent is installed (Unix Server 2 in the diagram) must have an ssh client.
• The server that the OS Job will run on (Unix Server 3 in the diagram) must have a working ssh server (daemon).
• If the Job Definition does not have a full set of credentials (username + password), the SSH connection will be tried using the username. If the username is not set, RunMyJobs will try the default user that OS Jobs run as on the proxy host (Unix Server 2 in the diagram). In such cases, the system will use the authorized_keys mechanism.

Special Considerations for Windows Processes

If you want to use an agentless Windows Job Server, consider the following.

• The proxy server and the target server (Servers 2 and 3 in the diagram) must have WMI active and configured.
• Both servers must belong to the same domain, or there must be a trust relationship between the servers' domains.
• Each Job Definition must be fully authorized, including a password. Set the Run As User field to a username or domain\username, with either a password in the Run As User field or in a credential object.
• The user specified in the authorization must be an administrator account on the target server.
• Enable incoming WMI and DCOM connections in the firewall on the target server (Server 3 in the diagram). If you use the built-in Windows Firewall, enable the following inbound rules on the target server:
  • Windows Management Instrumentation (DCOM-In)
  • Windows Management Instrumentation (WMI-In)
• The proxy server (Server 2 in the diagram) must allow file sharing to the target server. As part of an OS Job, a temporary network file share is created on the target server to contain the output and log files on the proxy server.

If you get a WMI connection failure, especially if accompanied by error code 0x800706ba, make sure you have created the firewall exceptions as indicated above. For more information, see System Administration > Windows Management Instrumentation > Using WMI > Creating WMI Clients > Connecting to WMI on a Remote Computer > Connecting Through Windows Firewall in the Microsoft MSDN documentation.

Implementation Details for Windows

The proxy Job Server (Server 2 in the diagram) prepares a job-specific directory. Since all job directories and the files in it are to be owned by the Run As User, this user account must be known on the proxy Job Server. Even if it were owned by a different user. the actual OS runner account would have to be granted full access to these files, so there is no workaround for this restriction.

The proxy Job Server accesses the target host (Server 3 in the diagram) via WMI. Windows requires Administrator privileges to allow this. The proxy Job Server also shares the proxy Platform Agent binary and data root directories via SMB. The latter requires no special privileges as it is performed by the local system account. You can see these network shares if you run net share on the proxy Job Server. The following is example output.

C:\> net share

Share name                      Resource                        Remark

---------------------------------------------------------------------------------------------------
C$                              C:\                             Default share
IPC$                                                            Remote IPC
ADMIN$                          C:\Windows                      Remote Admin
agent-SystemID_10180-bin        D:\agent\9_2_11_20230727_18\bin
agent-SystemIDs_10180-dataroot  D:\agent\var\SystemID_10180\proxyhost

The command completed successfully.

All actions on the WMI channel for a single job are bundled into one WMI session running as the same user. From Windows 2008 onwards, these sessions are fully isolated, even from other agentless Jobs.

During the Dispatched phase of a Job, the proxy Platform Agent (on Server 2 in the diagram) tries to access the target server's ADMIN$ share, in particular \\host\ADMIN$\Temp. This is the default system temp directory. The proxy Platform Agent creates a temporary directory and stores a small executable and a log file there. If the creation of this temporary directory and the files succeeds, it is able to call the copied executable in order to create a temporary network share to \\proxyhost\agent-SystemId_port-dataroot with a temporary drive letter.

If the access to the ADMIN$ share fails, the proxy Platform Agent runs NET USE directly. This has the disadvantage that it needs to pass the password in clear text, and cannot handle all possible punctuation characters in passwords. In particular, a password containing a single or double quote or a space may not function correctly on all Windows versions. You can either change the password or enable access to the ADMIN$ share on the target host.

Once the temporary drive has been set up, the Job goes into the Running status. The Platform Agent on the proxy server asks WMI to start a second copy of the job processor, but this time running on the target host. The job processor on the target host switches to the correct WoW (Windows On Windows) environment if a 64 bit execution environment is requested, and runs the CMD script or CMD shim. Because CMD is used for all Definition Types as a buffer to set up the correct environment for the Job, it is required for all Jobs. Unfortunately, CMD requires a current directory that starts with a drive letter. This is why RunMyJobs must set up a temporary share for every job.

Once the user code is finished executing, the WMI session ends. This automatically cleans up the temporary network share access and drive letter on the target server. The job processor on the proxy server then removes the temporary directory in ADMIN$\Temp and copies any log files to the JobFiles directory. You can find these extra log files as extra files attached to the Job.

• stdsetup.log contains the execution log of setting up the \\host\agent-SystemID_port-dataroot share.
• stdremote.log contains the execution log of the actual job processor running on the remote Platform Agent.

Debugging Agentless Connections

When you run an agentless process, it is executed by calling remote (SSH or WMI) software from a job processor on the proxy server. A stdlog.log file is created by this job-processor process. If you need to analyze the operation of the remote OS job creation, you must change the log level setting of the proxy Job Server, and not the target Job Server.

Configuring WMI Port Ranges or Static Ports

By default, WMI initially makes a call from the client server to the target server via RPC on port 135. Subsequent calls are then made on various ports in the range defined for WMI. The port ranges differ for the various supported Windows versions. For more information, see KB832017.