Unable to route incoming call to a single Lync 2013 User.

Recently I came across a strange problem which I thought I would share.

The scenario is Lync Server 2013 Standard edition and Lync Server 2010 Mediation server(in process of migrating). The problem started when a user reported that he wasn’t able to receive incoming PSTN calls. Outbound calls was working just fine.

I started investigating the problem and ran some tracing with Wireshark on the Mediation server along with Lync Server logging tool. The Wireshark traces showed that the Lync Mediation server was sending “487 – Request terminated” to the PSTN gateway after receiving a CANCEL.
Snooper logs was showing the same messages and also in some cases “504 – Server timed out”. The Lync Monitoring server had no records of the call beeing established at all. After checking with the service provider of the PSTN gateway and doing some thorough checks of the unassigned numbers and all other kind of stuff(including the use of this script from a colleague to check all registered telephone numbers used in Lync and other systems), I was left in the dark. There was no reason for this not to work as it should.

Solution: Rebooted the Lync 2013 FrontEnd server, and everything worked like a charm.
Key takeaway from this post: When in doubt, reboot :-)

Windows Server 2012 Certificate issues with Lync.

With the new Windows Server 2012 and the enhanced certificate control, some may have experienced different “strange” error scenarios. Features stop working, and servers are behaving strange.

In Lync, one of the most common situations is when federation stops working. In most cases, you’re able to see Messages in the event log on you Access edge server indicating that something is wrong with the certificates. The Server 2012 has a more strict certificate handling than previous server versions, and the placing of certificates in the certificate store is critical.

Make sure that no intermediate certificates are placed under Trusted Root Certificates. If they are, this will break the certificate structure on the server and strange errors will start to appear in the event logs.

To check if you have certificates in the wrong stores, the following PS command can be run(it will list the certificates with wrong location):

Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File “c:\computer_filtered.txt”

Lync Server 2013: Event ID 32054, LS Storage Service

Problem With event ID 32054 appearing in event log onm Lync 2013 server.

The scenario is as follows:
Lync 2010 upgraded to Lync 2013 CU3 in co-excistence with Exchange 2010 SP2 running on Windows Server 2008 R2.

Problem:
The event log on the Lync 2013 server is showing repeated event ID 32054. “Sorage Service had an EWS Autodiscovery failure.”
Event ID 32054

The error message pointing in direction of missconfigured autodiscovery or reverse proxy configuration. Since I’m not a big fan of red messages in the event log, I proceeded to check out the possible causes to this error.

Ran a check of the Exchange web services configuration:

EWS_config

Everything seems OK here.
Also checked for autodiscover.domain.com in internal and external DNS. All good there as well. Even had the SRV records for autodiscovery in place both internally and externally.
Ok.
Next step was to check all the Lync features to see if anything was not working as it should. Did a complete check of all features both on my internal Lync PC client and from my mobile iOS client. Everything worked like a charm, while at the same time the events kept popping up in the event log saying “this is not right”.

My conclusion:
The event ID 32054 can safely be discarded as rubbish as long as everything is working fine. I’ve seen multiple posts regarding the same problem all over, and currently there has been no cure.

If anyone by any chance has a working, documented solution to this “problem”(Microsoft???), please feel free to post a comment with links in this post.

Exchange 2013: Inbound mailflow suddenly stops.

I recently came across a problem with Exchange server 2013 which I thought I would like to share with you.

I installed an Exchange 2013 server with CU2 in a migration scenario migrating from Exchange 2007. The servers coexisted for a while when migrating all mailboxes, and I then verified that mailrouting was working as expected with the mailboxes residing on the new Exchange 2013 server. All good so far.

Proceeded with the migration and moved/recreated all connectors on the new server before disabling them on the old one. Everything seemed to be working fine for a while, but then suddenly the server stopped responding for incoming SMTP mail. There was nothing in the logs indicating anything wrong with the server, but every once in a while the server would stop accepting inbound SMTP and a reboot was the only way of getting it back on track(or a restart of the Exchange Transport Service/ Information Store service).

After spending quite some time troubleshooting this issue, a colleague of mine pointed me in the direction of the receive connectors. It turns out I had missed an important thing when I created the SMTP internal receive connector.

Exchange 2013 Receive Connectors

Exchange 2013 Receive Connectors correctly configured

As Paul Cunningham points out in this blog post regarding SMTP relaying, if the server is a multi-role server the connector has to be created using the FrontendTransport role, instead of the HubTransport which I had been using. My mistake… (but it doesn’t point out the fact that failing to create it with the correct properties makes everything else fail as well)

So, with this new info in mind, I proceeded to recreate the Internal SMTP routing connector as a FrontendTransport connector with all the same IP addresses that the old one had. Restarted the Transport service and the information store and watched as e-mail started flowing in.

Turns out that even if the connector in question was just meant for internal mail routing, the fact that it was made as a custom HubTransport caused a total failure for all the default connectors as well.

PS: This “bug” applies only to Exchange Server 2013 CU2. In CU1 this is not a problem as far as I know.

Busy-On-Busy in Lync 2010/2013.

A common challenge when deploying Lync in an enterprise voice environment, is to have the Lync Client behave as close to an “ordinary” phone as possible.

One common “problem” is the busy-on-busy. When an incomming call is routed to a Lync Client already in a call, you would want the caller to get a busy tone. This is, by default, not a function in Lync. To get this behavior, one would have to do it by using MSPL scripting as referred to in this article(not tested, so I don’t know if this actually Works) or use a Third party Application.

I’ve recently deployed this in a small environment using Busy-On-Busy from UnifySquare.

This is a fairly cheap solution, and it’s very easy to set up and configure. The functionality is also delivered in larger call center applications/suites like Competella Unified Communication Suite for Microsoft Lync.

You decide which is the best option in your environment :)