Skip to main content
System StatusContact Support

Documentation related to the following products will soon be moved to a new portal: ( Agility, Agility Connect and Agility Integrations Continuum and ALM Connect
Links from the site will automatically redirect to the new site.
If you have any questions, please contact Support. Agility Community

Continuum Automate Task Assets

An Asset can be a virtual machine in a cloud, a physical machine in a datacenter, or a software instance or service on one of these. For example, a Linux server, an instance of an Oracle Database, a Web server, etc. all are examples of Assets. An Asset represents an entity on which Tasks can perform work.


An Asset can be a virtual machine in a cloud, a physical machine in a datacenter, or a software instance or service on one of these. For example, a Linux server, an instance of an Oracle Database, a Web server, etc. all are examples of Assets. An Asset represents an entity on which Tasks can perform work.

Cloud computing and virtualization concepts such as Instances, Volumes and so on are often temporary entities, and are not represented by an Asset. Interaction with cloud resources is performed through the relevant Cloud Provider API commands. Assets are most commonly used to represent fixed systems.

Managing Assets

Assets can be accessed from the top menu by selecting Tasks -> Manage Assets.

Creating Assets

Select Tasks -> Manage Assets. Then select Create.

On the General tab, enter an Asset name and select the status and any other settings as required, then and select Save.

  • Asset Name - the name of the Asset, must be unique in the system. Required.
  • Status - Active or Inactive. Only Assets with a status of Active can be accessed by Tasks.
  • Address - This is the system address such as the IP Address or FQDN (fully qualified domain name). The Task Engine uses this address to establish connections.
  • DB Name - If this Asset is a database type of Asset, this would be the database name intended for use. If a single database server contains multiple schemas, each schema will be represented by a different Asset.
  • Port - This is the port to be used in a connection string. This is usually only needed if the default port is not used for a particular protocol (such as port 1433 for SQL Server databases).

On the Credentials tab, select or create the Credentials that will be used to connect to the Asset.

  • If you would like to use a Shared Credential that already exists in the system, select it from the list. This list displays credentials that are shared amongst multiple Assets.
  • To create a new 'local' credential for the Asset, select the credentials tab and select the New Credential button. Now select whether the credential should be available to be shared amongst multiple Assets or on will be local to this particular Asset.
  • The Privileged Password is an optional password used on network devices such as Cisco switches that may require a separate password to enable privileged mode.

After making all selections select Save.

Deleting Assets

Assets can be deleted, provided they do not have any Task history. If an Asset has history, it can be marked as Inactive until all history has expired, at which time it can be deleted.

  • Select Tasks > Manage Assets.
  • Select one or more Assets to delete using the checkboxes, then select Delete.
  • Select Delete in the delete confirmation dialog.

Editing an Asset

  • Select Tasks > Manage Assets.
    • Click the row for the Asset you wish to change -OR-
    • Select one or more Assets to edit using the checkboxes, then select Modify.
  • For each Asset, edit the settings as necessary and select Save.
    • If multiple Assets are selected, the dialog will move to the next Asset each time the Save button is clicked.


Assets can have local credentials (user login information specific only to that Asset), or shared credentials. Shared credentials allow a username/password or private key to be available to more than one Asset or process. Setting up user accounts with the appropriate log-in credentials on Assets enables Tasks connecting to the Assets via those user IDs to securely perform various commands.


When an Asset is a Unix machine, some Tasks may need to run commands or access files that require root-level privileges. To conform with least-privilege policies, we recommend granting "sudo" access to the ssh user that performs these commands rather than allow a Task to connect as root.

Following is a simple example - it is recommended this step be performed by a knowledgeable system administrator capable of granting all the necessary privileges.

To set up sudo access for a user on Unix operating systems:

  • Log into the Linux Asset as an administrator.
  • Edit /etc/sudoers to add a line that will grant the user access to the specific commands necessary. Examples of common commands often used for automation are ls, cat, grep, sed, awk, tail and so on. Make sure to set the secondary password prompt off. For example:

    myuser ALL=NOPASSWD:/bin/cat, /bin/grep, /bin/tail, /bin/ls

Once this change is in place, Tasks logging in as myuser will be able to perform the commands shown with sudo, for example sudo cat <filename>


Automate interacts with the Windows operating system using the Microsoft tool called WinRM (Windows Remote Management)

WinRM commands are executed in a very similar fashion as Unix Commands - by making a connection and then executing a series of commands. Valid Local or Active Directory credentials with sufficient permissions are necessary when making a connection to Windows.

WinRM is included by default in Windows Server 2008 and later. It is available on 2003 Server, and desktop versions Windows 7 and Vista, but some manual configuration is required.

WinRM is a powerful access layer, able to read the Windows Registry, access all the configuration information of a server via WMI. But most importantly, WinRM allows the remote execution of commands, and PowerShell scripts. WinRM is a significant step forward in the interoperability of the Windows platform, and using it Automate can do just about anything.

On Windows Server 2008, WinRM is installed by default. The following commands issued by an Administrator should be sufficient to enable and configure WinRM for remote access by Automate.

winrm qc -q
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}

Complete details of the configuration of WinRM, Active Directory, or PowerShell is beyond the scope of this document.