Actually, the command for the older versions of Windows and Powershell give us more information.
I ran some tests from my SCM Client machine targeting my SCM broker machine (olnx75) over port 5101.
1. The first test, broker is up and listening over port 5101 and firewall is down. Expecting a successful connection:
PS C:\Users\Administrator> $t = New-Object System.Net.Sockets.TcpClient 'olnx75', 5101; if ($t.Connected) {"OK"}
OK2. The second test, I stopped the broker, so it's no longer listening on port 5101, but the firewall is still down. This should simulate the 10065 error code:
PS C:\Users\Administrator> $t = New-Object System.Net.Sockets.TcpClient 'olnx75', 5101; if ($t.Connected) {"OK"}
New-Object : Exception calling ".ctor" with "2" argument(s): "
No connection could be made because the target machine actively refused it 192.168.56.105:5101"
At line:1 char:6
+ $t = New-Object System.Net.Sockets.TcpClient 'olnx75', 5101; if ($t.Connected) { ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [New-Object], MethodInvocationException
+ FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand
3. The third test, I restarted the broker but put the firewall back up. So this would simulate a port blockage :
PS C:\Users\Administrator> $t = New-Object System.Net.Sockets.TcpClient 'olnx75', 5101; if ($t.Connected) {"OK"}
New-Object : Exception calling ".ctor" with "2" argument(s): "
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.56.105:5101"At line:1 char:6
+ $t = New-Object System.Net.Sockets.TcpClient 'olnx75', 5101; if ($t.Connected) { ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [New-Object], MethodInvocationException
+ FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand
The same tests should work with the agent machine as well. Just substitute the hostname of the agent machine instead of the broker hostname, and substitute the agent's port number instead of 5101.
Let me know if this helps :)
Original Message:
Sent: 08-21-2019 10:30 AM
From: Melinda Skelton
Subject: Deploying to a remote agent / PEC error
You might check to see if the port is open for traffic in both directions.
You could also use one of the following powershell commands from the broker/openmake machine to see if there is any trouble with the port:
For newer versions of Windows (works on my Windows 2012 R2 test box)
Test-NetConnection -ComputerName agenthostname -port agentportnumber
(replace agenthostname with the hostname of the agent machine and replace agentportnumber with the actual port number)
If you are using an older version of Windows and Powershell where Test-NetConnection isn't available, here is a command that will accomplish the same thing. It will return an error message or "OK" if connection test was successful.
$t = New-Object System.Net.Sockets.TcpClient 'agenthostname', agentportnumber; if($t.Connected) {"OK"}
Let me know if this helps. :)
Melinda
Original Message:
Sent: 08-21-2019 09:12 AM
From: David Day
Subject: Deploying to a remote agent / PEC error
On thing that I can do -- is I can connect to the agent via that port in the Remote Agent Neighborhood on the Harvest server. I always works, every time. So you would think connectivity isn't the issue, unless it needs the port opened from the various other servers in play ---
Harvest Application Server ( has access to port through the firewall )
Openmake KB Server ( no rule in place )
Openmake Remote Build Server ( no rule in place )
The Target Server
When using an OM workflow to perform the actual deployment by executing an HCO command,
where is the connectivity actually needed?
Original Message------
Hello David,
Could you please try the below steps
A. The reason for PEC ec=10065, is not able to reach the machine or connect to the machine. To check the connectivity we can try below steps
1. Execute ping to be able to reach out to the agent machine from the machine where you are executing the command.
2. Execute ping to be able to reach out to the machine where you are executing the command from agent machine.
[Connectivity test between both the machines]
If you are able to ping in the above 2 steps and still facing the agent connectivity error, please try to connect to the agent using Fully Qualified Domain Name(FQDN)
B. The reason for PEC ec=10060, is not able to connect to that particular port. This may be due to agent not running or port got blocked.In this case please verify whether the agent is running properly or the agent running port is not blocked by any other application.
Please verify this and let us know the outcome.
You may kindly respond to
Swapna.akkaladevi@broadcom.com
Balakrishna.shantamurthy@broadcom.com
Thanks & Regards
Swapna.