SfB Server – Sonus SBC SIP Trunk – No audio during calls

I have recently been troubleshooting an issue a customer had been facing since installing a SIP trunk from a UK Provider in preparation for a migration away from older ISDN circuits. In this deployment, the customer had already configured the SIP trunk and calls inbound and outbound to and from end-user assigned numbers were working fine, two-way audio, good quality and calls were staying up without any issues.

The problem was apparent, when a call was made inbound to the on premises SfB Server PSTN Dial-in access number. Whenever a call was made to these numbers, the calls would establish, but no audio was being sent from the Conferencing Auto Attendant, greeting a callee and offering meeting ID and pin entry options.

As I hadn’t configured the SIP trunk myself I did the usual checks and reviewed the configuration of:

  • Signalling groups; which were configured correctly (inbound/outbound calls were OK)
  • SIP server tables; which were all defined for both SIP provider and SfB
  • Media lists were in place, the provider used G711 and the appropriate TLS media list was in place for SfB
  • SIP profiles were configured correctly

Using the Sonus logging tool, LX, from a bird’s eye view of the call, I could see the invite being accepted, call being setup and teared down correctly:

Call flow setupThe next step for me was to review the invite, from the outside in (inbound call), firstly reviewing the SIP invite and SDP negotiation between the provider and our SBC appliance. The invite was a routable IP address in our signalling group and SIP server table (ITSP IP) coming in to our internal IP interface for this SIP trunk…

…but then looking at the SDP negotiation, I noticed that for the media endpoint being offered within the SDP (referred to as ITSP IP2 below), the SBC did not have a static route back available to it, and all traffic to this IP address would be sent to the default route, pointing to an internal gateway (and therefore no way of reaching the ITSP):

The SDP negotiation provides valuable information, from the media processing endpoint, to the codecs and capabilities of the call. For further reading, the following are good references:

The customer has decided to strictly define the endpoints presented to them by the ITSP, in the static route table using a /32 notation and therefore would need to explicitly define each of the endpoints required for communication to ensure correct routing. In this instance, an IP address had been missed but by correctly configuring the static route table in the SBC to account for this IP (ITSP IP2), we were now being presented audio for inbound calls to the conferencing service.

An important note I would like to make is that in this scenario, it is crucial to ensure that all endpoints/networks have been accounted for – I continued to work with the customer to ensure that the static routes covered all potential endpoints as there is the potential for the ITSP to failover between endpoints and therefore reintroducing the issue we have faced above!


Sonus SBC SIP Trunk Config (Registration Mode)

I have recently been tasked with the deployment of a new SIP trunk for an office in Hong Kong, working with a relatively new SIP trunking provider in this region.

The deployment topology itself is straight forward; centralised SfB 2015 pools deployed to central sites, with local gateways servicing local PSTN connections at each geographically dispersed office location, a distributed SIP trunking topology. Each of the local site gateways was provisioned with SBA functionality. The local gateway being provisioned was a Ribbon SBC1000, very familiar technology.

Our SIP circuit was a registration mode trunk, meaning that a registration process must be completed with the trunk to authenticate and then subsequently, each outbound call would also need to respond to a challenge request.

This was the first trunk I had encountered using this mode so I thought it would make a good blog entry. This post, won’t go into the depths of the initial configuration of the gateway and SIP circuit, but will focus on what is needed that is different to the typical SIP trunk configuration.

From here, I assume you have deployed the following:

  • The initial SBC configuration, networking, hostname and SBC certificate
    A signalling group has been created representing the PSTN provider (we will apply additional config here)
  • A signalling group has been created representing an SfB Pool / SBA / STD Edition server
  • Call routing tables have been created
  • Call transformation tables have been created

If you do need some advice on the above, the following blog article but my friend Mark Vale is a great multi-part walk-through:


So assuming the above is all in place, the very first thing to configure are the Contact Registrant and Remote Authorisation tables which can be found under the SIP configuration node. I have seen references to configuration guides that state, that only the Contact Registrant table is required, certainly in my instance I had to configure both tables.

The Contact Registrant contains information in relation the Realm and User ID used when registering on the trunk and the Remote Authorisation table contains the credentials. This was my first hurdle and it purely came down to a language translation barrier so one word of advice would be really to clarify that you have all of the information required and in a supported format for the SBC1000.

The following settings were applied across my tables:

Contact Registrant Table:

Contact Registrant Table





Remote Authorisation:

Remote Authorisation Table







To confirm that you have successfully registered, the easiest way is to simply view the status of the contact registrant table, for further confirmation you can also monitor the registration request via LX or Wireshark, you will see a 200 OK response for a successful registration. Any failures at this point are likely to be due to the realm, user ID or password across the tables.








Once the trunk is registered, like me you will be tempted to make a test call (in my instance I actually believed I had the configuration ready). Now depending on your trunk, these calls may be OK, my test calls were failing and upon viewing an LX trace from the gateway, our provider was immediately responding with 404 User Not Found for a valid local HK telephone number:

404 not found







I went back to the provider and requested [politely demanded] additional configuration information. They responded this time with an internal configuration guide, that, would have been useful at the very start!
Within this guide, the provider stipulated the following:

  • From: DN@sipprovider.com (for example  21111111@sipprovider.com)
  • PAI: PilotDN@sipprovider.com (for example 21111111@sipprovider.com)

This is significant information needed on the trunk for the correct presentation of the call, to the provider before they will accept the call.

To manipulate the FROM header, I initially did a literal replacement of the entire FROM field, resulting in 21111111@sippovider.com being presented using SIP Message Manipulation.

SIP Message Manipulation






I also did the same for the HOST portion of the PAI field and replaced it with SIPPROVIDER.com

So now, my invites outbound, to the best of my knowledge, should be presented in a format that the provider accepts – boy was I wrong.

Upon sending an invite now, the provider was sending a 401 Challenge Request which was expected, now the issue was that our SBC was simply not responding to the challenge request and re-inviting without any authentication

INVITE sip:21111111@sipprovider.com:5060;user=phone SIP/2.O
call-ID: call-6A941SOO-OOOO-0010-1911-A@
Contact: <sip:21111111@local-sbc.com:5060;transport=UDP;maddr=>
Content-Length: 308
Content-Type: application/sdp
cseq: 2 INVITE
From: <sip:22222222@sipprovider.com:5060>
Max-Forwards: 69
Min-SE: 600
P-Asserted-ldentity: <sip:22222222@psipprovider.com:5060>
Session-Expires: 3600
Supported: replaces,update,timer,100rel
To: <sip:21818888@pccwone.com:5060;user=phone>
Via: SIP/2.O/UDP

This one had me stumbled for a couple of hours, I started looking at the logs, line by line and then noticed that the FROM: field, did not contain a ;tag=xxxx;sgid=x, this tag  information is what a UAS uses to determine that a call is not a duplication session (if you want to dig a little deeper https://www.ietf.org/rfc/rfc3261.txt), and which signalling group should manage the connection and without this our SBC was not responding as we would expect it to. It can be found correctly formatted in the image below:



Confirmation of this theory became apparent when I found the following errors in the SBC log:

LX Error Log

No tag value in FROM header, it then goes on to fail to find a suitable signalling group.

Taking a step back reviewing my options I decided to revert the FROM manipulation and not implement it using SIP Message Manipulation, and use the more simplified SIP profile options to set a static FQDN for both TO and FROM fields:















This did the trick, my call was correctly presenting ALL required ITSP information, calls were not permitted inbound and outbound!! SIp Message Manipulation could have achieved what we needed in this point, but the SIP profile is easier configuration for anyone to pickup and read so we opted for this method.

Additional notes:
We were using EXT prefix in a user Line URI and this was affecting the presentation of the P-Asserted Identity field. To overcome this, within the ITSP SIP Profile, we set the following:

  • Calling Info Source: FROM header

Skype for Business Server 2019 / vNext – Ignite 2017

I have been very fortunate to have been given the opportunity to attend Ignite 2017 in sunny Orlando Florida, its my first time at ignite and all I can say is WOW.

It’s a great opportunity to network, meet those faces you see everyday online and just get a much better understanding of all products at a deep dive level.

I have just attended a session on Skype vNext, or as we now know Skype for Business Server 2019, the purpose of this post was to provide you all with the content that was shared and give you an insight into what’s coming;

For those customers that have invested in Server, you aren’t being forgotten about! Now would be a good idea to start to think about that shift to the Cloud of UC communications but there be at least (maybe maximum!) one more on premise server iteration – Skype for Business Server 2019

So, from Mid-2018, we can start to expect to see Office 2019 clients with a view to release, Late 2018. One big announcement was the fact that these clients will support a minimum of Windows 10 and will be available on in the C2R format

Skype for Business Server 2019

  • IT Pro and Voice Centric Release
  • Improved Teams Interoperability
  • Refreshed mainstream support
  • Quality Security and Performance fixes
  • Refreshed clients
  • Improved MAC client, finish the story
  • C2R clients

SfB 2019 Client will be backwards compatible with the Skye for Business Server 2015 AND Lync Server 2013 – allowing for deployment of new office clients and desktops OSes in parallel to server planning

Deployment Requirements (important!)

High level deployment requirements were released and included some significant announcements:

  • Lync Server 2013 and Skype for Business Server 2015 support SIDE BY SIDE migration to Server 2019
  • SfB Server 2019 requires a minimum of Windows 2016 and SQL 2016
  • No Standard Edition in the next release
  • No in place upgrades,
  • Director Role has been dropped (although you could setup an empty EE pool and let it perform your auth and 301s)
  • The Online code effectively has been brought down and used as the basis for SfB Server 2019

Hybrid Value in 2019 Server

  • Don’t need to home users online but you do need a tenant!
  • We can give the on-premise users some of the same experiences
    • Same with admin experiences too
  • We will see a new hybrid Aware Office 365 Portal
  • Single portal for all Call analytics and reporting, one portal for all users, tailored
    • Teams users, SfB Server 2019 and SfBO users
  • Voicemail, Auto Attendants and Call queues, integrated with SfB Server 2019
    • Reduced Exchange Server dependency
  • Support for Hybrid Modern Auth (that’s already here)
  • Ensure interop between SfB and Teams with migration paths
  • Server 2019 will connect to the online portal to provide consistency
    • The new portal is hybrid aware

Meeting Migration Service

  • Scheduled meeting update service – replaces meeting migration tool
  • Works for users moving to SfBO from Server
  • Works for users adding PSTN conferencing to SfBO
  • Update for ignite: Users mailbox can be Exchange online or Server



  • MMS with Exchange Server 2016
  • Hybrid Modern Auth

Coming Soon:

  • Customer Surveys for SfB Server 2019 – late 2017
  • SfB Server 2019 preview bits – Mid 2018

Stay tuned for more updates straight from Ignite 2017!

Combining Call Queues and Auto Attendants

With the increase in popularity of Skype for Business Online Cloud PBX (as it is known for now…), I have been approached on many occasions and often presented with pushback, around the limitations of Cloud PBX Call Queues.

My first response is quite simple – they aren’t designed to replace an enterprise grade business contact centre. If we take a second to think about Server Response Groups – they were never aimed at replacing Enterprise Contact Centre, more so, bridge the gap to the requirement.

So, back to the point, with Cloud PBX Call Queues, I am often approached on their capabilities and limitations.

The main one being the fact that they are single tiered, so we call a given number, enter a given queue and a call is distributed to queue agents based upon Distribution lists:

Incoming calls via a Call Queue onlyTo overcome this limitation, it is time to start combining Call Queues with Cloud PBX Auto Attendants!

Auto Attendants allow us to record custom business menu greetings/menu prompts that can then feed into a Cloud PBX Call Queue depending upon the key pressed. Auto attendants not only allow for transfers to call queues, but they also support the ability to transfer to another AA!

So, if we think about this for a second, we can record a customer business hours menu prompts (Press 1 for Sales, Press to for HR, press 3 for Marketing) that then transfers into either, another tier of options, or a given queue:

Combining Auto Attendants with Call Queues

Based upon the above logic and call flow, we can introduce tiered call queues, providing callers with several options to find the queue best suited to handle their call.

The downside to this approach; each Cloud PBX Call queue requires a service number – they aren’t infinite either…hopefully we will support SIP only call queues soon!

Admittedly, it is still not providing feature parity when compared to a Contact Centre, but by using the above methodology, we can start to build out those ACD scenarios.

Exchage Online SBC Connectivity Discontinued

Microsoft have recently made the announcement that support will be withdrawn, as of July 2018, for third-party PBX systems (Cisco, Avaya, Siemens etc.) to leverage Exchange Online Unified Messaging (UM) via a Session Border Controller (SBC).

Today, as shown below, many organisations provide voicemail functionality via Exchange Online UM to the end users mailbox or telephone device whilst continuing to use their third-party PBX for call control functionality.

Removal of Microsoft SBCs

Based upon the announced change, customers have under a calendar year to complete the migration to one of the following supported topologies:

  • Migration from a third-party PBX to Office 365 Cloud PBX
  • Migration from a third-party PBX to Skype for Business Server (On Premise or Hosted)
  • Implementation of Cloud Connector Edition
  • Implementation of a software based connector, connecting the PBX to Skype for Business Server (On Premise or Hosted)
  • The final option is to implement a third-party voicemail system, removing the dependency upon Exchange Online

The following topology will continue to be supported:

  • Skype for Business Server leveraging Exchange Online UM
  • Third-party PBX systems connecting to Exchange Online UM via an API and NOT an SBC
  • All forms of Exchange Server UM (on-premise)

Unsure of what to do next? Feel free to get in touch and we would be happy to talk through the available options in more detail with you!

Move User from Online to Server Fails


When trying to move a user from Skype for Business Online to Skype for Business Server, the following error was being output in the Skype for Business Server Control Panel – “Index was outside the bounds of the array” – not the most helpful issue to troubleshoot!


A customer had recently requested support for the migration to SfB Online to SfB Server for a subset of users.

After initially understanding why this migration scenario was taking place, I began to look at the configuration in its entirety:

  • All Skype for Business Servers were running the latest CU
  • The SfB Server Topology was correctly and successfully published with no warnings or errors
  • All firewall ports had been opened correctly
  • Public DNS was pointing to the on-premise estate, for all required records
  • A Shared SIP Address space had been enabled
  • The Skype for Business control panel Hybrid wizard confirmed “all prerequisites had been met”

When testing a move of a user myself, I too encountered the error the customer had been reporting, which was;

“Index was outside the bounds of the array” – not the most helpful issue to troubleshoot!

The same occurred too when trying to move a user using PowerShell, with the appropriate switches.

As we had not implemented the solution, it was time to take a step back and look at all “moving components” within this scenario, including AAD Connect and ADFS.


When viewing the attributes that were being synchronised from the customers AD to Azure AD, I noticed that none of the MS-RTC* Attributes were included… hmmmm…..

After speaking with the customer, I then determined that Skype for Business Server had been install AFTER the installation of AAD Connect!

We decided to “Refresh the Directory Schema” using the AAD Connect Wizard, o ensure that our SfB attributes were being synced.

Following on from the refresh, we could then complete the procedure of moving a user from Online to Server, for those that needed to be migrated.

Cloud PBX –  Who, What, Where, When and Why?

It’s no secret that Microsoft have announced that the already feature rich service that is Office 365, will now include “Enterprise Voice” within its Skype for Business Online service.

It has been a long time coming, we dipped our toes in the water in a previous (similar)  iteration that was entitled ‘Hybrid Voice’ – well now it is back and along with additional supported topologies, they are here to stay!

This post is intended to be a ‘living post’; with constant updates as information is released and functionality is unveiled.

Quick Point:

  • Skype for Business Server = On-Premise
  • Skype for Business Online = Cloud
  • Skype for Business Hybrid = integrated On-Premise and Cloud deployment

Today, Skype for Business Server:

So as it stands, anybody wanting to leverage the enterprise grade PBX functionality offered by Skype for Business, must deploy the on premise iteration of the product, Skype for Business Server (or a hosted service via a third party). This enables customers to migrate all telephony functionality into the new on premise infrastructure in a smooth, well structured approach when planned correctly.

There is often reluctance to do this and from experience, this is due to a lack of knowledge of the platform and its eco system partners capabilities.

In a nutshell, yes we can provide support for the following AND more;

  • TDM and analog trunking
  • Multimedia Contact centres
  • Call Billing and Reporting
  • Call Recording (PCI compliance too)

This is just a shortlist of the capabilities, for an overview of all trusted partner applications and supported infrastructure components, the Skype for Business Solutions Catalog is the place to be.

So hopefully, if you did not already, you do have a better understanding of where we are today….

Cloud PBX – What is it and Where are we going?

In line with the ‘New Microsoft’, cloud first, agile software releases etc. the following offerings are being made available;

  • Cloud PBX with PSTN Calling (US only as it stands)
  • Cloud PBX with on premise PSTN connectivity
    • Via an existing Lync/Skype for Business pool
    • Via Cloud Connector Edition
  • Cloud PBX PSTN conferencing

There are also additional programs, but those are out of scope for this post;

  • Android Preview
  • Broadcast Meeting

In addition to the Skype for Business Server offering, Skype for Business Online will now start to offer ‘Enterprise Voice’ functionality in the cloud through your existing tenant service.

It is important to note that initially, the service will not provide all the functionality that on premise counter part does, the following table shows the functionality announced today:

Office 365 Express Route

In my opinion, taking into consideration the nature of real time UC traffic, versus the more static content, in say Exchanged Server, network connectivity has been one of the reasons many organizations have not yet adopted Skype for Business Online.

Microsoft have now accounted for this in the form of Office 365 Express which is now Generally Available.

This service allows organizations to leverage a managed connection, from their local on premise infrastructure into the Office 365 data centre, adhering to the Quality of Service DSCP markings recommended for Skype for Business.

Again, in my opinion, whilst not mandated, I would recommend looking at adopting Office 365 Express Route within your network to ensure end user quality can be guaranteed, as opposed to best effort traversing the internet.

Cloud PBX with PSTN calling

I strongly believe, this is where everything is going. As you will see, each of the methods to achieve voice in the cloud, ultimately leads to this topology.

  • At the moment, this is an option available to the US only with plans for expansion CY16.
  • This offering allows customers, to utilise Microsoft as their sole telephony provider.
  • As it stands, this service is currently only available to US tenants, with a further geographical reach aimed for CY16.
  • Either acquire new telephone number ranges for organisation, or port your existing telephone numbers into the service and have no dependencies for on premise server infrastructure to deliver your telephony services.
  • User accounts are homed in the cloud, telephony services are hosted in the cloud, under a financially backed SLA. A summary of the topology may look like the following:

For customers interested, it is perfectly viable to pilot the service, acquiring telephone numbers for users and allowing for evaluation of the service in line with preview program updates. This is a clean, non disruptive way of testin out the Cloud PBX with PSTN calling functionality.

Whilst there is not feature parity with th, to account for this Microsoft have presented several ways for customers to achieve the Cloud PBX functionality, each of those will be discussed now.

To enable a user, you must;

  • Own an Enterprise Office 365 tenant that contains E5 licenses
    • OR E1/E3 + Purchase of the Cloud PBX License
  • Acquire new or port existing telephone numbers
  • Assign Office 365 E5 to the users in question
  • Assign on of two calling plans (current offerings)
    • Domestic only – which includes all 50 US states
    • Domestic and International – exactly as it states on the tin
  • Assign a telephone number to the user

It is a simple as that, there are additional considerations to be taken into account, Office 365 AADSync, ADFS dependent upon your requirements, but again out of scope for this post.

Cloud PBX with on Premise PSTN

Falling in line with the hybrid topologies, that allow organizations to transition services over time, Skype for Business Online Cloud PBX now supports this platform topology.

As stated earlier, the current cloud PBX service from Microsoft does not provide all of the functionality that is available from  an on premise deployment. To account for this, Microsoft allow for the retention of existing telephony carrier relationships and  on premise deployment applications such as contact centres, through the hybrid topology.

For those users that require corporate telephony, home them in the cloud, for users requiring access to custom ISV applications, they can remain on premise, whilst the organisation continues to integrate new functionality as it arrives within the online service.

This offering breaks down into two further offerings;

  • Cloud PBX with on Premise Skype Business
  • Cloud PBX without any existing on premise Skype for business Lync

Let’s explore each of these further;

Cloud PBX with on premise Skype for Business

This option is similar to the Hybrid Voice topology that was previously released and withdrawn, to and from the market.

It allows organisations to leverage the existing investment made into building out an on premise deployment with a view to transition all services to the cloud.

In this scenario, users are homed within Skype for Business Online, but the voice services required by the user are delivered via the Skype for Business Server (on premise) infrastructure.

Important notes to consider during planning:

  • To enable an SfBOnline user for this Cloud PBX offering, you must have provisioned your company domain (e.g. uccorey.com) to your Office 365 tenant
    • .onmicrosoft.com domains are not supported
  • Lync Phone Edition must be updated to the minimum required firmware
    • Do not move users online before updating the firmware
    • If a user have been moved online, prior to firmware maintenance – DO NOT update the device firmware nor perform a hard reset
    • Move the user back on premise prior to updating or resetting the phone device
    • If a hard reset if performed, before the device is updated, it will default to PIN authentication, which isn’t supported
      • Which will answer any CX500 question…

System Requirements / Prerequisites

  • Front End Server must be running Skype for Business Server 2015 or Lynch Server 2013
  • Edge Server must be running Skype for Business Server 2015 or Lynch Server 2013
  • Mediation Server must be running Skype for Business Server 2015 or Lynch Server 2013
  • Enterprise Voice is configured and tested on premise, including all PSTN components; SBCs, IP-PBXs, PSTN Gateways…
  • Azure AD Connect 1.0.9125.0
    • Older versions of the tool must be upgraded
  • Hybrid Connectivity (Shared SIP address space) must be enabled between your on premise deployment and Office 365 tenant
  • To support Single Sign On for end users, Active Directory Federation Services must be provisioned
Cloud PBX with On premise connectivity, without Skype for Business Server:

This scenario applies to organisations that have not yet deployed any Skype for Business or Lync infrastructure, but wish to adopt the service for all Unified Communication and Telephony functionality.

In this instance, organisations must deploy a small ‘flavor’ of an SfB deployment called ‘Cloud Connector Edition’. This virtual appliance server is a virtual machine that consists of the following  server roles:

  • Central Management Store (CMS) Role
    • Configuration store for the topology components
  • Edge
    • Access Edge
      • SIP Routing between on premise and online services
    • Media Relay and Media Daly Authentication
      • Media routing and authentication token for media routing
    • Outbound Routing
      • Supports only global policies based on outbound PSTN numbers
    • CMS Replica
      • Maintains a copy of the CMS local and synchronizes data from the Global CMS
  • Mediation Server
    • SIP and Media gateway between Skype for Business and the on premise PSTN gateways
    • Includes as CMS replica
System Requirements / Prerequisites
  • .onmicrosoft.com domains are not supported
  • Cloud connector edition is currently supported on Hyper V hosts
  • Cloud connector is provisioned using PowerShell scripts that may change the configuration of your Hyper V Hosts – review them!
  • CMS and Mediation roles can be collected on a single Hyper V Host
  • Edge Server VM must be provisioned on a separate Hyper V hosts that is deployed into a DMZ
  • Administrator permissions over the Hyper V Host
  • Administrator permission to publish the topology in the on premise domain
    • AD Schema
    • Enterprise Admin
    • Domain Admin
  • External DNS Records
    • ap.<Domain Name>
    • mr.<Domain Name>
  • Your Office 365 tenant must have the required SRV records created for it
  • External Edge Certificates must be procured
  • Firewall ports 443, 5061 and 3478

This appliance, is used to create a SIP trunk connection to a supported PBX or SBC appliance, which becomes the gateway for the online homed user account voice traffic. Users are homed online and consume UC services via the online pool, whilst PSTN voice traffic is routed via the Cloud Connector VMs via the existing telephony infrastructure.

The following TechNet article details the required steps to implement Cloud Connector Edition – as this becomes available, keep an eye out for updates to this post!

Calls fail from Lync to Cisco Call Manager via SBC

Good afternoon everyone!

I have recently been involved in a Lync Enterprise Voice Telephony pilot, coexisting with Cisco Call Manager (CUCM) during the pilot phase.

So to help give a better understanding of the issue, the below diagram summaries the setup.




I liked to provide as much info as possible, if you need a quick fix, scroll down to the resolution section 🙂

Continue reading

Persistent Chat – All Channel Servers are down

I was recently rebuilding my home lab, purely as a refresher when I ran into a (new for me) hurdle when deploying Persistent Chat.

I had deployed;

  • Single standard Edition Server
  • SQL Server with Reporting Services, hosting Monitoring and Archiving

I had then decided to update my deployment by adding Persistent Chat to my Standard Edition Server (Collocated)

  • My lab was running the most current windows updates and SfB Updates
  • I updated my topology to include pChat
    • FQDN – SE01.uccorey.local
    • SQL Store – SE01.uccorey.local\rtc
    • File Share – SE01.uccorey.local\UCShare (File Share)
    • Remaining options left at default
  • Successfully published my topology with no issues
  • Started the Skype for Business Persistent Chat Service


When I then went to manage the service, via the Skype for Business Server Control Panel, I was presented with the following error;



The first area I checked was the event viewer logs, initially the “Lync Server” logs were not showing any issues and were only capturing my starting and stopping of the service.

After reviewing the application log, the following error was being presented;


After seeing this, I updated the permissions, on the MGC databases, under the RTC SQL instance located on my Standard Edition Server and then for good measure, restarted the server – which corrected the issue and allowed me to continue on with my pChat configuration.

Hope this helps you!

Skype for Business Broadcast Meetings Part 1

Unless you have been hiding under a gigantic UC rock, you will have no doubt seen the recent announcement from Microsoft around Skype for Business Broadcast Meetings.

Further enforcing the agile software release strategy of Cloud first, On-Premise second – should you fall into the latter category, this is the first Skype for Business feature release that is explicitly going to depend on hybrid connectivity being in place.

In Lync Server 2013, Hybrid connectivity always felt like an afterthought, something to bolt on, to help you get from A to B but there was never any real feature benefit from doing so (IMO – it was purely for migration purposes).

With Skype for Business, this has now changed – there will actually be scenarios where hybrid connectivity is required to not only allow for selective user placement and migrations, but also to enable specific functionality, Meeting Broadcast being the first.

Continue reading