CPU (Socket/No. of Core) Considerations in Lync Server 2013/Skype for Business Server 2015

Update 2017/05/29 – Added Skype for Business Server 2015 and SQL Server 2014 reference.

The hardware requirements in Lync Server 2013/Skype for Business Server 2015 have increased since the previous version, which makes sense since now Audio/Video Conferencing, Monitoring and Archiving roles can be collocated in the Front End. As a result, more CPU and RAM are required to make Lync Server 2013/Skype for Business Server 2015 work properly.

When we deploy a Standard Edition Front End we will have 3 local SQL Server database instances running; on the contrary, the Enterprise Edition Front End will have 2 SQL Server instances. These instances are SQL Express and now it gets tricky, especially if we have a virtual machine host with 4 physical CPUs and we create a new virtual machine with 4 Cores, assigning each Core to a different Socket (physical CPU) available.

Lync/SfB Server services will use all available Cores independently if they are on the same Socket or note, but there is a catch — SQL Express license only allows the instances to use one Socket. Thus, if we have each Core on separated Sockets, all SQL Express instances will only use one Core, and in larger deployments this can cause client disconnect issues, conferences failing and overall user experience degradation.

In Windows Server 2012/2012R2/2016, we can use Task Manager to check how many Sockets and Cores are assigned to the server:


In the previous image we can see that this Virtual Machine is running on one Socket and has two Cores.

On Windows Server 2008 R2 we can use the following PowerShell cmlet:

gwmi Win32_ComputerSystem | select NumberOfProcessors, NumberOfLogicalProcessors | fl


Where NumberOfProcessors corresponds to the number of Sockets (physical CPUs) and NumberOfLogicalProcessors is the number of CPU Cores.


We must carefully prepare/plan a Lync Serve 2013/Skype for Business deployment. If we have a Standard Edition Front End, we need to make sure that it has 4 CPU Cores assigned on the same Socket. On Enterprise Edition Front End the same applies but keep in mind that, if we have 4 Front End‘s, we should not assign the same Socket to all CPU Cores.

The SQL Express limitation is 1 Socket or 4 Cores. For additional details please check:

Features Supported by the Editions of SQL Server 2012

Features Supported by the Editions of SQL Server 2014

New profile and tracing location in Lync 2013

Recently I had to troubleshoot an issue with Address Book on the new Lync Client 2013 and found out that things have changed a little.

Since Lync Client is now part of Office 2013 package, all files related can be found inside the Office 2013 ‘Application Data’ folder.


The Lync profile is stored in a folder with the following format: ‘sip_<username@sip_domain>’. In order to force Address Book to refresh and sometimes solve issues, a good solution is to delete ‘GalContacts.db’ and ‘GalContacts.db.idx’ files from the profile directory (you have to close Lync Client before this action). The profile folder is stored in the following paths:

Lync 2010

%userprofile%\Local Settings\Application Data\Microsoft\Communicator

Lync 2013


Tracing Folder

To enable Tracing you can check my previous post Enabling Trace Log in Office Communicator, Lync 2010 and Lync 2013.

After enabling it,  the log files will be located in the following locations:

Lync 2010



Lync 2013



Address Book Download Delay

Also another feature that helps troubleshooting Address Book issues is to disable Download Delay. By default Lync Client waits between 0 to 60 minutes to download Address Book. To achieve this we must add the following register keys:

Lync 2010

reg add HKLM\Software\Policies\Microsoft\Communicator /v GalDownloadInitialDelay /t REG_DWORD /d 0 /f

Lync 2013

reg add HKLM\Software\Policies\Microsoft\Office\15.0\Lync /v GalDownloadInitialDelay /t REG_DWORD /d 0 /f

As you can see, the location of the registry key has also changed in Lync Client 2013 but the result is the same.