Changing the default Development Agent

How to replace the default development Agent with another Agent.

There may come a time when you need to move your development work to a different server, whether due to hardware upgrades, infrastructure changes, or simply wanting to consolidate your development environment. This guide walks you through the process of safely transitioning your default development Agent from one server to another.

Prerequisites

Before changing your default development Agent, you should have Administrator access to your Frends tenant to access the Administration UI where Agents, Agent Groups, and Environments are configured.

You'll also need access to both the current and target servers, along with the necessary permissions to install, uninstall, and run the Frends Agent Service on those machines.

In the case of moving the development Agent from Frends Cloud, you need to work together with Frends Support to perform the actions.

The Default Development Environment

The Frends Platform comes with a built-in Development Environment and a corresponding Development Agent Group. These are your default starting points for building and testing integrations. You can easily spot them in your browser's address bar, as they are represented by /Default/Default in the URL, like https://tenantname.frendsapp.com/Process/List/Default/Default.

Default Environment & Agent Group in Frends Tenant.

It's important to remember that while you can change the "Display Name" of these in the Administration UI, this is only a visual tweak. The underlying real names, which must be unique across your Frends instance, remain the same.

You also cannot delete the /Default/Default Agent Group or the /Default/ Environment, even if they are empty. Also, there isn't a simple toggle to designate another existing Agent or Agent Group as the new development default. This means you'll need to reconfigure an Agent to run specifically in the /Default/Default Agent Group to make it your new development Agent.

Constraints

Before making changes, it's helpful to understand a few basic constraints within Frends.

For Agents, Agent Groups, and Environments, their real names cannot be changed after they have been created. An Agent is also permanently tied to the Agent Group and Environment it was assigned to upon creation. Similarly, an Agent Group is fixed within its Environment.

You can delete an Agent from the UI once it has been offline for at least ten minutes, and an Agent Group can be deleted only if it contains no Agents. An Environment can be deleted when no Agent Groups are configured under it, but be aware that this action will also permanently delete any Environment Variable values associated with it.

An exception to the above are the Default Environments and Agent Groups, as explained above.

Preparing to Switch Agents

Before you begin the actual switch, you need to prepare both the current and target servers. On the current server where your existing development Agent is running (let's call it Server X with Agent X), you should plan to stop and uninstall the Frends Agent Service. This ensures that Agent X won't start up again and cause conflicts with your new setup.

If your target server (Server Y) already has a different Frends Agent running on it, you'll need to stop and uninstall that Agent as well. While it's technically possible to run multiple Frends Agents on a single server, this is not a recommended practice as it can lead to complex management scenarios and potential conflicts.

Switching Your Development Agent

Now you're ready to perform the actual switch. This process involves removing the old Agent configuration and installing a new one on your target server.

Stop and Remove the Old Agent

First, navigate to Server X and stop the Frends Agent Service. Once the service is stopped, uninstall the Agent to ensure it doesn't start up again. After the Agent has been offline for at least 10 minutes, it will become eligible for deletion in the Frends UI. The recommended approach is to wait for this period and then remove Agent X's configuration from the Administration UI. This clean removal ensures there's no confusion about which Agent is active.

Deleting an Agent from Agent Group.

Prepare the Target Server

If there's an existing Frends Agent running on Server Y that you want to repurpose, stop its service and uninstall it now. This clears the way for your new development Agent installation.

Create and Install the New Agent

Now you can create a new configuration for your new Agent (Agent Y) within the default /Default/Default Agent Group in the Administration UI. Once the configuration is created, download the installation package and configuration file. Transfer these files to Server Y and proceed with the installation following the standard Agent installation process.

Download the configuration or installer for newly configured Agent.

Alternative Approach: Reusing the Configuration

Alternatively, if you prefer to reuse the configuration of Agent X for Agent Y, you can skip the step of removing the old Agent X configuration from the UI. Instead, simply download the existing configuration's installation package and configuration file.

However, you must carefully ensure that this configuration is valid for the new Server Y before proceeding with the installation. This approach can be faster but requires more careful validation that all settings, paths, and configurations are appropriate for Server Y.

This approach is not possible when moving away from development Agent in Frends Cloud, as the configuration is different for Cloud Agents than for Self-Service Agents.

Final Notes

Remember that throughout this process, you're not changing what the default Development Environment is, but rather changing which physical server and Agent installation serves that role. The /Default/Default designation in Frends remains the same, ensuring your Processes and configurations continue to reference the correct Development Environment.

As mentioned earlier, while running multiple Frends Agents on a single server is technically possible, it's best to avoid this configuration to prevent management complexity and potential resource conflicts.

Last updated

Was this helpful?