Runtime Resource Receives Connection Attempts from a Second Application Server Every 30 Seconds

[m.kupplich]

Hello everyone,

I'm investigating a strange behavior in a Blue Prism environment and would appreciate any insights from people who may have seen something similar.

Environment

• Blue Prism 7.3.x
• Separate DEV and PROD environments
• Dedicated Application Server and database for each environment
• Runtime Resources connect through Application Servers (no direct database connections)
• WCF SOAP with Transport Encryption
• ASCR enabled (gRPC)
• Runtime Resources use the standard Resource PC listener on port 8181

Problem Description

One specific Runtime Resource behaves differently from all other Runtime Resources in the environment.

The resource is explicitly started using the PROD connection:

/resourcepc /public /dbconname PROD_Connection

`

The listener log shows:

checking connection 'PROD_Connection'

connected to 'PROD Application Server'

Listener started

The resource appears correctly in the PROD Control Room and functions normally:

• Processes can be started successfully
• Processes run and complete successfully
• The resource remains online in PROD
• No unexpected disconnects from PROD occur

From a production perspective, everything appears to work correctly.

Unexpected Behavior

Despite being connected and fully operational in PROD, the listener continuously receives incoming connections from the DEV Application Server.

Example:

New connection from DEV-AppServer

Disconnected ... quit

These connection attempts occur approximately every 30 seconds.

What is important here is that:

• The Runtime Resource is connected to PROD
• The DEV Application Server initiates the connection
• The Runtime Resource is not attempting to connect to DEV

Why This Seems Unusual

Other Runtime Resources in the environment:

• Use the same configuration structure
• Have the same connection definitions available locally
• Are known in both DEV and PROD environments
• Use the same startup mechanism

However, none of them exhibit this behavior.

The issue is isolated to a single Runtime Resource.

Investigation Already Performed

Runtime Resource Side

• Compared Automate.config with working Runtime Resources
• Compared LoginAgentService.config with working Runtime Resources
• Explicitly used /dbconname PROD_Connection
• Reinstalled Login Agent
• Rebooted the machine
• Confirmed only a single Automate.exe instance is running
• Verified listener functionality on port 8181

Database Investigation

• No active or hanging sessions found for this Runtime Resource
• No open sessions found in BPASession
• Historical schedules referencing the resource were found
• Schedule execution logs show no recent executions

Scheduler Test

To determine whether the DEV Scheduler was responsible for the connection attempts:

1. Scheduler disabled on DEV
2. DEV Application Server restarted
3. Connection attempts continued

Therefore, the Scheduler appears not to be the cause.

Application Server Test

When the DEV Application Server service is stopped:

No incoming connections from DEV

`

When the DEV Application Server service is started again:

Incoming connections from DEV immediately resume

This strongly suggests that the DEV Application Server itself is actively initiating these connections.

Main Question

Has anyone experienced a situation where:

• A Runtime Resource is connected and operating normally in Environment A (PROD)
• A second Application Server from Environment B (DEV) repeatedly attempts to connect to that Runtime Resource
• The Runtime Resource remains fully functional in PROD
• Other Runtime Resources in the same setup do not show the same behavior

Additional Concern

At the moment this does not appear to be causing any functional issues because the Runtime Resource remains connected to PROD and can execute processes normally.

However, my concern is understanding why the DEV Application Server is attempting to communicate with this specific Runtime Resource every 30 seconds.

I am worried that at some point DEV could inadvertently interfere with the Runtime Resource, create session conflicts, affect scheduling behavior, or otherwise interact with a machine that should currently be operating exclusively in PROD.

Areas I'm Currently Considering

• ASCR (Application Server Controlled Resources)
• gRPC callback registrations
• Resource registration metadata
• Stale runtime references
• Internal health checks
• Callback channels
• Load balancing or Application Server routing behavior

Has anyone seen similar behavior or have any suggestions on where to investigate next?

Thanks in advance for any ideas or guidance.
Michael

[greggoodrem]

Was this an additional resource to your estate?
If so it could be that your infrastructure team has added it to the incorrect AD group (either way a different set of rules are clearly applying here). Knock on effect could be that you have a refreshing group policy in the background that is triggering the start of your listener?!
 Worth checking the bots user account incase that has been incorrectly setup.

[jegendra]

Hi Michael,

You mentioned that the Production Runtime Resource continues to receive incoming connections from the DEV application server.
As a next step, can you rename the Runtime Resource's hostname, register it as a new instance in the production environment, and observe the behaviour further from the Resource PC Console?

[m.kupplich]

Hi Jega,

Thank you for your suggestion.

Before renaming the Runtime Resource, I would like to share an additional finding from my investigation.

I was able to confirm that the connection attempts are initiated directly by the DEV Application Server (BPServerService.exe). Network traces on the DEV server showed repeated TCP connections from the DEV Application Server to the Runtime Resource listener on port 8181.

I also performed the following test:

• When the DEV Application Server service was stopped, the connection attempts immediately stopped.
• When the DEV Application Server service was started again, the connection attempts immediately resumed.
• Disabling the DEV Scheduler had no effect.

Most importantly:

After removing the Runtime Resource from the DEV environment, the repeated connection attempts stopped completely.

This seems to indicate that the DEV Application Server is actively trying to communicate with the Runtime Resource because it is still known to the DEV environment.

The Runtime Resource is already connected to PROD and operates normally there. Processes can be started successfully and the resource remains online in PROD.

Before I proceed with renaming the machine, could you advise:

• What internal mechanism in Blue Prism would cause BPServerService.exe to repeatedly connect to a Runtime Resource simply because it exists in the environment?
• Is this expected behaviour with ASCR or Runtime Resource registration?
• Are there any tables, logs or configuration areas that would explain why one specific Runtime Resource is being polled while identical Runtime Resources are not?

Kind regards
Michael

[m.kupplich]

Thanks for the suggestion.

I did some additional investigation and found something interesting.

The repeated connection attempts are being initiated directly by BPServerService.exe running on the DEV Application Server.

I was able to verify this using netstat and tasklist. The DEV Application Server repeatedly opens TCP connections to the Runtime Resource listener on port 8181.

I also found that:

- Stopping the DEV Application Server immediately stops the connection attempts.

- Starting the DEV Application Server immediately resumes them.

- Disabling the DEV Scheduler has no effect.

- Removing the Runtime Resource from the DEV environment stops the connection attempts completely.

Because of this, I am currently leaning more towards a Blue Prism resource registration / application server behaviour rather than an AD group, GPO or bot account configuration issue.

That said, I will still double-check the machine and bot account configuration to make sure nothing unusual exists there.

Thanks for the suggestion.

[greggoodrem]

How have you got on with this issue have you used BP Support to check the setup?

[hossein.azimi]

Hello Michael,

Thank you for contacting Blue Prism community.

I'd check the DEV Application Server's own database (BPAResource table) for a record matching this Runtime Resource. Application Servers periodically poll every resource they have registered, independent of active sessions — that matches your logs exactly (connect, no session created, disconnect, repeats every ~30s). Since this is the only resource showing the behavior, it's likely the only one that ended up registered in both DEV and PROD (possibly from an earlier build step, VM clone, or a resource repoint that left a residual entry).

Suggested next step:
query DEV's BPAResource table by this resource's name/FQDN. If found, remove it via DEV's Control Room (or a controlled DB delete after confirming no DEV automations reference it) — this should stop the connection attempts without affecting the resource's operation in PROD.

I also suggested opening a support ticket for further investigation if necessary.

Regards
Hossein Azimi (APJ Team)