Category Archives: Lync

#Skype4b: Error while requesting certificate

Requesting and assigning a certificate to Lync/Skype for Business server is a crucial process. Any kind of ignorance while requesting the certificate can trouble end-user services. If you are requesting the certificate for Lync/Skype for Business server, you may notice “WARNING: The chain of the certificate “xxxxxxxxxxxxxxxxxxxx” is invalid”.

If you will look into the logs then you can easily find it out that the process couldn’t find certificate chain and it happens because of root certificate. It simply means that the root certificate of certification authority does not exist on the local server from where the request is being generated.

Note: To reproduce this problem you should not install and configure local AD CS before Lync/Skype for Business Server installation. Install and configure AD CS after Lync/Skype for Business installation and try to request certificate without restarting the Lync/Skype for Business server. Most probably you will see the same error.

Now, let me use step by step process to identify and resolve this problem.

Below snapshot shows warning message while requesting certificate.

Open certificate snap-in through MMC and look for the root certificate of certification authority by which you are trying to request certificate.

You will not find the root CA in both “Current User” and “Local Computer”.

Now, Reboot the Lync/Skype for Business server and check again, now you may find the root certificate. In my case, certification authority name is “dcloud-AD-CA”. If you could not find the root certificate or not using AD CS then install the root certificate chain manually.

You can check this root certificate chain in both the locations “Local Computer” and “Current User”.

Now, you should try to request and assign the certificate.

Hope, it helps you.


How does Office Web Apps / Office Online server integration work with Lync/SfB Server?

Office Online Server (OOS) is a latest version or new release of Office Web Apps Server. It plays an inimitable role for Microsoft UCC (Exchange, Lync/SfB, SharePoint) applications. In this blogpost, I’ll cover the integration workflow between Lync/SfB and OOS.

OOS provides enriched PowerPoint presentation view to Lync/SfB end-users.

When a user uploads PowerPoint file into the meeting, the file is sent to the OOS server without any conversion.

OOS performs encryption and saves the file to Lync/SfB content file share.

When you configure OOS in Lync/SfB at the time of topology configuration, you define base URL. When a user presents a file, the url is taken for customization with unique identifier, file ID and meeting ID etc as well as with additional security using session lifetime token and send it to all the clients.

Whenever an end user connects to this meeting and try to access broadcast URL, OOS send the instruction to the Lync/SfB FE server to get the file details.

FE server fetch the file details based on the file ID from Lync/SfB share folder and uploads to the OOS.

Finally, OOS sends the http response with current page to the participants.

Totally confuse L

Let’s try to understand this process through illustration:

Courtesy: MVA

When a user setups a conference and upload the presentation file, it first connects to the conference server and then share the file. As shown above in the image it works as follows:

  1. The Presenter/Sharer uploads the file to the Front End.
  2. The Front End save the shared file to the Skype for Business file share folder.
  3. The sharer user starts the file presentation though the Front End server.
  4. The Front End user send the broadcasting URL with a defined file ID and authentication token to all the participants.
  5. Participants send the HTTP instruction to get the broadcast URL though the Office Online server / Office Web Apps server.
  6. The Office Online server / Office Web Apps server send the instruction to the Front End server to get the file with the defined file ID.
  7. Front End server takes the file of that file ID from the Skype for Business file share folder.
  8. Front End server uploads the file to the Office Online server / Office Web Apps server.
  9. Office Online server / Office Web Apps server sends the
    HTTP response with current page to the participants.

Windows Fabric and Server Placement – Part II

Part I of this article talks about Windows Fabric basics. In part II, will describe how Lync Server 2013 and Skype for Business is tied together with Windows Fabric. Will call out few best practices which should be taken care while placing Front End Servers in virtualized environment.

In Lync Server 2013 & Skype for Business Server 2015, a pool can have maximum 12 Front End Servers. Lync Server 2013 works with Windows Fabric V1 while Skype for Business works with Windows Fabric V2/V3. As Lync Server 2013 and Skype for Business Server Front End pools uses a distributed systems model which is based on Windows Fabric. In this model, it keeps important users and conference data of each user on as many as three Front End Servers in a FE Pool. With this model a least number of FE servers must be running for the pool to function. There are two loss modes where quorum loss comes in picture for a FE Pool.

Routing group level quorum loss: Every user is assigned to a particular routing group with in a FE Pool and there are three servers in one Routing group where one is a primary replica and another two are secondary replicas. When enough replica servers of a particular routing group become unavailable then it results in routing group level quorum loss.

Total number of servers in the pool Number of servers that must be running for the pool to be started the first time
2 1
3 3
4 3
5 4
6 5
7 5
8 6
9 7
10 8
11 9
12 10


Pool level quorum loss: Same as Windows Server Cluster, FE pool needs minimum N/2+1 to make the pool state up and running. In the odd numbers it is automatically taken care while in the even numbers Primary SQL database plays a role of witness. When minimum numbers of server in a FE Pool becomes unavailable, it results in Pool level quorum loss.

Total number of Front End Servers in the pool Number of servers that must be running for pool to be functional
2 1
3-4 Any 2
5-6 Any 3
7 Any 4
8-9 Any 4 of the first 7 servers
10-12 Any 5 of the first 9 servers


If organization has plan to deploy Skype for Business Server in virtualized environment, FE Servers placement is a key to make sure minimum impact on FE services in case one host goes down. If you place more than one FE Server on any particular host in virtualized environment that can surely result in routing group level quorum loss or might be result in Pool level quorum loss as well if pool has only four FE Servers and SQL primary database is part of the host which is down.

The above example consider SfB deployment with two physical hosts where each host caters two FE Server and one SQL Back End Server. If only routing group goes down then it can be recovered via Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery cmdlet. Please make sure if two FE Servers in a particular routing group go down, the users belongs to that routing group will be downgraded in limited functionality until FE Servers come back or pool registrar state has been reset.

Windows Fabric and Server Placement – Part I

Windows Fabric plays a key role for Front End pool services availability in Lync Server 2013 and Skype for Business Server 2015. In Lync Server 2010 this responsibility was managed by Cluster Manager. Lync Server 2013 / Skype for Business 2015 Front End Pool services availability totally depend on windows Fabric and Fault & Upgrade domains provisioned by the Topology Builder.

Lync Server 2013 and Skype for Business Server 2015 use brick model which is based on Windows Fabric and use lazy writes to update Back End Server databases. Windows Fabric is a distributed system platform for building scalable applications. It is used for both on premise and cloud scenarios. Windows fabric starts independently without any specific external configuration store. It has self-healing and decentralized features which provides self-monitoring and automatically adjustment (load balancing) without any single point of failure. Windows Fabric Hosts service (FabricHostSvc) is installed as part of “Setup and Remove Lync Server components. Windows fabric also elect primary, secondary and backup secondary (tertiary) replica, maintain replication between primary and secondary replicas. You can find config file on each server located at “C:\ProgramData\Windows fabric\<ServerFQDN>\Fabric\ClusterMainfest.current.xml”.

Below are the core services which use Windows Fabric:

  • Routing Services
  • Lync Storage Services
  • MCU Factory Services
  • Conferencing Data Services

Windows Fabric is nothing but works like Windows Server Cluster. Similar to Cluster, Windows Server works on Majority where every Front End Server serves as voters. To get the majority for Front End pool, it always calculate N/2 + 1 for even FE nodes & N+1/2 for Odd FE nodes.

There are two major concepts which rely on fault and upgrade domain. Fault domain basically correlates underlying hardware and widely considered at the time of virtualization where organizations or administrators place more than one similar server role on same host. While Upgrade domains correlates logical set of nodes for planning upgrades.

Part II covers quorum loss modes, server placement, SQL server requirement for majority and best practices.

Lync Server 2013 – Location Based Routing: Part II

In part I Lync Server 2013 – Location Based Routing aka LBR, I discussed about the basic fundamentals, benefits, capabilities and routing methodologies. To extend the same, part II will cover implementation steps and test cases. As discussed in part I, LBR is a set of rules which handle your PSTN calls to comply with regulations of specific countries such as India. In telephony terms, it prevents toll bypass by blocking or modifying the routes of PSTN calls. Organizations can define the scope for LBR such as specific region, International calls, specific gateways or PBX and set of users. LBR policies can be based on user’s location or PSTN gateways location. LBR applies rules on different scenarios.

To test the LBR scenario, Single Site is deployed with asterisk PBX to generate voice calls. Test scenario will consider enterprise voice calls which are generated by Lync user located @ office and located @ home

Let’s start with deployment process:

1. Process start with Enterprise Voice deployment

Create dial plans and configure Normalization rules

Create and configure trunks, voice policies and define voice routes

2. Test Enterprise Voice setup

3. Create Network Region and Sites, define subnets based on your Lync infra.

4. Create Voice Routing Policy.

New-CsVoiceRoutingPolicy –Identity “Site1VoiceRoutingpolicy” –Name “Site1 Voice Routing Policy”

5. Set Voice Routing Policy and assign PSTN Usage (In lab scenario PSTN usage is created with name “Asterisk”)

Set-CsVoiceRoutingPolicy –Identity “Site1VoiceRoutingpolicy” –PSTNusages @{add=”Asterisk”}

6. Enable and configure location based routing and voice routing policy for Network Site

Set-CsNetworkSite –Identity Site1 –EnableLocationBasedRouting $true –VoiceRoutingPolicy “Site1 Voice Routing Policy”

7. Trunk configuration

Set-CsTrunkConfiguration –Identity Site1Trunk –EnableLocationRestrictions $true –NetworkSiteID “Site1”

8. Change Voice & Routing Configuration

Set-CsVoicePolicy “Site1VoicePolicy” –PreventPSTNTollBypass $true

Set-CsRoutingConfiguration –Enable locationbasedrouting $true

Follow the same steps for multiple sites carefully.

Test multiple calls scenario such as:

Incoming PSTN call while user @ his home location (Site1)

Outgoing PSTN call while user @ his home location (Site1)

Transfer and Forward while both the users @ their home location (Site1)

Simultaneous ring while both the users/endpoint @ their home location (Site1)

Lync users @ their home location are doing conference

Lync users @ their home location are doing Lync conference and PSTN user is joining conference using “Dial-in Conferencing”

Incoming PSTN call while user is logged in from outside

Outgoing PSTN call while user is logged in from outside

Transfer and Forward while both the users or one of them are not @ their home location (Site1)

Simultaneous ring while both the users/endpoint or one of them are not @ their home location (Site1)

Lync users @ their home location are doing conference and one of the conferencing user is trying to conference any PSTN user

These are few examples related to my Lab design, if you have more than one site then you need to test many other scenarios as well which certify that you are compliant with regulation.

Lync Server reporting url error

Lync monitoring reports deployment is a key part of the management & administration of Lync server. Sometimes, it is simple to configure and use but some time you can face some problems. You can get this common error “An error occurred during report processing.” While accessing report url.

Sometimes this error can occur because of database stored procedure. If reporting url was working fine earlier you can follow below steps only for LcSCDR & QoEMetrics databases.

  • Open SQL Server studio manager.
  • Go to the LcSCDR / QoEMetrics
  • Go to the Programmability

  • Go to the Stored Procedures under Programmability
  • Select and right click on dbo.RtcGenerateSummaryTables
  • Click on New Stored Procedure

  • You will see the result with return value 0.


Now, another case comes in picture while you are deploying new reporting servers. This issue can be faced in both the cases while monitoring services are deployed on SQL Mirror or SQL Cluster. To resolve this issue, open reporting services url and go the CDRDB & QMSDB under report content and modify the connections string.

  • You can find “data source=(local)\instancename;intial catalog=QoEMetrics
  • Change (local) with real sql server name and apply the changes.

Follow the same steps for LcSCDR also via updating CDRDB and enjoy J


Remove Lync Server Standard Edition from existing Lync infrastructure

Business critical applications such as Exchange and Lync are very tightly integrated with Active Directory. Many preparation steps are required to introduce these application or even when you’re migrating to the newer version. Most of the times professionals see, few changes like installation or removal are required frequently for small branch site deployments. Let’s start with removal process of Lync server Standard Edition deployment from existing Lync infrastructure. There are few pre-requisites for uninstallation of Lync server required which should be performed before uninstallation process.

Below is the step by step process for Lync Standard Edition Server uninstallation:

1. Move/Disable/Remove all Lync users from existing Lync Standard Edition Server.

2. Delete/Move Conference directories.

Open Lync Management Shell

Run Get-CsConferenceDirectory and note down the Identity which are associated with Lync SE pool.

To remove run Remove-CsConferenceDirectory –Identity <Identity Number>

3. Remove other components which are associated

  • Delete all Contact objects enabled for Lync Server Enterprise Voice features by using Lync Server Management Shell.
    • If the Lync Server 2010 response groups have been migrated to a Lync Server 2013 deployment, do not remove the contact objects of the migrated response groups. If response groups have been migrated, skip the document “Remove Response Group Service Workflow Contact Objects” that is listed in the “Documentation” column. For more information, see
  • Remove Enterprise Voice routes by using Lync Server Control Panel.
  • Remove all Call Park orbits by using Lync Server Control Panel.
  • Remove all tables for Enterprise Voice unassigned phone numbers.
  • Back up the Location Information service database.
  • Back up the custom music on hold file.
  • Delete Enterprise Voice routes.
  • Reassign the public switched telephone network (PSTN) gateway.


4. Cross verify, Lync Standard Edition server which you are going to uninstall is empty.

5. Open Lync Topology builder and delete the server from topology.

6. Delete the Lync site if there is no Lync server or other components are not associated with existing deployment.

7. Publish the topology.

8. Open Lync server 2013 deployment wizard and run “Install or Update Lync Server System”

9. Run “Setup or Remove Lync Server Components”.

10. Once components are uninstalled successfully then remove associated certificates.

11. Cross verify the uninstallation.

12. Open SQL server studio manager and remove all the databases from all three instances RTC, RTCLOCAL & LYNCLOCAL.

13. Uninstall SQL Server Express Edition from control panel.

14. Uninstall Lync Server components and other pre-requisites.


I hope you have enjoyed the uninstallation process. Please feel free to write you views or any observation which you find at the time of uninstallation process.


Lync Server 2013 – Location Based Routing

Location Based Routing is an impressive feature of Lync Server 2013 which distinct Lync Server 2013 from other UC solutions. LBR allows full fledge Lync 2013 Enterprise Voice deployment for those enterprises who are doing business in regulated countries such as India, UAE, Egypt etc. Lync enterprise voice deployment with LBR requires well-versed planning and designing as your one wrong step can disturb entire voice setup. Now, questions come to every Lync professional if LBR requires planning & designing; it means LBR is not enabled by default or in other ways, LBR configuration part comes later.

Question: If LBR is not enable by default and needs additional configuration, which methodology Lync Server uses by default?

Answer: LCR

Many Exchange professional who are reading this blog, can assume LCR means Local Continuous Replication which was introduced in Exchange Server 2007.

By default Lync server uses Least Cost Routing methodology. Least cost routing can reduce the call rates by minimizing toll charges and maximizing WAN uses, which can benefit to the enterprises but in another ways it is a revenue loss for PSTN service providers.

LBR Benefits:

  • Comply with regulations that restricts IP-to-PSTN routing in pre-defined cases.
  • Routes PSTN calls based on caller’s location to prevent toll bypass.
  • Scoped to specific locations, gateways, and users based on Network configuration.
  • Route call to the gateway closest to the calling party which increase QoS & QoE.
  • Minimize use of WAN which result in better QoS & QoE.

LBR Capabilities:

  • Route outgoing calls to a PSTN gateway local to the caller’s location.
  • Prevent incoming calls if the Lync client is not in the PSTN gateway’s location.
  • Route outgoing calls through international PSTN gateways when there is no local gateway.
  • Ensures that conferences do not have a mix of users from different locations and PSTN dial-out.

Outbound routing:

Trunk-to-trunk routing:

Inbound routing:

There are many test cases involve in LBR implementation which need to be tested. Implementation steps and test cases is explained in the next part of this article.

Courtesy: Lync Conference 2014.

A trusted server….. error while publishing Lync Server 2013 topology

You may see “A trusted server….” error while publishing Lync Server 2013 topology.

In my case, I was adding Archiving and Monitoring role in existing Lync environment and had never faced this issue before.

After searching and looking into the error, I observed this error is occurring because of some existing entries in Active Directory.

To resolve this issue, I followed the below steps.

Note: Please take your AD backup before playing with ADSI Edit or ask your AD expert to perform the same activity.

  1. Open ADSI Edit (adsiedit.msc)
  2. Open Configuration partition and navigate to CN=Services>CN=RTC Service>CN=Trusted Services.

  1. Go to the properties of each entry under “CN=Trusted Services”.
  2. Type “msrtc” to search the Lync attributes in the property.

  1. Cross verify “TrustedServiceType” and “TrustedServerFQDN” with the error.
  2. Close the property and delete the entry.
  3. Publish the topology.
  4. If you get the same error again with different TrustedServiceType, follow the same procedure one more time.

Finally, publish the topology 🙂

Lync Server 2013 Brick Model

Messaging is a business critical application for any enterprise. To increase the productivity, instant or real-time communication is very much required. Lync has become a more suitable option for business productivity which serves all real-time workloads such as IM/Presence, Audio/Video & Web conferencing, Group/Persistent Chat, Application & Desktop sharing and Enterprise Voice.

While enterprises are moving towards an application for real-time communication, services availability is concern for IT decision makers. To avoid complexities and provide more availability Microsoft came up with brick model architecture for Lync 2013. It allows scaling out your Lync FE servers from 1 to 12 and each server can support up to maximum 6666 concurrent users. Lync Server 2013 is loosely coupled with Lync Back End SQL server and use lazy writes feature to write data in SQL Back End server.

Lync Server 2013 divides users in a group and each group is dynamically assigned to three Front End Server, primary secondary and tertiary. Once user logs in, primary server serves the services and replicate the data across secondary and tertiary using synchronous replication as well as update the SQL backend server using asynchronous replication known as lazy writes. In case of primary server failure secondary server serves the services.

In Lync server 2013, Front End server keeps rtc, rtcdyn and xds database in local sql express store. To know more about Lync 2013 databases please go through Lync Server 2013 databases.

Now, we should talk about how brick model works. Basically, brick model is based on windows fabric and it consider nodes majority for availability. That’s why you need minimum three Front End servers to achieve high availability. The majority is considered when n/2 or n+1/2 Front End servers are alive.

For maintenance, you should restart/down one server at a time. If all Front End servers go down due to the power outage or any other reasons, please make sure you are starting all Front End servers at the same time.