UPDATE 10/10/2014: Microsoft has updated the following KB Article with a supported fix and listed the root cause.

This problem can occur if you install this security update on Lync Server 2013 before you install the August Update of Lync Server 2013. 


So you’ve just upgraded to the August or September 2014 CU for Lync Server 2013 and now the Centralized Logging Agent is not working. A quick check using netstat reveals that the necessary TCP ports (50001 – 50003) are not listening and the following error is logged in the Lync Server event log.

Lync Server Centralized Logging Service Agent Service could not be started.

Source: LS Centralized Logging Agent
Event ID: 33005

Exception: Could not load file or assembly ‘Microsoft.Rtc.ClsAgent.IISLog, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

Exception type: FileNotFoundException
Additional Data:
Source: ClsAgent
Stack Tracer.Trace:
at Microsoft.Rtc.ClsAgent.AgentCore.InitializeAgentCore()
at Microsoft.Rtc.ClsAgent.ClsAgent..ctor(ClsAgentService service)
at Microsoft.Rtc.ClsAgent.ClsAgentService.StartAgent()
at Microsoft.Rtc.ClsAgent.ClsAgentService.OnStart(String[] args)
Data: 0 key/value pairs
Inner Exception:

Cause: Exception during startup
Check the events prior to this to resolve the service startup issue.

[read more…]

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

ShellHangYou have just finished installing Lync Server 2013 onto Windows 2012 R2 and you start the Lync Server Management Shell only to spend the next few minutes (or hours) staring at a little back box. If you are lucky it will finish loading in a few seconds, however for you unlucky few you can end up staring at the black box forever. Now a quick workaround for this is to just use the default PowerShell shortcut as the Lync Server cmdlets are automatically loaded in Windows Server 2012 R2. However, if you are like me you want to know just what is wrong and it’s eating away at you from the inside.

The answer is very simple. There is a problem with the way the Lync Server Management Shell shortcut is generated and all that you will need to do is add the missing double quotes (“) to the end of the Target field in the shortcut.

  1. Click the Start button
  2. Start typing “Lync Shell” to display the Lync Server Management Shell shortcut
  3. Right click the shortcut and select “Open File Location
  4. Right click the Lync Server Management Shell shortcut and select Properties
  5. Edit the Target field and add the missing double quotes (“) to the end of the command
  6. Click OK
  7. Done

Since we are editing the root shortcut the change will affect all administrators that login to the system. Translation, you will only have to make the change one time.

Special thanks to Korneel Bullens for pointing out this fix to me.

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)

It is becoming more common place to see requests from customers who need to place a firewall between Lync Pools.  Maybe the servers are separated by large geography or in different datacenters or the InfoSec team requires firewalls between applications (zoning).  Now Microsoft has published very good information on what ports are needed for the different roles and services in Lync Server and Client.  However, what about other Windows services that Lync uses?  Troubleshooting firewalls and ports is a pain and can lead to extra work when something doesn’t work as expected.  One of those key services in particular is DCOM.

The DCOM ports are used in conjunction with RPC (135) for moving users, user replication synchronization and address book synchronization.  Now Microsoft does states that you need port 135 in their TechNet article and the protocol does say DCOM and RPC.  However, most people will assume that 135 is all you need.  That’s where the mistake happens.  Now most Network and InfoSec teams are not going to be too happy when you call them up and say that you need port 1024-65535 opened up between your two pools.  In fact, we know what they will say. 

Let’s take a typical move-csuser request.  A NetMon trace will show that their is an initial RPC request occurs on behalf of the svchost.exe process over port 135 however the actual “work” will occur over DCOM and utilize the high port range.  If this port range is blocked due to a firewall you’ll get an error from the PowerShell command saying that DCOM isn’t available.

To address the large number of ports DCOM uses by default, Microsoft has published a procedure to configure DCOM to work with firewalls.  Leveraging the procedure found here one can modify the registry and restrict DCOM to use a specific port range.  Microsoft recommends a minimum of 100 ports for this protocol.  That’s much less than what we started out with.  You can get the articles below along with some of my favorite tools for network troubleshooting.


In this example ports 5000 through 5100 inclusive have been arbitrarily selected to help illustrate how the new registry key can be configured. This is not a recommendation of a minimum number of ports needed for any particular system.

  1. Add the Internet key under:
  2. Under the Internet key, add the values “Ports” (MULTI_SZ), “PortsInternetAvailable” (REG_SZ), and “UseInternetPorts” (REG_SZ).
    For example, the new registry key appears as follows:
    Ports: REG_MULTI_SZ: 5000-5100
    PortsInternetAvailable: REG_SZ: Y
    UseInternetPorts: REG_SZ:
  3. Restart the server. All applications that use RPC dynamic port allocation use ports 5000 through 5100, inclusive. In most environments, a minimum of 100 ports should be opened, because several system services rely on these RPC ports to communicate with each other.

Articles & Tools

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

If you are having problems with certain features on the Lync Web App and need to enable logging you can use the following simple procedure to enable verbose logging in the Lync Web App.  To enable logging you can follow this simple procedure as outlined here.  But if you are really having a problem, the default logging level may not be enough.  So how to we enable verbose logging in the Lync Web App?

Force the Lync Web App client

Append ?sl=1 to the end of the meeting invite to join any meeting using the LWA instead of the Lync client.

  • https://join.aspoc.net/meet/matt/[id]?sl=1

Enable verbose logging

Append ?log=full to the end of the meeting invite.

  • https://join.aspoc.net/meet/matt/[id]?log=full

Force the LWA client and verbose logging

That’s easy, just use the & to join the two strings together.

  • https://join.aspoc.net/meet/matt/[id]?sl=1&log=full

Where are the logs?

The logs that LWA creates are stored here:

  • C:\Users\\AppData\Local\Microsoft\LWAPlugin\Tracing

The file you are looking for is:

  • LWAJSPersistentx.log

Where x is a number, usually 0 or 1.  Opening up the file, you will see a whole bunch of information including information about WebTicket, MRAS, and ICE candidates among other information.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Page 1 of 8112345678910...203040...Last »