Category Archives: Skype for Business

Skype for Business Cloud Connector Edition Releases/Versions


Skype for Business Cloud Connector Edition is a revolutionary offering from Microsoft to connect on-premises voice infrastructure with Skype for Business online. I wrote a series of articles about Skype for Business Cloud PBX and Cloud Connector Edition and this post will give you a holistic view of all the Cloud Connector Edition current and upcoming releases (versions).

Below are the series of blogposts related to Skype for Business Cloud PBX and Cloud Connector Edition:

Skype for Business Cloud PBX

Skype for Business Cloud Connector

Skype for Business Cloud Connector Components

Skype for Business Cloud Connector Supported Topology

Skype for Business Cloud Connector Infrastructure Requirements Part I

Skype for Business Cloud Connector Infrastructure Requirements Part II

Skype for Business Cloud Connector Edition Public DNS, IP and Certificates requirements

Call flow with Cloud Connector Edition

Now, I am going to cover the different releases of Skype for Business Cloud Connector Edition in the following table.

Product Release Remarks
Skype for Business Cloud Connector Edition 1.3.4 Initial release
1.3.8  Read more
1.4.1  Read more

For the initial release, please read the series of blogposts and for specific release updates read the respective blogposts which covers the changes and enhancement.

Exchange 2013/2016 EAC(ECP) and OWA blank page after login


This is a very common and known issue which may occur in Exchange Server 2013 and Exchange Server 2016. This issue occurs mostly in new deployments. When this issue occurs, you see blank web page after login into https://<exchangewebservicesurl>/owa or https://<exchangewebservicesurl>/ecp.

This issue occurs because of SSL certificate binding and can be resolved by changing the binding settings in IIS.

Once you open the Exchange Admin Center or Outlook Web App and enter your user name and password, the blank page comes.

To resolve this issue, Please login to CAS server in Exchange Server 2013 or Mailbox server(because Exchange 2016 has one role) in Exchange 2016 and follow the given below steps.

  1. Open IIS manager.

2. Go to the sites under Exchange Server and Select “Exchange Back End”.

3. Open Bindings from right side “Actions” panel.

4. Select https under binding settings and click on Edit.

5. Select “MS Exchange” under SSL certificate and click on OK to apply settings.

Now, you should try to open Exchange EAC or OWA.

Hope, it worked for you. J

Please share your feedback.

#skype4b: Director Server role


There are myths around the director server role in Lync Server 2013 and Skype for Business Server 2015. Let me give you the facts:

What, When, Why, Where and How?

Many IT professionals, even consultants and architects who work on Microsoft Unified Communication area may have all these questions in their mind.

What: Director is an optional server role in Lync Server 2013 and Skype for Business Server 2015. Director authenticates user requests, but doesn’t home any user accounts.

When: Director may require in following conditions:

  • If you deploy, multiple Front End pools at a central site.
  • If you want to increase security against denial of service attacks.

Why: Director protects Front End pools from denial of service attacks, avoid unnecessary traffic by pre-authenticating inbound requests, and redirecting users to their home pool.

Where: Director can be deployed in corporate network where you deploy Front End servers and can never be collocated with any other role.

How: You need to use the same process which you use to add mediation server or any other additional server role in Lync/Skype for Business site.

As I mentioned in the beginning, director is an optional server role and deployment of director totally depends on the business need and discretion.

Definitely, it increases the level of security and simplify the authentication process for external users who comes through Edge server, Director does the pre-authentication for them and passes these request to internal servers. By doing this, it saves Front End pool server from the authentication overhead and also help isolate internal Front End pools from malicious traffic such as denial-of-service attacks.

It serves as an internal next hop server to which an Edge Server routes inbound SIP traffic intended for internal servers. If the network is flooded with invalid external traffic in such an attack, this traffic ends at the Director.

If you deploy multiple Front End pools at a central site, by adding a Director to that site you can streamline authentication requests and improve performance. In this scenario, all requests go first to the Director, which then routes them to the correct Front End pool.

Now, I think you can pick the best option and design your Skype for Business solution based on the specific requirements.

#skype4b: Skype for Business Licensing User vs Device CAL


Microsoft licensing is not easy and sometimes create lots of confusion. My previous blogpost “Skype for Business Licensing” talks about different types of Skype for Business licenses including server and client. In this blogpost, I am going to cover different type of access patterns.

In most of the companies, you will find three types of users.

Internal: Users who come to office and access services. Help Desk employees are good example of these kind of users.

Remote: Most of the time these types of user access services from outside and use multiple devices. Sales and marketing folks are good example of remote users.

External: Partners, vendors and customers can come in external users group. These types of unauthenticated users use services based on the need. But these users doesn’t belongs to your corporate infrastructure. External users cover different types of users in Skype for Business scenario.

Federated users
Anonymous users
Public IM Connectivity users

 

Therefore, it is very important to choose between user and device CAL that suits your requirements most. Most of the organization choose User CAL instead of Device CAL.

User CAL: If each user has his/her own device then you must choose User CAL. One user CAL can be used on multiple devices by an unique user.

Device CAL: Device CAL is a good option in those scenarios where multiple users use same device. For example: In BPO/KPO multiple users uses same system in different shifts.

External Connectors: Very few IT professionals know about external connectors. External connector is a very common scenario which applies to windows server services where anonymous people access services from outside. Skype for Business cover this EC under Skype for Business server license.

I hope this blogpost helped you 🙂

#Skype4B: Call via work (Part IV)


This post is the IVth part of the Call via Work series and continuation of part III. In this blogpost, I am going to cover the limitations of Call via Work. However, CvW is a great feature of Skype for Business Server 2015 which can be implemented easily with a limited hardware configuration but it comes with its own limitations.

There are following limitation which comes with CvW:

  • CvW call back number doesn’t work directly. If a user has setup a call forwarding on CvW call back number and someone invites him through that number, in that situation call will fail because the invitation will not reach to the user. To avoid this situation, you should invite the user for meeting by clicking on his name, not by the number.
  • Following things cannot be used by CvW enabled user
    • Team Call
    • Response Group
    • Delegation
  • Following actions can’t be performed by CvW user through SfB:
    • Record a meeting
    • Mute or Unmute the call
    • Hold or Transfer the call
    • Call Parking
  • CvW can’t be used by user to access their PBX voicemail messages.
  • User of CvW can’t perform following things:
    • Add more users to a 2-person call.
    • Can’t escalate voice call to a collaborative meeting which includes other modalities such as video, PowerPoint etc.
  • No support for deskphone pairing or VDI plugin pairing.
  • Enhanced 911 capability and malicious call tracing are not available during Call Via Work calls.
  • If your PBX system does not support REFER with Replaces, the following behavior will happen. While on a Call Via Work call, if the user transfers the ongoing call from the PBX Phone, the call window will not disappear from their Skype for Business window. If the user then closes the call window, the call between the transfer target and the transferee will end.

Courtesry: Microsoft Technet

I hope you enjoyed the entire series of Call via Work. Please write your queries and feedback in the comment section.

Call via Work Part I

Call via Work Part II

Call via Work Part III

#Skype4B: Call via work (Part III)


Part I and Part II of this blog post cover CvW fundamentals and how does it work. Now this part of the blogpost will cover CvW prerequisites and deployment process.

CvW is a cool feature of Skype for Business but it can only be configured in few scenarios. Below are the prerequisites and infrastructure should meet these requirements.

  • Unified Communication Web API (UCWA): Comes default with Skype for Business Server and installed automatically on all Skype for Business Front End Servers.
  • Mediations Server: Should be deployed standalone or part of the Front End server.
  • Direct Inward Dialing (DID): Each user should have DID on the PBX phone system for users who will be enabled for CvW and enabled for enterprise voice in SfB with the corresponding DID.
  • Automatic Configuration: CvW users must have Automatic configuration selected in their Advanced connections settings. The enables the client to discover the UCWA URLs.


  • Call forwarding and Simultaneous ring: CvW users must enable for call forwarding and simultaneous ring.
  • Dial-in and Dial-out conferencing: CvW users must enable for dial-in and dial-out conferencing which enable these users to get into and out of SfB conferences.


  • Delegation, team call, and response group: CvW users should be disabled for delegation, team call and response groups.

Deploy Call via Work: Now, let’s have a look into deployment part of the CvW.

  • Create a global phone number: for your deployment which Skype for Business displays on the PBX caller ID of users who are making Call Via Work calls.
         Set-CsRoutingConfiguration -CallViaWorkCallerId +<PhoneNumber>
  • Create one or more Call Via Work policies:
        New-CsCallViaWorkPolicy [-Identity] <XdsIdentity> [-Tenant <guid>] [-Enabled <bool>] [-UseAdminCallbackNumber <bool>] [-AdminCallbackNumber <string>] [-InMemory] [-Force] [-WhatIf] [-Confirm] [<CommonParameters>]
  • Assign a Call Via Work policy to each user who will be enabled for Call Via Work:
        Grant-CsCallViaWorkPolicy -Identity <UserName> -PolicyName Tag:<PolicyName>

Part IV of this article covers limitation in Call via Work.

#Skype4B: Call via work (Part II)


Part I of this blog post covers introduction of Call via work, differentiate remote call control and describe how does CvW work etc. Part II will cover different scenarios of call via work which takes place.

Outbound routing scenario has been covered in Part I. Now, let me describe inbound scenarios.

Skype for Business Server and PBX can be configured in two different ways for incoming traffic:

  1. Skype first in line
  2. PBX first in line

Case 1: User experience when external PSTN user makes an inbound call:

In this scenario, Skype First offers all the features such as Skype toast, missed call alert and voicemail while PBX first only offers voicemail.

Scenario 1: Skype first in line scenario for inbound PSTN call:

User Experience:

  1. PSTN user makes a call
  2. Skype for Business Server receives call
  3. User A client endpoints is alerted
  4. Since User A is enabled for CvW and Simulring, a ms-SkipRnl header is used to force a call out to user A desk phone

Scenario 2: PBX first in line scenario for inbound PSTN call:

User Experience:

  1. PSTN user makes a call
  2. PBX receives call
  3. Since User A has PBX desk phone, therefore user desk phone rings

Case 2: User experience when internal user makes an inbound call:

In this scenario, Skype for Business user (as a first party) offers all the features such as Skype toast, missed call alert and voicemail while PBX desk phone (as a first party) offers voicemail.

Scenario 1: Skype for business user scenario for inbound PSTN call:

User Experience:

  1. User B makes a call to User A from SfB Client
  2. Skype for Business Server receives call
  3. User A client endpoints is alerted
  4. Since User A is enabled for CvW and Simulring, a ms-SkipRnl header is used to force a call out to user A desk phone

Scenario 2: PBX user scenario for inbound PSTN call:

User Experience:

  1. User B makes a call from PSTN desk phone
  2. PBX receives call
  3. Since User A has PBX desk phone, therefore user desk phone rings

I hope, this post gives you clarification about inbound scenarios of CvW. If you have any comments or queries, please write in comments box. I’ll be happy to hear from you and resolve all your queries.

#Skype4B: Call via work (Part I)


Skype for Business Server 2015 introduced Call via Work (CvW) and replaced remote call control (RCC) which was available in previous versions of Lync server. It enables integration between Skype for Business and your PBX phone system. A SfB user enabled for CvW can initiate a PSTN call from SfB client and leverages PBX phone to have a call with another user within organization or outside the organization.

How is it different from Remote Call Control?

RCC is a replacement of CvW but doesn’t work in same way, you can understand it in this way: RCC required computer-supported telecommunications application (CSTA) gateway to integrate Lync Server with PBX system while CvW uses Unified Communication Web API (UCWA) as the back-to-back user agent (B2BUA) between Skype for Business Server and PBX systems. Therefore, CvW only work in case you have direct SIP between Skype for Business Server and PBX systems.

Call via Work offers the following for PBX phone users:

  • Click-to-call experience form Skype for Business client
  • IM, App and Desktop Sharing, File Transfer
  • One-click meeting join experience

How does it work?

The end user selects another end user in their Skype for Business client, and clicks the phone icon to call him. Or, during an IM conversation, the end user clicks to call another user they are having the session with. The PBX phone of the user who placed the call starts to ring. The caller ID for this phone shows a global phone number which you have set up to show in the caller ID of all users placing Call Via Work calls. This global phone number is not an actual phone number that corresponds to any one person’s phone. Instead, it is a visual signal to let a user know that this is their own outgoing call, and not an incoming call happening at the same time. When you deploy Call Via Work, you should educate those users about this global phone number and what it means. The user who placed the call picks up their PBX phone. Skype for Business then initiates the voice call to the callee. When the callee answers, the voice call begins. If the two users already had an IM session going, it can continue. Courtesy: Microsoft TechNet

Let’s take an outbound call scenario where Users A which is enabled for Call via Work initiates a call from SfB client to external PSTN number.

  1. User A initiates a call from SfB client.
  2. Skype for Business Server places call to user’s PBX phone.
  3. PBX System routes call and user answer that call.
  4. When Sfb server perceives that call has been answered by local user then it initiates a far-end call by using user A DID.
  5. PBX system routes a call out to PSTN with user’s DID.
  6. Far-end calls answers and call is established.

Once call has been initiated, media will directly flow between both the end points.

Let’s take an another outbound call scenario where Users A which is enabled for Call via Work initiates a call from SfB client to User B within same organization. Here, User B is enabled for call via work and Simulring.

  1. User A initiates a call from SfB client.
  2. Skype for Business Server places call to user’s PBX phone.
  3. PBX System routes call and user answer that call.
  4. When Sfb server perceives that call has been answered by local user then it initiates a call to user B.
  5. Since User B is internal user and enabled for call via work and set to simulring their own desk phone, a ms-skipRnl header is used on an outbound call to force another call out to user B desk phone
  6. User B answers call from either skype client or desk phone and call is established.

Once call has been initiated, media will directly flow between both the end points.

The above examples are simple scenarios but there are many other scenarios which take place when deploy call via work. Rest of the scenarios, I’ll coven in next part of this blog series.

Call flow with Cloud Connector Edition


Cloud Connector Edition is an option for those customers who are new to Microsoft Real Time Communication and directly adopting Skype for Business Online (Office 365) for real time communication. At present to find an organization without any telephony system is almost impossible. When customers are looking for best RTC solution and adopting SfB online, it is crucial for them to leverage existing telephony investment while maintaining seamless user experience across all RTC modalities. Microsoft is committed to provide seamless PSTN calling experience through Cloud Connector Edition to those users who are accessing all the SfB modalities except PSTN calling form SfB online infrastructure.

Let’s discuss more about PSTN calling. In Skype for Business each conversation is divided into two pieces i.e. signaling and media. When you are using CCE all media traffic for PSTN calling will be managed by CCE and PSTN Gateway while signaling will be managed by CCE and SfB online infrastructure.

Whenever, we talk about telephony communication, it could be either inbound or outbound.

Outbound Calling: If a user place a call from internal network:

  1. Users dial an external PSTN number in E.164 format
  2. SIP traffic routes to Skype for Business online infrastructure
  3. SfB online performs a reverse number lookup for the dialed number
  4. The RNL fails because it is an external number and doesn’t belongs to any SfB user
  5. The call is routed to the Edge component of CCE
  6. If the PSTN routes exist Edge Server relays the traffic through Mediation component of CCE
  7. Mediation component sends the traffic to the PSTN gateway and establish a connection between the user end point and PSTN Gateway through Mediation component for media flow

Inbound Calling: If an internal user receive a call from PSTN network:

  1. PSTN Gateway receives a call from external PSTN number for a SfB online user who is in internal network as of now
  2. Gateway routes the SIP traffic to Mediation component of CCE
  3. Traffic goes out from Mediation component to SfB Online through Edge component of CCE
  4. SfB online performs a reverse number lookup
  5. The RNL passes and SfB online finds that this number belongs to the SfB online user
  6. SIP signaling goes to all the point of presence of that user
  7. Finally, Media traffic will be established between PSTN gateway and Mediation component and between Mediation component and the user end point for media flow

These are the features which are available through CCE as of now.

There are many limitation if you will compare it with Skype for Business on-premises or hybrid. Below are the list of limitations:

  1. No call via work or remote call control
  2. No media bypass
  3. No response group
  4. Active call can’t be transferred to the cell phone which is registered in your Active Directory by picking it from a list of suggested phones in the transfer menu. You can transfer to any other number.
  5. Call between SfB user and PSTN number can’t be escalated as conference call
  6. Users must use full number in E.164 format only
  7. Only specific series of Polycom phones are supported as of now
  8. No integration available with contact centers
  9. Private lines and common area phones are also not supported

I tried to cover most of the stuffs but there is no guarantee if you face any other limitation.

Skype for Business Cloud Connector Edition Public DNS, IP and Certificates requirements


Skype for Business Cloud Connector Edition deploys multiple VMs which allows users to connect with on-premises PSTN Infrastructure. As it contains Edge Server role, then obviously it requires Public DNS, IP and Certificates to function properly.

Let’s discuss internal things first.

Internal IP Addresses: Each CCE VM required one internal IP address, it means, you need four internal IP address for every CCE deployment. Make sure these IPs are from dedicated subnet, must not use existing subnets.

Internal DNS records: As each CCE deploys one ADDS, therefore all the internal dns records will point to deployed CCE internal dns.

Internal Certificates: Each CCE domain controller deploys certificate services with directory services, therefore all the internal certificate will be issued by internal certificate server.

Internal requirement looks simple but there are many more things which you need to plan in well advance to make the deployment successful.

Now let’s focus on external requirements which are very important to work CCE correctly.

External IP Addresses: One public IP address is required for external interface of edge server. This IP will be used by Access Edge and Media Relay Edge. You can use either direct public IP address or NAT IP address, if it is NAT IP address then specify both address. If it is NAT IP address then specify public IP address of the NAT device (one more parameter: “ExternalMRPublicIPs”) for media relay edge.

External DNS Records: External DNS records are mandatory for CCE employment. Onmicrosoft.com suffix is not supported for external DNS entries. You need to create external DNS record for access edge. In single site HA deployment, you need one dns record with multiple ip address and for multisite deployment, you need multiple dns records with multiple IP addresses.

Public Certificates: Public certificate require for each Edge component in CCE deployment. Certificates must have an exportable private key to copy between Edge components. Before you request public certificate, must plan for it properly.

You can have two different scenarios:

  1. Single SIP Domain
  2. Multiple SIP Domain

While choosing certificate, you can choose either SAN certificate with multiple entries or wildcard certificate.

Therefore, now you can have four different options;

First option: Single SIP domain with multiple SAN entries.

SN = <site1-accessedgepool>.sipdomain.com, SAN = sip.sipdomain.com, <site1-accessedgepool>.sipdomain.com, <site2-accessedgepool>.sipdomain.com

Second option: Single SIP domain with wildcard entry.

SN = sip.sipdomain.com, SAN = sip.sipdomain.com, *.sipdomain.com

(Note: With the above configuration, you must not create any sip.sipdomain.com entry in external DNS because this name belongs to the Office 365 deployment)

Third Option: Multiple SIP domain with multiple SAN entries.

SN = <site1-accessedgepool>.sipdomain1.com, SAN = sip.sipdomain1.com, sip.sipdomain2.com, <site1-accessedgepool>.sipdomain1.com, <site2-accessedgepool>.sipdomain1.com, <site1-accessedgepool>.sipdomain2.com, <site2-accessedgepool>.sipdomain2.com

Fourth option: Multiple SIP domain with wildcard entry.

SN = sip.sipdomain1.com, SAN = sip.sipdomain1.com, sip.sipdomain2.com, *.sipdomain1.com, *.sipdomain2.com

I hope this blog post will help you to plan IP addressing, subnets, dns records and certificates for CCE deployment.