Tests the ability of two users to conduct an instant messaging conference. Test-CsGroupIM is a "synthetic transaction": a simulation of common Microsoft Communications Server activities (in this case, conducting an online conference) used for health and performance monitoring.
Syntax
Test-CsGroupIM -TargetFqdn <String> [-Force <SwitchParameter>] [-OutVerboseVariable <String>] [-ReceiverSipAddress <String>] [-RegistrarPort <Nullable>] [-SenderSipAddress <String>] |
Test-CsGroupIM -TargetFqdn <String> -ReceiverCredential <PSCredential> -ReceiverSipAddress <String> -SenderCredential <PSCredential> -SenderSipAddress <String> [-Force <SwitchParameter>] [-OutVerboseVariable <String>] [-RegistrarPort <Nullable>] |
Parameters
| Parameter | Required | Type | Description |
|---|---|---|---|
|
TargetFqdn |
Required |
String |
Fully qualified domain name of the pool to be tested. |
|
RegistrarPort |
Optional |
Integer |
SIP port used by the Registrar service. This parameter is not required if the Registrar uses the default port 5061. |
|
SenderCredential |
Optional |
PS credential object |
User credential object for the first of the two user accounts to be tested. The value passed to SenderCredential should be an object reference obtained by using the Get-Credential cmdlet. For example, this code returns a credentials object for the user litwareinc\kenmyer and stores that object in a variable named $x: $x = Get-Credential "litwareinc\kenmyer" You need to supply the user password when running this command. The sender credential is not required if you are running the test under the health monitoring configuration for the pool. |
|
SenderSipAddress |
Optional |
String |
SIP address for the first of the two user accounts to be tested. For example: -SenderSipAddres "sip:kenmyer@litwareinc.com". The SenderSIPAddress parameter must reference the same user account as SenderCredential. The SIP address is not required if you are running the test under the health monitoring configuration for the pool. |
|
ReceiverCredential |
Optional |
PS credential object |
User credential object for the second of the two user accounts to be tested. The value passed to ReceiverCredential should be an object reference obtained by using the Get-Credential cmdlet. For example, this code returns a credentials object for the user litwareinc\jhaas and stores that object in a variable named $y: $y = Get-Credential "litwareinc\jhaas" You need to supply the user password when running this command. The receiver credential is not required if you are running the test under the health monitoring configuration for the pool. |
|
ReceiverSipAddress |
Optional |
String |
SIP address for the first of the two user accounts to be tested. For example: -ReceiverSipAddress "sip:jhaas@litwareinc.com". The ReceiverSIPAddress parameter must reference the same user account as ReceiverCredential. The SIP address is not required if you are running the test under the health monitoring configuration for the pool. |
|
Verbose |
Optional |
Switch Parameter |
Reports detailed activity to the screen as the cmdlet runs. |
|
Force |
Optional |
Switch Parameter |
Suppresses the display of any non-fatal error message that might arise when running the command. |
Detailed Description
Test-CsGroupIM is an example of a Communications Server "synthetic transaction." Synthetic transactions are used in Microsoft Communications Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the Public Switched Telephone Network (PSTN). These tests can be conducted "manually" by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager.
Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up a "health registrar" for each of their registrar pools. A health registrar is nothing more than a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts belonging to actual users.) With a health registrar configured for a pool, administrators can simply run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test.
Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts) and try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts keep in mind that you will have to supply the logon names and passwords for each user.
The Test-CsGroupIM cmdlet enables you to verify that users in your organization can conduct online conferences. Test-CsGroupIM requires two user accounts in order to conduct its tests. If you have set up a health monitoring registrar for the pool where the test is to be conducted then you do not need to specify these accounts; instead, Test-CsGroupIM will automatically use the accounts assigned to the health monitoring registrar. (See the help topic New-CsHealthMonitoringConfiguration for more information.) Alternatively, you can conduct the test using accounts other than the ones assigned to the registrar. This allows you run tests even if you have not configured a health monitoring registrar. It also allows you to test the ability of two specific users to conduct an online conference. (If you choose to use this approach, you will need to provide the user name and password for both users.)
When you run Test-CsGroupIM, the cmdlet attempts to sign both test users on to Microsoft Communications Server. If successful, Test-CsGroupIM creates a new conference using the first test user, then invites the second user to join the conference. After an exchange of messages, both users are then disconnected from the system. All of this happens without any user interaction, and without affecting any actual users. For example, suppose the test account sip:kenmyer@litwareinc.com corresponds to a real user with a real Microsoft Communications Server account. In that case, the test will be conducted without any disruption to the real Ken Myer. For example, even when the Ken Myer test account logs off from the system Ken Myer the person will remain logged on. Likewise, the real Ken Myer will not receive an invitation to join the conference. That invitation will be sent to, and accepted by, the test account.
Adding the -Verbose parameter enables you to get a detailed account of all the actions taken by Test-CsGroupIM in order to complete its test.
Return Types
Test-CsGroupIM returns an instance of the Microsoft.Rtc.SyntheticTransactions.TaskOutput object.
Examples
-------------------------- Example 1 --------------------------
 Copy Code |
|
|---|---|
Test-CsGroupIm -TargetFqdn atl-cs-001.litwareinc.com |
|
The preceding example checks to see if a pair of preconfigured test users can log on to the pool atl-cs-001.litwareinc.com and participate in an instant messaging conference. This command will work only if a health monitoring registrar has been defined for the pool atl-cs-001.litwareinc.com. If it has, then the command will determine whether the two users can log on to the system, then check to see if these users can participate in an instant messaging conference.
If a registrar has not been defined then the command will fail because it will not know which users to employ when doing the test. If you have not defined a health monitoring registrar for a pool then you must include the -SenderSipAddress and –ReceiverSipAddress parameters as well as the corresponding credentials for the users involved in the instant message exchange. Test-CsGroupIM will then conduct its checks using the two specified users.
-------------------------- Example 2 --------------------------
| Copy Code |
|
|---|---|
$cred1 = Get-Credential "litwareinc\jhaas" $cred2 = Get-Credential "litwareinc\kenmyer" Test-CsGroupIm -TargetFqdn atl-cs-001.litwareinc.com -SenderSipAddress "sip:jhaas@litwareinc.com" -SenderCredential $cred1 -ReceiverSipAddress "sip:kenmyer@litwareinc.com" -ReceiverCredential $cred2 |
|
The commands shown in Example 2 test the ability of a pair of users (litwareinc\jhaas and litwareinc\kenmyer) to logon on to Microsoft Communications Server and then participate in an instant messaging conference. To do this, the first command in the example uses the Get-Credential cmdlet to create a PowerShell credential object containing the name and password of the user Jonathan Haas. (Because the logon name - litwareinc\jhaas - has been included as a parameter, the resulting Windows PowerShell Credential Request dialog box only requires the administrator to enter the password for the Jonathan Haas account.) The resulting credential object is then stored in a variable named $cred1. The second command does the same thing, this time returning a credential object for the Ken Myer account.
With the two credential objects in hand, the third command in the example determines whether or not the two users can log on to Microsoft Communications Server and then participate in an instant messaging conference. To carry out this task, Test-CsGroupIM is called, along with the following parameters: -TargetFqdn (the fully qualified domain name of the registrar pool); -SenderSipAddress (the SIP address for user 1); -SenderCredential (the PowerShell object containing the credentials for user 1); -ReceiverSipAddress (the SIP address for user 2); and –ReceiverCredential (the PowerShell object containing the credentials for user 2).