Lync MX and Skype Crash on Windows 8.1

I got around to upgrading my main laptop to Windows 8.1 this week (finally!) and found I was unable to open the Metro-version apps of both Lync and Skype. They would start to open, show me the splash screen, and then exit. After a bit of digging it appears the crash is caused by the display adapter driver. Seems like Intel still has some issues with their driver for the HD 4000 Graphics on 8.1 and there doesn't seem to a fix.

In case it saves someone else the time, I've already tried all of the following revisions, the latest of which was released less than two weeks ago:

  • 10.18.10.3379
  • 10.18.10.3345
  • 10.18.10.3316
  • 9.18.10.3190 (Windows 8 version)

So you may want to hold off on that upgrade if you have an Intel HD 4000 chip and rely on Lync MX or Skype heavily.

Lync 2013 CU3 and Hosting Providers

One change I've noticed with the Lync 2013 CU3 (October 2013) Edge server update is how it validates trusted FQDNs found in the topology. Specifically, a FQDN can now either be configured a hosting provider or a federated partner's Access Edge address, but not both.

Under normal circumstances this shouldn't pose an issue, but the Lync Control Panel will not prevent an administrator from performing this configuration. And until CU3, the services didn't seem to care either way.

As an example, the proper way to allow Lync Mobile push notifications for Windows Phone clients (and Lync 2010 iOS clients), has always been to define sipfed.online.lync.com as a hosting provider like in this screenshot.

11-6-2013 9-20-09 PM

The partner push.lync.com should then be defined as a SIP Federated Domain with no Access Edge service specified. But, if an administrator did accidentally specify sipfed.online.lync.com as the Access Edge service FQDN, like in the screenshot here, it had no negative impact on the configuration. 11-6-2013 9-30-54 PM

Until CU3 this didn't present a problem. But after applying CU3 on an Edge server you'll find the Access Edge service will no longer start. Event 14517 will be logged after it fails:

The server configuration validation mechanism detected some serious problems.

ERRORS:
The server at FQDN [sipfed.online.lync.com] is configured as both type 'allowed partner server' and type 'IM service provider' .

The solution here is to make sure any hosting providers, such as Lync Online, are not also defined as the Access Edge address for a SIP federated domain. This issue isn't unique to push.lync.com - it applies to any Office 365 tenants specified as a SIP federated domain.

Make sure you validate your hosting provider and federated domain configurations prior to deploying CU3 on an Edge server.

LYSS.exe High CPU Usage

Not sure on the root cause, but I ran in to an instance where the LYSS.exe process was consuming 80-90% CPU on a Lync 2013 Front End server, and consequently causing issues with conference joins and other Lync functions. This process name is new to Lync 2013 and represents the Lync Storage Service. LYSS runs within an additional SQL Express instance on each Front End server, and is responsible for providing the magic pixie dust that allows Lync to now leverage either SQL or Exchange 2013 Web Services for contacts and archiving data. LYSS provides a layer of abstraction for the internal Lync components to deliver content to, and then sorts out how to deliver it to the appropriate end-state data store. It's essentially a glorified queuing service which replaced the need for MSMQ, so it temporarily stores the data, and then delivers to the appropriate destination (either SQL or Exchange.)

Back to the intent of the post, LYSS doesn't run as its own service so you cannot simply restart it via the Services MMC. If you do run in to this problem, you can kill the lyss.exe process. The service will restart itself automatically, and you'll hopefully see the CPU usage drop.