Lync PSTN Calls Fail: 2 Rings,Quit, Repeat

“Lather, rinse, repeat” – the other day that is how we felt. 

Thanks go to a variety of folks who helped get us through this.  A special call-out to Justin Hiedeman for maintaining his perspective in trying times.

Scenario

We have a semi-greenfield of Lync 2013, HA –3 nodes of FE, single PSTN trunk to an AudioCodes Mediant 3000, Level 3 is the SIP Trunk provider.

The Issue (Lather, Rinse, Repeat)

Incoming PSTN calls were being disconnected and reported as a missed call at approximately 2 rings and a brief 2 second toast from the Lync client. If the user was logged out, the calls would immediately go to VM. If the user set the Call Forwarding – Unanswered Calls” to 5 seconds it would work, anything higher than that resulted in the described bad behavior.

Lync to Lync (P2P) calls operated normally; going to voice mail direct from inside the Lync client was normal.  The client is Lync 2013.

Needless to say, this was very annoying to the end-user. At one point we thought a certain individual might burst into flame. Not having a fire extinguisher handy, we thought we might look into what was causing this (annoying) call behavior.

Troubleshooting

Both Level 3 and AudioCodes indicated this was an issue with the Mediation server configuration. The fact that Lync to Lync calls (P2P) worked as advertised led us to believe it was either with the AudioCodes or Level 3. After discussing the obvious finger-pointing, we turned back to the job at hand.  Troubleshooting consisted of using OCSLogger and Snooper resulting in narrowing down the call appearing to drop with highlighted line below. Which was consistent with all calls.  Using the ACSyslog, we discovered that after the below error that a 183 was received from Level 3 which terminated the call.

ms-diagnostics: 10037;source="serverfqdn.domain.com";reason="Normal termination response from gateway before the call was established";component="MediationServer";sip-reason="Q.850 ;cause=31 ;text="local, RTP Broken Connection""ms-diagnostics-public: 10037;reason="Normal termination response from gateway before the call was established";component="MediationServer";sip-reason="Q.850 ;cause=31 ;text="local, RTP Broken Connection"" ,

We also terminated (shut off, disabled) the mediation server service on two of the three Front End servers)

Because AudioCodes was so adamant about it not being their issue, we then spent the better part of 3 hours with a friendly soul from Microsoft.  It was gratifying to note that the “expert” support engineer went over all the exact same items we had already checked – and guess what?  We now had  verification that we were right: the Lync trunk to gateway setup was fine.  As a final note to the Microsoft CSS call, the CSS engineer had us try this:  http://support.microsoft.com/kb/2817465 in a vain hope to getting something sort of related to fix our issue.  Note the date on this update would indicate that this is part of CU2 for the Lync 2013 client but one can never tell.

However – and here is why it sometimes pays dividends to call CSS - within the MS internal article database our technician discovered a similar issue with a previous case that involved an AudioCodes Gateway. The MS recommendation was to change the “Disconnect on Broken Connection” setting from Yes to No under the Advanced Parameters setting for SIP definitions.

This resulted in no change in the behavior. At this time, armed with the knowledge that the Lync setup was correct, we called AudioCodes.  We also got Level 3 on the same call.

The Fix

So here we are, two days into this <sigh>. All the same symptoms were occurring, Level 3 saw the disconnects, AudioCodes and the Lync Servers (Mediation service was shut down on two of the three servers) were seeing the broken Connection. On further inspection of the AudioCodes configuration it was discovered that the ‘Disconnect on Broken Connection’ setting is also in the profile Coders and Profiles Settings which would over-ride the setting in the SIP definitions. For this implementation two profiles were setup, one going to Lync and one going to Level 3.

After backing up the configuration this was changed to “No” for both profiles.  Note that this profile also has an “Advanced Parameter List” – more on that in just a bit.

Level 3 Profile

The Lync Profile was already done, but remember that “Advanced Parameters List” – you ought to, I have highlighted it twice now.  I will wait while you go back and check my math.

On the Profile for Lync the ‘Media Early 183’ setting was also enabled. It would appear that this was already set on the Level 3 profile.

The Outcome

After all this, an inbound call to Lync behaves as you would expect; user logged in or not.

YMMV

Crack a 2048 bit certificate

I have no background in determining how accurate this claim is, but the video is interesting, and even if it is only 1% accurate (in terms of time needed), then I think we are good.

Crack a 2048 bit certificate

YMMV

Windows 8.1 Usurps OneNote Snipper Tool

Usurper!

Well, not in the traditional “usurper” context, but I really like this word – so descriptive.  What has occurred of course, is that a higher-level product team basically said “too bad for you, we are taking the Windows+S key combination for OUR use.  Neener neener!  Or words and actions to that effect.  Which does not fit the definition of “usurp” – not exactly, but I really like that word. Adelante.

Which leaves us poor users in the lurch.  I don’t know about you, but I use TechSmith Snagit (tm) for screen caps. But I also use the snipper tool that comes with OneNote (oh so handy for those quickie screen caps that won’t need any editing, redacting, commenting, or other manipulation).  Until the other day when I updated to Windows 8.1 and discovered that my snipper tool looks a lot like Windows 8.1 Search.  Oddly, not only does snipper look like Windows 8.1 Search, but it functions just like Windows 8.1 Search. 

The Fix

Here is how to restore your beloved OneNote to its’ previous functionality. 

YMMV.

VMware Workstation Cannot Change Network to Bridged

Problem

Cannot change network to bridged: There are no un-bridged host network adapters.  Using VMWare Workstation 8.06.

Scenario

I ran Windows 8.1 Enterprise onto my work laptop.  Things were working just fine before (I never learn).  When I went to open a virtual I got the this lovely error message: 

Ain’t that purty?  Makes my virtual machine fairly useless.

Cause

It would appear that upgrading to Windows 8 removed the VMWare Bridge Protocol from all of my adapters.  Nice, huh?

FIx

After some reading that went further into the vagaries of VMWare and Windows 8 than I really wanted to go, I found this little gem:  http://blog.unixwiz.net/2010/09/vmware-workstation-there-are-no-un-bridged-host-network-adapters.html – and down towards the middle of that wonderfully detailed article is a bit about re-installing the VMware Bridge Protocol onto at least ONE of your network adapters.

YMMV.

Exchange ReadTrackingEnabled

As I have said before, I work with a great bunch of folks who possess, and daily exhibit, some deep skills.  Here is a sample email that went flying by the other day.

Background:  Jim Coan (Principal Consulting Engineer) and Vitaliy Mednik (Senior Consulting Engineer) are on CDW’s Microsoft Unified Communications team out of the Detroit area.  If I need help, these are two of the people to whom I turn for assistance. 

This is what Jim said at the bottom of his email:  “Considering this the frequency I’ve been asked about this I figured I’d share with the team.  I always get gripes when migrating from GroupWise to Exchange about this.”  Personally, I have not done a GroupWise migration in several years  - Jim seems to get stuck with them sandwiched between his other work. 

---

I’ve been asked more than a few times if there was a way to find out if a user has read/opened an email on Exchange.  My standard answer was that we can track mail flow to delivery and also to use message tracking when sending the message itself.  This was not an acceptable answer for the client I am currently working with so I did some extra digging and with a nudge in the right direction from our good friend Vitaliy Mednik I found this little jewel inside Set-OrganizationConfig called –ReadTrackingEnabled.  What this does in essence is turn on read receipts for everything in the organization.  It doesn’t replace read receipts, so users can still have that at their disposal, it is really more of a server side read receipt that can’t be canceled like a read receipt.  This can be good or bad depending on the perspective as it’s a bit more work for the servers to process. Ilse over at MS wrote up this little article that describes it pretty well.

http://blogs.technet.com/b/ilvancri/archive/2010/04/13/question-is-it-possible-to-check-if-a-message-has-been-read-even-when-the-sender-forgot-to-check-the-box-request-a-read-receipt-for-this-message.aspx

What isn’t included on that article is how to pull the information through PowerShell as an administrator.  The following commands will take care of that for you.

$temp = Search-MessageTrackingReport -Identity quest1@co.domain.com -Recipients "username@co.domain.com"

Get-MessageTrackingReport -Identity $temp.MessageTrackingReportID -RecipientPathFilter username@co.domain.com -ReportTemplate RecipientPath

Compliments of Mike Pfeiffer for the above PowerShell snippet and the full blog post can be found here.

http://www.mikepfeiffer.net/2012/01/generating-delivery-reports-and-tracking-messages-from-powershell/

As a side note, this works on 2010 & 2013 including Office 365.

As always YMMV.

---

HTH

Pithy but so true.

When you are dead, you do not know that you are dead.  It is difficult only for the others.

It is the same when you are stupid.