Test-CsRegistration -TargetFqdn <String> [-Force <SwitchParameter>] [-OutVerboseVariable <String>] [-RegistrarPort <Nullable>] [-UserSipAddress <String>]

Test-CsRegistration -TargetFqdn <String> -UserCredential <PSCredential> -UserSipAddress <String> [-Force <SwitchParameter>] [-OutVerboseVariable <String>] [-RegistrarPort <Nullable>]

Parameters

Test-CsRegistration 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-CsRegistration cmdlet enables you to verify that users in your organization can log on to Microsoft Communications Server. In order to perform this check, Test-CsRegistration requires a single test account. 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 an account; instead, Test-CsRegistration will automatically use the first test account that was assigned to the health monitoring registrar. (See the help topic New-CsHealthMonitoringConfiguration for more information.) Alternatively, you can conduct the test using an account that has not been 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 a specific user log on to Communications Server. (If you choose to use this approach, you will need to provide the user name and password for the account being tested.)

When you run Test-CsRegistration, the cmdlet attempts to sign the test user on to Microsoft Communications Server and then, if successful, disconnects that test user 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. When the Ken Myer test account logs off from the system Ken Myer the person will remain logged on.

Adding the -Verbose parameter enables you to get a detailed account of all the actions taken by Test-CsRegistration in order to complete its test.

Test-CsRegistration returns an instance of the Microsoft.Rtc.SyntheticTransactions.TaskOutput object.

-------------------------- Example 1 --------------------------

	Copy Code
Test-CsRegistration -TargetFqdn atl-cs-001.litwareinc.com

The preceding example tests the Registrar service for the pool atl-cs-001.litwareinc.com. 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 or not the first test user in the health monitoring registrar is able to logon to Microsoft Communications Server.

If a registrar has not been defined then the command will fail because it will not know which user to logon as. If you have not defined a health monitoring registrar for a pool then you must include the -UserSipAddress parameter and the credentials of the user that the command should use when trying to logon.

-------------------------- Example 2 --------------------------

	Copy Code
$cred1 = Get-Credential "litwareinc\jhaas" Test-CsRegistration -TargetFqdn atl-cs-001.litwareinc.com -UserCredential $cred1 -UserSipAddress "sip:jhaas@litwareinc.com"

The commands shown in Example 2 test the ability of a specific user (litwareinc\jhaas) to logon on to Microsoft Communications Server. 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 then checks to see if this user can log on to the pool atl-cs-001.litwareinc.com. To carry out this task, Test-CsRegistration is called, along with three parameters: -TargetFqdn (the fully qualified domain name of the registrar pool); -UserCredential (the PowerShell object containing Jonathan Haas’ user credentials); and -UserSipAddress (the SIP address corresponding to the supplied user credentials).