locked
Synthetic Transactions Using Watcher Node as Target FQDN Instead of Pool Name:10061, No connection could be made because the target machine actively refused it RRS feed

  • Question

  • I checked the status of the synthetic transactions in the event viewer and saw that none of them were completing. After looking at the logs for a bit, I noticed that all of the synthetic transactions are using the FQDN of my watcher node as the Target FQDN instead of Lync pool name. As a result, all automatic executions of the synthetic transactions are failing.

    If I replace the watcher node FQDN with the pool FQDN and manually run the command string from the event log, the transactions run successfully. If the transactions are run manually as-is they fail. So, the question is, how do I ensure that the pool name is passed into the $poolfqdn variable instead of the name of my watcher node?


    When I setup synthetic transactions, I used the following commands.

    New-CsTrustedApplicationPool –Identity "WatcherNode.mydomain.com" –Registrar "lyncpool.mydomain.com" –ThrottleAsServer $True –TreatAsAuthenticated $True –OutboundOnly $False –RequiresReplication $True –ComputerFqdn "WatcherNode.mydomain.com" –Site "TEST"
    
    New-CsTrustedApplication –ApplicationId STWatcherNode –TrustedApplicationPoolFqdn "WatcherNode.mydomain.com" –Port 5061


    Event log information is included below.

    Synthetic Transaction [GroupIM] against [WatcherNode.mydomain.com] : 
    GroupIM synthetic transaction execution started against WatcherNode.mydomain.com.
    GroupIM synthetic transaction execution completed. 
    Result:
    
    Target Fqdn   : WatcherNode.mydomain.com
    Result        : Failure
    Latency       : 00:00:00
    Error Message : 10061, No connection could be made because the target machine 
                    actively refused it 172.x.x.x:5061
                    Inner Exception:No connection could be made because the target 
                    machine actively refused it 172.x.x.x:5061
                    
    Diagnosis     : 
                    
    GroupIM synthetic transaction execution logs:
     Workflow Instance Id '2a3e0504-e5d0-491b-b0eb-10423ed33e20', started.
    Command line executed is '        $result = . $stName $poolFqdn -SenderSipAddress $senderSipAddress -ReceiverSipAddress $receiverSipAddress -RegistrarPort $portNumber -Authentication $authentication -OutVerboseVariable detailLogs -OutLoggerVariable detailedSchematicLogs  
    '.
    Workflow 'Microsoft.Rtc.SyntheticTransactions.Workflows.STGroupIMWorkflow' started.
    Workflow 'Microsoft.Rtc.SyntheticTransactions.Workflows.STGroupIMWorkflow' completed in '7.2E-05' seconds.
    An exception 'Unable to establish a connection.' occurred during Workflow Microsoft.Rtc.SyntheticTransactions.Workflows.STGroupIMWorkflow execution.
    Exception Call Stack:    at Microsoft.Rtc.Signaling.SipAsyncResult`1.ThrowIfFailed()
       at Microsoft.Rtc.Collaboration.LocalEndpoint.EndEstablish(IAsyncResult result)
       at Microsoft.Rtc.SyntheticTransactions.Activities.RegisterActivity.InternalExecute(ActivityExecutionContext executionContext)
       at Microsoft.Rtc.SyntheticTransactions.Activities.SyntheticTransactionsActivity.Execute(ActivityExecutionContext executionContext)
       at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity, ActivityExecutionContext executionContext)
       at System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime)
       at System.Workflow.Runtime.Scheduler.Run()
       at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
       at Microsoft.Rtc.Internal.Sip.TcpTransport.OnConnected(Object arg)
    'RegisterActivity2' sequence activity started.
    'RegisterActivity2' sequence activity completed in '3.15E-05' seconds.
    'Register' activity started.
    Sending Registration request:
    	Target Fqdn      = WatcherNode.mydomain.com 
    	User Sip Address = sip:franklin.roosevelt@mydomain.com 
    	Registrar Port = 5061.
    Authentication Type 'Trusted' is selected.
    'RegisterActivity2' sequence activity started.
    'RegisterActivity2' sequence activity completed in '3.49E-05' seconds.
    'Register' activity started.
    Sending Registration request:
    	Target Fqdn      = WatcherNode.mydomain.com 
    	User Sip Address = sip:george.washington@mydomain.com 
    	Registrar Port = 5061.
    Authentication Type 'Trusted' is selected.
    'UnRegister' activity started.
    'UnRegister' activity completed in '0.000646' seconds.
    'UnRegister' activity started.
    'UnRegister' activity completed in '0.0004914' seconds.
    
    Workflow Instance ID '2a3e0504-e5d0-491b-b0eb-10423ed33e20' completed.
    Workflow run-time (sec): 8.3148533.
    
    Log File path (local):      C:\Program Files\Common Files\Microsoft Lync Server 2013\Watcher Node\20140411_0544_GroupIM_WatcherNode.mydomain.com.html
    Log File path (unc):      \\WatcherNode.mydomain.com\Watcher Node\20140411_0544_GroupIM_WatcherNode.mydomain.com.html
    
    Thanks

    Wednesday, April 16, 2014 7:57 PM

Answers

  • The value of parameter Identity of the command New-CsTrustedApplicationPool is the FQDN of the new pool.

    Note that while the Identity value for creating a pool is the pool FQDN, the value that will be stored as the Identity with the new pool is actually an automatically generated service ID of the pool. The Identity entered here will be saved as the PoolFqdn.

    Registrar indicates the service ID or Registrar service for the pool.


    Lisa Zheng
    TechNet Community Support

    • Proposed as answer by Lisa.zheng Wednesday, April 23, 2014 6:09 AM
    • Marked as answer by Lisa.zheng Friday, April 25, 2014 1:53 AM
    Thursday, April 17, 2014 8:52 AM
  • Lisa,

    I was able to resolve this. The issue was not tied to the New-CSApplicationPool cmdlet. Instead, I had to adjust the New-CSWatcherNodeConfiguration parameters to point the TargetFQDN to the primary Lync pool.

    New-CsWatcherNodeConfiguration –TargetFqdn "lyncpool.mydomain.com"
    Mike

    • Proposed as answer by Lisa.zheng Wednesday, April 23, 2014 6:09 AM
    • Marked as answer by Lisa.zheng Friday, April 25, 2014 1:53 AM
    Monday, April 21, 2014 2:10 PM

All replies

  • The value of parameter Identity of the command New-CsTrustedApplicationPool is the FQDN of the new pool.

    Note that while the Identity value for creating a pool is the pool FQDN, the value that will be stored as the Identity with the new pool is actually an automatically generated service ID of the pool. The Identity entered here will be saved as the PoolFqdn.

    Registrar indicates the service ID or Registrar service for the pool.


    Lisa Zheng
    TechNet Community Support

    • Proposed as answer by Lisa.zheng Wednesday, April 23, 2014 6:09 AM
    • Marked as answer by Lisa.zheng Friday, April 25, 2014 1:53 AM
    Thursday, April 17, 2014 8:52 AM
  • Thanks, Lisa!

    If I am following you properly, I would need to set the -Identity flag to the default lync pool (the FQDN that works on the command line). So, the new command would look like this.

    New-CsTrustedApplicationPool -Identity "lyncpool.mydomain.com" –Registrar "lyncpool.mydomain.com" –ThrottleAsServer $True –TreatAsAuthenticated $True –OutboundOnly $False –RequiresReplication $True –ComputerFqdn "WatcherNode.mydomain.com" –Site "TEST"

    However, upon entering that, I a get an error.

    New-CsTrustedApplicationPool : Cannot add a computer to a pool that contains service roles other than the trusted application server role. To add a computer, use Topology Builder.

    So, I'm still stuck.

    Mike


    Thursday, April 17, 2014 8:01 PM
  • Lisa,

    I was able to resolve this. The issue was not tied to the New-CSApplicationPool cmdlet. Instead, I had to adjust the New-CSWatcherNodeConfiguration parameters to point the TargetFQDN to the primary Lync pool.

    New-CsWatcherNodeConfiguration –TargetFqdn "lyncpool.mydomain.com"
    Mike

    • Proposed as answer by Lisa.zheng Wednesday, April 23, 2014 6:09 AM
    • Marked as answer by Lisa.zheng Friday, April 25, 2014 1:53 AM
    Monday, April 21, 2014 2:10 PM
  • Glad to hear that!

    Best Regards,

    Lisa


    Lisa Zheng
    TechNet Community Support

    Wednesday, April 23, 2014 6:08 AM