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”. image001

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

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 :)

Ok, I admit it. I’m running Lync on OSx :(

Several of my machines, including my work machine, are apple products. But I still want to run Lync in a local client. Sadly, Microsoft has not come up with a Mac client worthy of comparison with the Lync 2013 client for Windows.

So, I have to stick with the Lync 2011 client for Mac :) This client is very unstable, and does a lot of strange things. I’ve managed to get it fairly stable and working, but not 100%. It keeps crashing when I plug in USB devices etc.

After the last update to version 14.0.8, the client started to sign in and out every few seconds. It seems like the problem arises due to the fact that newer Mac OSx is case sensitive, which is not taken into consideration by Microsoft.In order to fix this, I had to run the following command in Terminal on my Mac:

cd /Applications/Microsoft\ \
    && ln -s USBHIDWrapper.framework USBHidWrapper.framework

Just so you know it in case you are in the same situation as I am :)
PS: VmWare Fusion is a super product for running Windows on a Mac(if you have to) :)

Note: It turns out that the last patch for Lync for Mac 2011(14.0.8) also fixed some other problems I had with the client crashing when removing or inserting USB headsets and web cam’s while the client was running.

Take a look at this post from David Paulino if you ever stumble accross this problem:

“No available Servers to connect to” when trying to view user PIN status..

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 :-)

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”