Testing third-party audio conferencing in Lync Server 2013


Letztes Änderungsdatum des Themas: 2015-03-09

Verification schedule


Testing tool

Windows PowerShell

Permissions required

When run locally using the Lync Server-Verwaltungsshell, users must be members of the RTCUniversalServerAdmins security group.

When run using a remote instance of Windows PowerShell, users must be assigned an RBAC role that has permission to run the Test-CsAudioConferencingProvider cmdlet. To see a list of all RBAC roles that can use this cmdlet, run the following command from the Windows PowerShell prompt:

Get-CsAdminRole | Where-Object {$_.Cmdlets -match "Test-CsAudioConferencingProvider"}


An audio conferencing provider is a third-party company that provides organizations with conferencing services. Among other things, audio conferencing providers enable users located off site, and not connected to the corporate network or the Internet, to participate in the audio portion of a conference or meeting. Audio conferencing providers often provide high-end services such as live translation, transcription, and live per-conference operator assistance.

The Test-CsAudioConferencingProvider cmdlet is used to verify that a user is able to make a connection to his or her audio conferencing provider. Note that this cmdlet can be run in one of two ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users represent a pair of user accounts that have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) If test users are configured for a pool, administrators can run the Test-CsAudioConferencingProvider cmdlet against that pool without having to specify the identity of (and supply the credentials for) the user account involved in the test.

Alternatively, administrators can run the Test-CsAudioConferencingProvider cmdlet using an actual user account. If you decide to conduct the test using an actual user account you will need to supply the logon name and password for that account.

Running the test

Example 1 checks to see if a test user defined for the pool atl-cs-001.litwareinc.com is able to connect to his or her audio conferencing provider. This command requires that at least one test user be defined for the pool. If no test users have been defined for atl-cs-001.litwareinc.com, then the command will fail; that's because the Test-CsAudioConferencingProvider cmdlet will not know which user to employ in the test. If you have not defined test users for a pool, then you must include the UserSipAddress parameter and the credentials of the user account that the command should employ when verifying the connection with an audio conferencing provider.

Test-CsAudioConferencingProvider -TargetFqdn atl-cs-001.litwareinc.com 

The commands shown in Example 2 test the ability of a specific user (litwareinc\kenmyer) to connect to his audio conferencing provider. To do this, the first command in the example uses the Get-Credential cmdlet to create a Windows PowerShell command-line interface credentials object containing the name and password of the user Ken Myer. (Because the logon name litwareinc\kenmyer has been included as a parameter, the Windows PowerShell Credential Request dialog box only requires the administrator to enter the password for the Ken Myer account.) The resulting credentials object is stored in a variable named $credential.

The second command then checks to see if this user can connect to his audio conferencing provider. To carry out this task, the Test-CsAudioConferencingProvider cmdlet is called, along with three parameters: TargetFqdn (the FQDN of the Registrar pool); UserCredential (the Windows PowerShell object containing Ken Myer's user credentials); and UserSipAddress (the SIP address corresponding to the supplied user credentials).

$credential = Get-Credential "litwareinc\kenmyer" 
Test-CsAudioConferencingProvider -TargetFqdn atl-cs-001.litwareinc.com -UserSipAddress "sip:kenmyer@litwareinc.com" -UserCredential $credential

Determining success or failure

If the audio conferencing provider is correctly configured, you'll receive output similar to this, with the Result property marked as Success:

Target Fqdn : atl-sql-001.litwareinc.com

Result : Success

Latency : 00:00:00

Error Message :

Diagnosis :

If the specified user can't log on or log off, the Result will be shown as a Failure, and additional information will be recorded in the Error and Diagnosis properties:

Target Fqdn : atl-sql-001.litwareinc.com

Result : Failure

Latency : 00:00:00

Error Message : 10060, 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 [2001:4898:e8:f39e:5c9a:ad83:81b3:9944]:5061

Inner Exception: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


Diagnosis :

For example, the previous output includes the note “the connected party did not properly respond” That typically indicates a problem with the Edge Server.

Reasons why the test might have failed

Here are some common reasons why Test-CsAudioConferencingProvider might fail:

  • An incorrect parameter value was supplied. As shown in the previous example, the optional parameters must be configured correctly or the test will fail. Rerun the command without the optional parameters and see whether that succeeds.

  • Note that the test will fail if the user employed by the Test-CsAudioConferencingProvider cmdlet has not been assigned an audio conferencing provider.

  • This command will fail if the Edge Server is misconfigured or not yet deployed.