Summit 7 Team Blogs

More O365/Lync Troubleshooting: The Endpoint Cache

Recently we experienced a bit of an issue with Lync Online (Office 365). Some of the users could not log in to the service while others appeared to be fine. This seemed to be occurring on a per-user basis. The users affected would be impacted on Mac or Windows, no matter which of the clients they were using.

Okie, that was primarily me, since I'm the founder of the Mac Rebel Unit at Summit 7, but there were other Windows-only users impacted as well.

The Mac and Windows clients would show some different information, of course. But the end result was the same. On the Mac, you can enable Lync logging by going to "Preferences" in the application and selecting "Turn on logging for troubleshooting."

Mac Lync Preferences General

This will create a log called "Microsoft-Lync.log" and update it in real time, which you can tail in the shell with "tail -f" or watch it roll in the Mac Console application.

You may see something akin to this:

2012/05/18 08:32:28.602 Office Communications Server LOGON STARTED: USER = {<your user id>}
2012/05/18 08:32:28.604 SIPService::Logon
2012/05/18 08:32:28.653 SIPService::OnEvent(IApplicationLayerEvent &), type: 1, HasSignedIn(): 0, HasSignedOut: 0
2012/05/18 08:32:28.819 SIPService::OnEvent(IApplicationLayerEvent &), type: 3, HasSignedIn(): 0, HasSignedOut: 0
2012/05/18 08:32:28.819 SIPService::OnEvent(IApplicationLayerEvent &), type: 1, HasSignedIn(): 0, HasSignedOut: 0
2012/05/18 08:32:28.833 SIPService::OnEvent(IApplicationLayerEvent &), type: 3, HasSignedIn(): 0, HasSignedOut: 0
2012/05/18 08:32:28.833 SIPService::OnEvent(IApplicationLayerEvent &), type: 1, HasSignedIn(): 0, HasSignedOut: 0
2012/05/18 08:32:28.833 SIPService::OnEvent(IApplicationLayerEvent &), type: 3, HasSignedIn(): 0, HasSignedOut: 0
2012/05/18 08:32:28.833 SIPService::OnEvent(IApplicationLayerEvent &), type: 1, HasSignedIn(): 0, HasSignedOut: 0
2012/05/18 08:32:28.861 SIPService::OnEvent(NModel::ILogonSessionEvent), hr: 0x0, oldState: 10, newState: 20, direction: 0
2012/05/18 08:32:28.866 InternalConnect, NLResolveAddress returned: 0
2012/05/18 08:32:28.867 IsLocalAddress, '' is not a local address
2012/05/18 08:32:28.867 FShouldUseProxy, is returning 1
2012/05/18 08:32:28.867 Connecting to (port 443)
2012/05/18 08:32:29.277 InternalConnect, NLCreateConnection returned: 0,
2012/05/18 08:32:29.277 InternalConnect, NLCopyConnectionBinding returned: 0,
2012/05/18 08:32:37.187 FShouldUseProxy, is returning 1
2012/05/18 08:32:37.545 FShouldUseProxy, is returning 1
2012/05/18 08:32:37.730 SIPService::OnEvent(ILogonCredentialManagerEvent), type: 0
2012/05/18 08:32:37.730 Login (1) failed with error: (0.0)
2012/05/18 08:32:37.814 SIPService::OnEvent(ILogonCredentialManagerEvent), type: 6
2012/05/18 08:32:37.815 SIPService::OnEvent(NModel::ILogonSessionEvent), hr: 0x80c80009, oldState: 20, newState: 10, direction: 1
2012/05/18 08:32:37.815 void SIPService::OnLogoffResult(HRESULT), hr: 0x80c80009
2012/05/18 08:32:37.818 void SIPService::LogoffEx()

No matter what you do, you'll see the same information roll through the log. It gets a little old. Now let's look at the Windows client. The error message is different, but the same basic symptoms exist. The client spins for a few seconds, then it dies with an error saying it cannot connect. In my case, the Windows client claimed that it was unable to acquire a personal certificate to log in.

Win Lync Certificate Error

You can enable Windows troubleshooting by going to options in Lync and turning on the logging option. That's very similar to Mac. However, you may not see much in the way of what's truly going on.

So what's going on here? Well, if you start looking through the Microsoft Knowledge Base you'll discover that the Windows client error message offers the best clue. You may even stumble across this article that offers a fix for the certificate issue. The fixes for consideration are fairly generic. I'll spare you the trouble. The article says you didn't run O365 setup, you're using the wrong version of Lync, or some other completely incorrect solution. Don't bother.

Instead, head over to this other article where they list different symptoms but provide the correct fix. What's happened is that Lync has cached the endpoints to connect to the Office 365 service. At some point, O365 or your provider had an issue with the endpoint and removed it from the pool or something like that. Instead of asking for a new endpoint, Lync for Mac and Lync for Windows both continue to connect to the endpoint that no longer works.

There's an easy solution, but if you're managing a lot of desktops this is likely to be a pain.

On Windows Vista and 7, make sure Lync is completely exited and no longer running. Launch Windows Explorer and navigate to:


Inside that directory you will find a file named "EndpointConfiguration.CACHE." Delete it. Restart Lync. It should now successfully sign in and create a new EndpointConfiguration.CACHE file.

On Windows XP, the path is a little different. You'll find it in:

%UserProfile%Local SettingsApplication DataMicrosoftCommunicator<>

Believe it or not, the same exact problem exists on the Mac client. You'll find the endpoint cache file in a different location, however. To resolve it on the Mac, do a CMD-Q on Lync to make sure it's completely exited. Using Finder, visit:

~/Documents/Microsoft User Data/Microsoft Lync Data/<>

You'll find the file "EndpointConfiguration.cache" in there. Delete it and restart Lync. It should now connect.

Now that you've resolved the problem, how do you deal with this on a lot of desktops? It really depends on your environment, but here's a few ideas for consideration:

  • Engage the help desk with the solution and make sure they understand the process if a user calls in with the issue
  • Delete the endpoint configuration cache in a login script (hacky)
  • Use SCCM or some other system management tool to quit Lync and delete the file overnight (not great)
  • Deal with it on a case by case basis for those who have a problem (not the best solution)

The real challenge with this issue is figuring out who has this exact problem and whether or not this fix will resolve the issue. In our environment, about 30% of our employees were experiencing the issue. It was confusing, misleading (thanks to the Microsoft KB) and tough to chase down… so yay, it's a blog article now!

Hope this helps. 再見!


The sample scripts are not supported under any Summit 7 Systems standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Summit 7 Systems further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Summit 7 Systems, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Summit 7 Systems has been advised of the possibility of such damages.

About Jason Miller