Lync Synthetic Tests: What They are and When They Don’t Work – Part II
In Part I of this series, I talked about what synthetic tests are, and some of the issues you may see when using them. Today I want to bring up another issue with synthetic tests. Let me show you how I found it.
I tried to use New-CsHealthMonitoringConfiguration to assign two newly created accounts for synthetic testing. As I mentioned in part I, configuring the accounts makes running the test cmdlets easier. The syntax to use is
New-CsHealthMonitoringConfiguration -identity [pool FQDN] -FirstTestUserSipUri [string] -FirstTestSamAccountName [string] -SecondTestUserSipUri [string] -SecondTestSamAccountName [string]
When I ran it in my client’s environment, I got back a nasty error:
New-CsHealthMonitoringConfiguration error
Notice that regex expression. Value must match pattern:[^\\/:\*\?\”<>\|\.][^\\/:\*\?\”<>\|]{0,14}\\[^\\/:\*\?\”<>\|\.][^\\/:\*\?\”<>\|]{0,14}”
At first I thought I didn’t have the SamAccountName in the correct format, but the New-CsHealthMonitoringConfiguration documentation clearly says I can use the domain\user format. Just as I was about to break out regex buddy to see what that regex was trying to match, I noticed the (0,14) at the end and wondered if it was only expecting up to 15 characters (starting at 0, 14 would be the 15th number). I looked at the test user SamAccountNames and they were more than 15 characters long. So I shortened them to 15 characters and ran the cmdlet again, and bingo – that worked. I tested some more and verified that as soon as the SamAccountName reaches 16 characters or more, I get the above error.
I looked at the documentation for SamAccountName and found that it supports, as I suspected, that it can be up to 19 characters in length. So the New-CsHealthMonitoringConfiguration limitation, which isn’t documented anywhere that I could find, can catch you up in environments where usernames can be longer, such as in my client’s.
I’ve reported this to the product group to get it documented.
As a side note, you can configure test accounts for every Front End and Director pool, and they should be different users for each pool.
Hopefully, this info will save you some troubleshooting time.
Hi Pat,
Many thanks for a great post on an area that I don’t think many people have explored. I wanted to know if you had experienced the same behaviour that I have seen:
I have successfully configured a SCOM 2007 R2 synthetic transactions watcher node for my Lync 2010 deployment and it’s generally working very well. However I have noticed that if the Test-CsPstnPeerToPeerCall fails then this will result in Lync Server marking the relevant gateway as being down and Lync Server will no longer submit calls to that gateway, even if the gateway is actually fully functional. So for example, my gateways were supporting many calls every hour without any problem until I enabled my ST watcher node. Because I had forgotten to enable my SCOM/Lync test accounts for Enterprise Voice and assign them to an appropriate voice policy (!) the automated Test-CsPstnPeerToPeerCall cmdlet immediately started to fail. Lync then marked the gateway as down and stopped sending calls to my gateway. It appears that the success/failure of this synthetic test overrides the usual SIP OPTIONS gateway availability test monitoring that Lync Server routinely performs. Once the SCOM/Lync test users were EV-enabled and added to a voice policy, test calls using Test-CsPstnPeerToPeerCall executed by the watcher node succeeded and the gateway was then marked as being available by Lync Server once again and calls started to succeed. I am surprised at this behaviour because a system such as SCOM is ultimately intended to maximise system uptime, but this behaviour can actually result in service interruption just because a synthetic transaction is failing. I have warned the system administrators to protect the SCOM/Lync test accounts at all costs.
have you seen this behaviour yourself?
Cheers,
Garry
We are experiencing the same issue and I am wondering if I should just override these PSTN Peer to Peer Call Synthetic Transaction failure alerts so it isn’t so noisy in our SCOM.