In some cases you might find that your synthetic transactions are failing with server timeout errors (error code 504). These errors are typically due to firewall problems. When a synthetic transaction is executed, that transaction runs under the MonitoringHost.exe process; in turn, MonitoringHost.exe starts an instance of the PowerShell.exe process. If either MonitoringHost.exe or PowerShell.exe is blocked by your firewall then the synthetic transaction will fail and will generate a 504 error.

To resolve this issue, you should manually create inbound firewall rules for both MonitoringHost.exe and PowerShell.exe.

If your watcher node computer is located outside your perimeter network, you will probably not be able to run the Data Conferencing Synthetic Transaction unless you first disable the Internet Explorer proxy settings for the Network Service account. To disable the proxy settings for this service, complete the following procedure:

1. On the watcher node computer, click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

2. In the console window, type the following command and then press ENTER:

   	Copy Code
   bitsadmin /util /SetIEProxy NetworkService NO_PROXY

The following message will appear in the command window:

	Copy Code
BITSAdmin is deprecated and is not guaranteed to be available in future versions of Windows. Administration tools for the BITS service are now provided by BITS PowerShell cmdlets. Internet proxy settings for account NetworkService set to NO_PROXY. (connection = default)

This message means that you have disabled the Internet Explorer proxy settings for the Network Service account.

The Exchange Unified Messaging (UM) synthetic transaction verifies that test users can connect to voicemail accounts homed in Exchange. These test users will need to be preconfigured with voicemail accounts before they can use the Exchange UM tests.

To use the Persistent Chat synthetic transaction, administrators must first create a channel and give the test users permissions to use it. The Test-CsPersistentChatMessage cmdlet can be used to properly configure these test users:

Copy Code

$cred1 = Get-Credential "litwareinc\kenmyer" $cred2 = Get-Credential "litwareinc\pilar" Test-CsPersistentChatMessage -TargetFqdn atl-cs-001.litwareinc.com -SenderSipAddress sip:kenmyer@litwareinc.com -SenderCredential $cred1 -ReceiverSipAddress sip:pilar@litwareinc.com -ReceiverCredential $cred2 -TestUser1SipAddress sip:kenmyer@litwareinc.com -TestUser2SipAddress sip:pilar@litwareinc.com -Setup $True

This setup task must be run from inside the enterprise:

• If run from a nonserver machine, the user who runs the cmdlet must be a member of the PersistentChatAdministrators role for Role-Based Access Control (RBAC).

• If run from the server itself, the user who runs the cmdlet should be a member of the RTCUniversalServerAdmins group.

In the preceding command, the Setup parameter was included and set to True ($True). If you include the Setup parameter, Test-CsPersistentChatMessage will create a special Persistent Chat room and populate that room with the test users. This helps to ensure that there is actually a chat room available for testing purposes. Note that the Setup parameter should be run only from a Front End Server.

The chat room that is created by Test-CsPersistentChatMessage can be deleted only by an administrator.

The Test-CsPstnPeerToPeerCall synthetic transaction verifies the ability to place and receive calls via the public switched telephone network (PSTN).

To run this synthetic transaction, administrators must configure:

• Two test users (a caller and a receiver) enabled for Enterprise Voice.

• Direct Inward Dialing (DID) numbers for each user account.

• Voice policies and voice routes that enable calls to the receiver’s number to reach the PSTN gateway.

• A PSTN gateway that accepts calls, and media that route calls backs to a receiver’s home pool based on the number dialed.

The Unified Contact Store synthetic transaction verifies that Lync Server 2013 is able to retrieve contacts on behalf of a user from Microsoft Exchange Server 2013.

To use this synthetic transaction, the following conditions must be met:

• Managing Server-to-Server Authentication (Oauth) and Partner Applications must be configured between Lync Server 2013 and Exchange 2013.

• Test users must have a valid Exchange 2013 mailbox.

After these conditions are met, administrators can run the following command to verify that the user with the SIP address kenmyer@litwareinc.com can retrieve his contacts from the unified contact store:

	Copy Code
Test-CsUnifiedContactStore -TargetFqdn atl-cs-001.litwareinc.com -UserSipAddress "sip:kenmyer@litwareinc.com" -RegistrarPort 5061 -Authentication TrustedServer -Setup

Note the use of the Setup parameter used in the preceding command. If the Setup parameter is included when running Test-CsUnifiedContactStore then the specified user’s contacts (in this case, sip:kenmyer@litwareinc.com) will be moved to the unified contact store. (Of course, if the user’s contacts are already in the Unified Contact Store then they do not have to be moved.) The Setup parameter is typically used only one time (the first time Test-CsUnifiedContactStore is executed), and should only be used with test users; that is, with user accounts that will never actually be logged on to Lync Server. After your test user has been migrated to the unified contact store, you can verify that the user’s contacts can be retrieved by calling Test-CsUnifiedContactStore without the Setup parameter:

	Copy Code
Test-CsUnifiedContactStore -TargetFqdn atl-cs-001.litwareinc.com -UserSipAddress "sip:kenmyer@litwareinc.com" -RegistrarPort 5061 -Authentication TrustedServer

The XMPP (Extensible Messaging and Presence Protocol) IM synthetic transaction requires that the XMPP feature be configured with one or more federated domains.

To enable the XMPP synthetic transaction, an XmppTestReceiverMailAddress parameter must be provided with a user account at a routable XMPP domain. For example:

	Copy Code
Set-CsWatcherNodeConfiguration -Identity pool0.contoso.com -Tests @{Add="XmppIM"} -XmppTestReceiverMailAddress user1@litwareinc.com

In this example, a Lync Server 2013 rule will need to exist to route messages for litwareinc.com to an XMPP gateway.