Using Synthetic Transactions to Identify Health Issues
Synthetic transactions were introduced in Lync Server 2010 and are a powerful way for administrators to validate the health of the environment. Lync Server synthetic transactions allow many different scenarios to be tested, all through PowerShell. These tasks are able to validate end-to-end scenarios such as making a call or joining a Lync conference. This section provides an understanding of how synthetic transactions work and common transactions that can be used to identify health issues.
Creating Lync Test Accounts for Synthetic Transactions
Test user accounts are required for synthetic transactions to validate user functionality. Although it is possible to run synthetic transactions by providing the credentials for valid user accounts, it is not recommended. The New-CSHealthMonitoringConfiguration cmdlet is used to define test accounts for each pool. When administrators specify two valid test accounts for each pool, it makes running synthetic transactions much easier because administrators are not required to provide credentials for each test. Before running this command, you should create two test accounts and enable the accounts for Lync Server. Also, be sure to assign any appropriate policies to account for scenarios you want to test. If you want to test PSTN calling, make sure that these users are enabled for Enterprise Voice and configured properly.
The command shown next creates a new health-monitoring configuration for NYPOOL01.COMPANYABC.COM. This pool will use [email protected] and [email protected] for synthetic transaction test accounts.
New-CSHealthMonitoringConfiguration -Identity NYPOOL01.companyabc.com - FirstTestUserSIPUri "sip:[email protected]"sip:[email protected] - SecondTestUserSipURI sip:[email protected]
Using Synthetic Transactions
After test accounts have been created, services can be tested using synthetic transactions. When performing synthetic transactions using preconfigured health accounts, the Lync Server machine account will be used to impersonate those users. As such, the use of synthetic transactions can become very simple; see the following text for examples.
To test that a user can sign on to the pool, essentially proving that the Front End Server is healthy for registration, use this:
Test-CSRegistration -TargetFQDN nypool01.companyabc.com
If it’s successful, the output should look similar to this:
Target Fqdn : nypool01.companyabc.com
Result : Success
Latency : 00:00:07.6614315
Error Message :
Diagnosis :
To test that a user can make an outbound PSTN call, including testing registration, the dial plans, and routing policies assigned, as well as the signaling and media path to the PSTN endpoint, use this:
Test-CSPSTNOutboundCall -TargetPSTNPhoneNumber 6000 -TargetFQDN nypool01.companyabc.com
If successful, the output should look similar to this:
Target Fqdn : nypool01.companyabc.com
Result : Success
Latency : 00:00:10.5099552
Error Message :
Diagnosis :
Tip
All Lync synthetic transactions are PowerShell cmdlets that begin with Test-. To identify a full list of cmdlets available, you can type Get-Command *test-* into a PowerShell window, which will return a list of available cmdlets.
The previous examples are just a small taste of what is available as part of Lync synthetic transactions. For a full list of synthetic transactions, navigate to the following URL, and explore all cmdlets with Test-CS in the name: http://technet.microsoft.com/en-us/library/gg398867.aspx.
Enabling Rich Logging for Synthetic Transactions
In Lync Server 2010, synthetic transactions were a great utility for identifying service issues. However, the information reported by a failed transaction test was often not enough to help users identify where the failure was occurring. At best, the verbose output of the cmdlets would provide a record of each step tested and it might enable an administrator to narrow down the source of the issue.
Lync Server 2013 introduces rich-logging capabilities in synthetic transactions. Each time a transaction is run, the following information is generated:
• The time started
• The time finished
• The action that was performed
• Messages generated by the activity (informational, verbose, warning, or error)
• SIP registration messages
• Exception records or diagnostic codes generated when the activity ran
• The result of the activity
Although this information is generated each time, a parameter must be added to a manually run synthetic transaction to output to a log file. This parameter is OutLoggerVariable. Use the following example to test logging in to Lync Server 2013 using Test-CSRegistration, and then to export the logging data to an HTML file for review.
Run the Test-CSRegistration cmdlet with the output parameter:
Test-CSRegistration -TargetFQDN Nypool01.companyabc.com -OutLoggerVariable TestRegistration
The logging data is then stored in the variable $TestRegistration as defined in the preceding cmdlet. Use the following command to export this data to HTML format:
$TestRegistration.ToHTML() | Out-File C:logsTestRegistration.Html
The report can then be opened in Internet Explorer to view the sequence of events, and any errors as appropriate. The example in Figure 13.14 shows a successful registration test.
Synthetic transactions should be a primary tool for administrators of all Lync Server 2013 environments. With this utility administrators have the ability to test and troubleshoot end-to-end user scenarios without requirements for end-user intervention.