When you try to search for a contact in Lync which is not in your contact list, the client would normally display all matching results from your company’s addressbook. However, sometimes this is not working as expected, and you might be wondering why it suddenly stopped.

The answer to this is a corrupt user profile on your Lync for Mac 2011 client.

To fix this problem, you just have to delete the user profile on your local Mac client. This is how you do it:

  1. Shut down your Lync klient.
  2. Open Finder and press Command-Shift-G. Type in the path to your Documents directory, typically /Users/myname/Documents.
    (Or navigate to the folder in whatever way you may prefer)
  3. Navigate to the folder “Microsoft User Data/Microsoft Lync Data” and delete all content.
    (If you delete the folder “Microsoft Lync History”, you will loose your entire Conversation History in Lync(not necessary))
  4. Log in to the Lync client.

The removed folder content is recreated when logging in to the client with fresh data from the Lync server. Addressbook search is back on track.

Script: Lync Certificates Report

Posted: August 8, 2014 in Lync 2013

Tom Rimala:

A really nice initiative on a matter that’s vital to Lync operations.

Originally posted on Just a Lync Guy:

I’ve been doing some troubleshooting lately for a customer which had some issues with expired certificates on his Lync Environment, and asked me how he can monitor or track existing certificates expiration on his Lync environment.

There are great tools out there which helps tracking and monitoring certificates in any environment (not only for Lync), the ones I had a chance to work with are:

The problem is that the first tool can run against an internal CA only which means it holds a lot of certificates or alternatively it does not include Public certificates.
The Cmdlet is doing an excellent job in providing the information we need, but it can only run against the local server which might be an issue for an environment with multiple Lync servers and pools.
The third option is easy and very detailed but it is running…

View original 192 more words

After spending some time being frustrated over the repeated Event ID 32054 “Storage Service had an EWS Autodiscovery failure.” described in my previous blogpost “lync-server-2013-event-id-32054-ls-storage-service“, I finally came accross the solution for this problem.
Some of you might already know this, but I choose to post this anyway if, for some reason someone don’t.

This article by Dr. Lync describes the solution. I’ve tried this on two different solutions, one where both Lync and Exchange are on 2013 and the other where we have a mixed environment with Lync 2013 and Exchange 2010. On the 2013 environment, I did go through the entire process all the way, including the last part with certificates. In the mixed environment, the part which describes the Configure-EnterprisePartnerApplication from Exchange, is not possible as the script does not exist on Exchange 2010.

One environment is 2013 all the way(this is where both parts where done, maybe it would have been enough with the certificate part) and the other is Lync 2013 Standard Edition and Exchange 2010. On Exchange 2010, the script “Configure-EnterprisePartnerApplication.ps1″ does not exist, so part of the solution in the article is not possible to implement in this scenario. Thats why the event ID won’t go away.

To recapture: The solution described in the blog post by Dr. Lync will work on a clean 2013 solution(Lync and Exchange on 2013), but not in a solution where Lync  2013 and Exchange 2010 are in play. So, upgrade to Exchange 2013 as soon as possible(even though the error is nothing but anoying) to have Lync and Exchange exist in perfect harmony  :)

In a scenario with Lync 2013 Standard Edition and Enterprise voice, I recently experienced problems with voice calls to PSTN users. All calls would connect normally and last for about 5 mins and 20 sec, and then it looked like the Lync client terminated the call normally(at least thats what the Monitoring reports told me).


The PSTN connection is IPT over internet(which is quite new to me), and it looked like everything was working fine both with internal firewalls and outbound to the IPT provider.

I proceeded to check the configuration of the SIP Trunk, and here’s where I came across a parameter that solved my problem. In the Trunk configuration, the “Enable outbound routing failover timer” was Checked out.



I proceeded to turn off “Outbound routing failover timer”, and voila, all calls behave as expected and no calls are disconnected before the user actually hangs upp/terminates the call in the client.

Here is a description of all the parameters involved in the configuration of the SIP Trunk.

The description of the “Enable outbound routing failover timer” is as follows:

“Indicates whether outbound calls that are not answered by the gateway within 10 seconds will be routed to the next available trunk; if there are no additional trunks then the call will automatically be dropped. In an organisation with slow networks and gateway responses, that could potentially result in calls being dropped unnecessarily.”

In my case, the calls are established normally, but terminated prematurely. There are no secondary gateway in the configuration. I’m not able to pinpoint why this parameter also has an influence on established calls, but if anyone who reads this has an input on the matter please feel free to comment on this post.

Recently I came across a small problem when I tried to move Lync users between pools in different sites. The environment is Lync 2013 Enterprise Edition with full HA and HLB(Riverbed Stingray).

The Error was “Unable to connect to some of the servers in pool <name> due to a Distributed Component Object Model (DCOM) error”.


All servers in the solution is Windows Server 2012/R2 running Lync 2013 Enterprise Edition.

Ben Lee posted an article abut the same error message in 2011, and the article is also valid for a Lync2013-only environment. The article can be found here.

PS: Make sure the HLB is configured correctly to handle all Lync traffic.

Great new update for the Lync for Mac client.

Check out this blogpost.

Includes new features for USB camera in Lync for Mac and enhanced 911 functionality.

I recently was made aware of a new “feature” in Lync 2013 which I was not aware of. This is regarding client authentication and remote access users.

There are three authentication methods on the security – registrar tab in Lync Server Control Panel:

The following TechNet article describes each of these  http://technet.microsoft.com/en-us/library/gg182601.aspx

Notice that the checkbox for Enable Integrated Windows Authentication is cleared in my configuration. According to the TechNet article, Microsoft recommends to enable this when serving remote access users, otherwise they won’t be able to authenticate. And here’s where my discovery comes in play.

I discovered that if this setting is enabled, a remote user with a local Lync client can log in to Lync with a username and password(of a Lync enabled user) without having to present a valid root certificate. The local PC does not have to be domain joined either. In my opinion, this is not very secure…The feature has obviously been there for a while, but I’ve never tried logging in to a system before without having the root certificate in place so that’s why I kinda didn’t know this was possible.

I think this setting was default disabled on Lync 2010 and had to be turned on, but I might be wrong on this one. Nevertheless, I would recommend this setting to be turned off in order to have some control of the clients logging in to the Lync environment. When Microsoft states that remote access clients won’t be able to authenticate unless you enable NTLM authentication, that’s not entirely true. They will be able to authenticate if they are provided with the domains root certificate from the internal rootCA. Domain joined clients get this by default, but nondomain clients like Mac’s, Linux and other Windows clients will have to import the certificate to the local trusted root certificate store.

This involves some manual actions to be taken, but in my opinion it’s worth the extra effort in order to have a more secure environment.

Of course, if the Lync environment is a multitenant solution where all users are treated as remote users and not able to acquire the root certificate from the domain in which Lync is installed(without a lot of intervention from the system administrators), NTLM authentication is the only way to allow clients to authenticate.

If anyone has comments regarding this matter or even have some other opinion on why this might be nice or not, please feel free to comment on this post :)