Skype for Business Mac Client – General Availability

I currently run a MacBook Pro for my daily driver, it’s the ‘spice of life’ I say! A MacBook Pro, a Google Pixel phone and the Microsoft Office 365 collaboration suite is what makes up my toolset. Now more then ever collaboration and data is becoming more accessible via a device flavour that you prefer. Running Mac OSX while working with the Microsoft stack presents two issues I’ve had to endure to this point as an end user and adminstrator:

  1. I want to leverage the full capability of Kloud’s Skype for Business platform while in OSX
  2. I want to execute PowerShell CLI natively in OSX

I’ve marked October 26th in my calendar as the day where I get to put a line through one of my wish list items. Skype for Business Mac client has become generally available and free to download here. I noticed while I can download the client from, I’m yet to have it available to me in the Office 365 portal where I’m still offered my very old friend Lync 2011 to install.

This software isn’t all that new to me personally, I’ve been on versions of the preview client for a while now with mixed emotions. That being said, that’s what a preview program is all about! For those wondering what you will get with this first release ( here is a closer look.


The installation package will ask you to shutdown Safari and once you have hit ‘next‘  or ‘continue‘ the correct amount of times you will be presented with the login splash screen.


Once you have logged in successfully with your credentials you will receive the ‘run-once‘ welcome wizard. Which probably gives away most of the capability you will have so I won’t double up.

It’s not my intention to turn this into one of those ‘unboxing videos‘ you see on youtube, but here are some key features that I feel you will need to know about since either using the preview or being a first time consumer of Skype for Business on Mac.

All the normal and expected features are here:

  • Instant Message
  • Tabbed Conversations
  • Audio Call
  • Video Call
  • Multi-Party Instant Message, Audio and Video
  • Share Desktops
  • Join Meetings
  • Dial PSTN Numbers
  • Receive PSTN Calls
  • Listen to Voicemails
  • View conversation, IM and call history

Preview to General Availability

Voice users, you get the very important advanced calling options in preferences which wasn’t in the preview. This includes:

  • Call Forwarding Behaviour
  • Dialin Conferencing Pin/Settings Link
  • Voicemail Greeting Option


A dial pad and/or a field to paste a number prior to dialling in the GUI was missing, not any more:


When you click to join a Skype for Business meeting from a URL in a calendar item you will be prompted to trust the ‘Skype for Business Meeting Join Plug-in‘ allowing native meeting join into the Skype for Business application from a Hyperlink:


What things are missing? And,….will I really need them?

I’ll let you be the judge if these are things that you just can’t live without. Here’s a few notable mentions I can see:

  1. Team Call / Delegates options (was available in Lync 2011)
  2. Audio Test Call Service
  3. Ability to share desktop while in 1-1 window (was available in Lync 2011)
    1. Workaround: You must ‘Meet Now’ and invite the user, desktop share is then available
  4. Ability to send files in 1-1 or meeting windows (was available in Lync 2011)
  5. Unanswered call delay and procedure options (Call timer and forward)
  6. Meeting Recording settings

Final thoughts

At the end of the day if its stable, its a win. The preview was problematic for me, with breaks in network connection and re-connection being my main issue. Microsoft have advised that there is server cumulative updates to install to the backend for best compatibility which could aid experience. From a client perspective they advise that you uninstall all previous clients (Lync 2011 or Skype for Business Preview). All these ‘need to know‘ fine print can be found in the ‘Details‘ section of the client download.

Happy downloading.

Automated Call Distribution for Cloud PBX

Microsoft’s Cloud PBX is well on its way to provide Office 365 customers PSTN calling ability in Skype for Business, if you’ve missed out my colleague Joel Neff has written a great blog about the start of Cloud PBX and the features it will offer the end user with call functionality. To put it very simply, they will get the same experience as a traditional Skype for Business Enterprise Voice user. This will enable you to have PSTN numbers assigned to your end users and will be sufficient for 1-1 and conferencing calling scenarios, but what happens with my public number entry points? Numbers that aren’t assigned to a user, but are really more important to get answered than Joe Bloggs desk phone.

What about call management needed for servicing business requirements through telephony?

Call Queue & Distribution

An enterprise telephony solution must have methods for routing calls not only to an individual, but a collective of individuals provided by rule based workflows, commonly known in the telephony world as Automated Call Distribution (ACD) or Hunt Groups. Cloud PBX will offer this capability that we are familiar with on-premises, allowing your main publicly listed numbers to come into a calling workflow to be processed with features such as:

  • Call Queues
    • Timeout Options (wait times)
    • Overflow Options (transfer, redirect, voicemail)
    • Max Queue Sizes (calls in waiting)
  • Agent Groups
    • Assigned users agents in Office 365 with E5
    • Assigned user agents with Enterprise Voice on-premises in a Hybrid environment
  • Distribution Methods
    • Attendant routing
    • Serial routing
    • Parallel routing
  • Toll-Free Number Services can be ported
  • Upload custom recorded greetings and menu options (wav, mp3, wma)
  • Agent Anonymity
  • Business and outside business hour times
  • No number call queues
    • Importantly having services with SIP addresses only (no PSTN number). Can be used to servicing down stream and internal call workflows

If you are familiar with Lync or Skype for Business Server on-premises these terms will be familiar to you as they are hosted on the Front End Server role.

So, what you’re really saying is there will be Response Groups and IVR’s available in the Cloud?

Yes is the answer, I’m very pleased to see that the workflow tooling that is fundamental to a enterprise voice rollout on-premises will be available in the cloud service.

Inbound Call Termination

To leverage this functionality you will need to port your service numbers to Office 365. It is my understanding that it won’t be possible in version 1 to have existing on-premises PSTN connectivity (via SIP/ISDN) with an existing deployment or Cloud Connector (CCE) and have that inbound call be serviced by an on-premises gateway to the mediation server and then routed to a workflow managed in Skype for Business Online Cloud PBX. The number will have to come directly into the Office 365 service and not through your existing deployment, this topology is commonly referred to as ‘Cloud PBX with PSTN Calling‘. I don’t see this as real issue, if you’re servicing your Cloud PBX via an on-premises gateway then you can run the workflow on the Front End server.

In my mind this really does complete the telephony platform if you looking to enable your business with E5 Cloud PBX in Office 365. Now its just a matter of time while we wait for it to be available in the datacenter that services your region. Tick Tock Microsoft.



Change ring tone behaviour with a Sonus SBC and SIP trunk provider

I recently had an issue with calls originating from a SIP trunk provider to Skype for Business Server(s) that needed to change who supplied the ring back tone. This would have been a much simpler process with ISDN, but SIP trunks are a much more involved PSTN connection. If you’re having problems with ring back this should help provide a quick troubleshooting step to expose a problem in this area. This article specifically describes what to change in Skype for Business and Sonus 1000/2000 SBC to get the desired outcome with a SIP trunk. “Ring-Ring, Ring-Ring!“.

A notable mention is that SIP Trunk Providers are not all created equal. The call setup could differ from this example.

My aim which led to this article was to change the ringtone generation from the SBC, to be supplied by the carrier. As I hunted through the SBC capture for the call setup information, I noticed the Mediation Server sends a 183 message with SDP back towards the SIP Trunk as seen in the below;

183 with SDP

I wanted to stop this behaviour of the Skype for Business Mediation Server sending 183 Session Progress messages to the carrier during inbound call setup. As this was contributing to whom was generating the ring back in my scenario. I’ll explain…

What are we looking at here?

The highlighted capture shows a 183 Progress going back towards the carrier in the setup of the call with a SDP. We are interested in this step because it has SDP which is leading towards whom/what is going to perform the ring tone generation.

What is a 183 Message?

Wiki has me covered here.

183 Session in Progress: This response may be used to send extra information for a call which is still being set up

Versus standard 180 Ringing

180 Ringing: Destination user agent received INVITE, and is alerting user of call
Thanks Wiki! Therefor the message we are looking at above has a 183 with SDP. We know two things;
  • The call is still being setup
  • and there is still codec information being arranged.

Some important details I note about SDP

How do I know a message has Session Description Protocol (SDP) information?
Content-Type: application/sdp
I know its an audio profile equalling RTP Audio Video Profile (RTP/AVP):
m=audio 30190 RTP/AVP 8 0 97
I know some of the codecs being sent for media. We are sending standard G.711 audio codecs used in PSTN calls:
G.711 A-Law 
rtpmap:8 PCMA/8000/1
G.711 µ-Law
rtpmap:0 PCMU/8000/1

So what’s going to happen?

The default behaviour for a Sonus SBC is to allow 183 Session Progress messages (why wouldn’t it!), which leads to Early Media during the initial call setup. Simply, the sequence of these messages sent to SIP Trunk with a 183 Session Progress messages with SDP information makes the SBC decide to generate the ring back internally.

Okay, we know why its happening. How can we stop this behaviour? I want to make the carrier work for their money.

I figured I could achieve this via stopping 2 things:

  1. Disable the Early Media message from the SIP Trunk Provider to the SBC and onward
  2. Remove the 183 Session Progress messages with SDP from the Mediation Server heading back to the trunk

Disable the Early Media message from the SIP Trunk Provider passing through

On the Signalling Group that connects the carrier and the SBC. Disable Early 183.

Early 183

Remove the 183 Session Progress messages with SDP from the Mediation Server

There isn’t a way to disable this natively in Lync/SFB Server so this is why we want to do it on the SBC. We are going to manipulate packets coming from the Mediation Server back to the SBC before it gets sent to the carrier.

Under the Settings Tab > Telephony Mapping Tables > Message Translation. Create Message Translation Table

Remove SDP Translation

Key notes from above:

Incoming criteria to match:

  1. Looking for 183 Progress Messages
  2. Includes SDP information

Outgoing result:

  1. Change the Message Type to 180
  2. Remove the SDP

(If I was to leave the outgoing message type as 183 but strip the SDP portion, the call will progress with no ring back and the inbound caller will experience silence throughout this time).

Apply this Message Translation to the Call Route Table from the SIP trunk. This is what makes the translation active on all proceeding inbound calls. The resulting call setup;

180 Ringing

Ring-Ring, Ring-Ring” says the carrier.

Office 365 – AADSTS50008: SAML token is invalid

If you’ve made it to this post because you are troubleshooting your AD FS sign in with Office 365 due to “AADSTS50008: SAML token is invalid” I still recommend you do all the standard troubleshooting steps provided in this article below the image:


Generally speaking, if you’re getting issued a token from your AD FS server and Microsoft’s STS is stopping you from logging in, it would be because of your token signing certificate:

Has your Token-Signing Certificate changed since you last told Microsoft?


It’s never a bad idea to re-run the following:

Update-MsolFederatedDomain -DomainName [verified domain]

Executing this MSOL cmdlet will get Microsoft’s STS service to check your Metadata, which in turn will update any certificate changes you may have made. If you’re really clever you can go to your WS-Federation Metadata and check what you’re telling the world is your public token signing certificate.

  1. Navigate to https://<AD FS Namespace> in Internet Explorer.
  2. Search for KeyDescriptor use=”signing” in the metadata document.
  3. If you copy the raw certificate data from <X509Certificate> into a text file and save with extension ‘cer‘ you can validate it matches what’s in your AD FS console > Service > Certificates > Token-Signing

Good, we have that under control. I experienced an issue the other day where I still got the error post running this cmdlet and performing the above nifty check….. Head scratches. Firstly, I know that my AD FS services has processed my sign on attempt and given me the required information to take to Office 365 and log in. Secondly, I know that my signing certificate is correct. Still the error remains;

We received a bad request.
Additional technical information:
Correlation ID: 82121251-3634-4afb-8014-fb5298d6f2c9
Timestamp: 2016-03-04 00:25:35Z
AADSTS50008: SAML token is invalid

My issue was a little unique but worth a notable mention on the internet. In my scenario, If I left my browser page up with the error shown above for a length of time, suddenly if my browser refreshed I would get dropped into whatever it was I was trying to authenticate to. So my authentication was successful with Microsoft after a point in time. I highlight those words cause I literally had to say them out loud to myself before I found the fix. Looking at the AD FS servers where my token is issued from, I took a quick look at the time. I then took a look at the time on the AD workstation I was trying from, they both seemed to be in synchronisation with each other.  What about from my BYOD Surface that I use at Kloud which uses a internet time source?

Great Scott! 7 minutes difference!

My token was being accepted by Office 365, but only once Microsoft had caught up to the future from which I had came from. This isn’t unreasonable from Microsoft to not allow my issued token until that time had actually happened in Microsoft cloud land. This wasn’t an issue that showed its face as easily with internal applications as all domain controllers and workstations were following orders from the time source in the domain. The problem was that the domain couldn’t synchronise with a internet time source at the time master. So it was slowly but surely sneaking ahead. Once we had come back from the future, the issue with ‘AADSTS50008: SAML token is invalid’ was resolved and authentication was instantaneous on the first attempt once again.

I don’t want to put the fear of the ‘internet time gods’ on you, I believe that there is some kind of threshold that Microsoft will allow. Just not in 10 minutes time or maybe tomorrow, in the future.  Possibly the magic number for token timestamp issuance is plus or minus 5 minutes. Once I rolled the AD FS servers time back within a couple of minutes/seconds of the internet time gods, tokens were accepted. Now over to the AD and Network teams to restore order on a wider scale.

Delegate Mailbox Access using Groups in Exchange Online

A common misconception about granting mailbox access rights in Exchange Online is that you can only add access to the individual and not a group. You may have opened the Exchange Administrator Center (EAC), found the mailbox you wanted and looked at the delegated access tab. Only to be provided with a list of eligible user identity’s, but none of your on-premises security groups that have been created. Fear not, the on-premises groups just need a little remediation to the correct flavour to be seen in the picker and then applied.
The key settings of a group to assign mailbox access in Exchange Online are:
  1. Universal Security
  2. Mail Enabled
Things in your environment may have gotten this way over time as legacy on-premises Exchange Server versions weren’t as picky with your selection and would allow the permission to be granted to any kind of group you threw at it. Moving to Exchange Online has more sophisticated taste that needs to be catered for due to its Evergreen state with all the latest Exchange trends.
If you migrate on-premises mailboxes with these slightly incorrect permissions to Exchange Online they will be lost forever. So if you remedy the existing on-premises mailboxes before initiating a remote move request to Exchange Online, no further action will be required at completion.

The Process

Update the group to universal:
Get-Group $Name | Set-Group -Universal
Mail enable the group:
Enable-DistributionGroup -identity $Name
Finally, not compulsory but if you want the group to be hidden from your Exchange Address Book:
Get-DistributionGroup -identity $Name | Set-DistributionGroup -HiddenFromAddressListsEnabled:$True
Force a synchronisation of your group modifications with Azure Active Directory and you should find that the group will be available in the Office 365 Exhange Administrator Center. On the Azure AD Connect Server:
CD C:\Program Files\Microsoft Azure AD Sync\Bin\
.\DirectorySyncClientCmd.exe delta
So my final note that I would like to re-iterate is that if you tidy this stuff up before migrating to Office 365 you will have a lot less problems when the mailbox becomes active in Office 365. A mailbox that has been migrated with a faulty group type will have permissions assigned on the object, but will not resolve to an object and therefore only show SID information. Firstly the permissions fail, but secondly, it makes it very difficult to find out what the group was previously to add post migration. (see first permissions below)

 Hot Tip

Fix the issue with your groups before you start the synchronisation of the mailbox to Exchange Online and the permissions will be stamped correctly during the initial phases of the move request and once finalised, will work as expected.

Block Inbound/Outbound Calls on Sonus SBC 1000/2000

At Kloud we had an interesting chat amongst the UC group on how to best implement call blocking/screening on a Sonus Session Border Controller 1000/2000. We proceeded to trial various methods including a well documented ‘Action Set’ scenario, which proved to be unreliable in our implementation. It was from this we looked to a simpler method that I will share with you in this article.

The process to block a call will be to use a Call Route Type with ‘deny’ action as the destination type, rather than the standard process of the destination being a FXS, FXO or SIP signalling group. Sounds simple enough.

The high level tasks are:

  • Create a Transformation Table
  • Create a Call Route Entry
  • Assign the Transformation Table to the Call Route Entry
  • Assign the Call Route Entry to a Route Table

Create a Transformation Table
Create a Transformation Table, this will be populated with either calling or called address that you wish to block based on your scenario. I’ve created a table that will match a known calling address that is to be blocked. The basis of my table logic is if a call is matched set a value to equal 1. Once the call has finished the logic in the table sequence and the value is 1 then a mandatory match is made and the table becomes true/successful.

Update: My good friend Greig and I had a conversation about this table and we agreed that you don’t need this third line entry. I had the third line to make the call logging simple when searching for the specific string for the value 2 ‘Block’. Really I could remove it.

If a Transformation Table only contains multiple entries for a single Input Field Type (e.g. Calling Number above), and all of entries have a Match Type of Optional, then the table is true if any one of the transformations succeed.

Create a Call Route Entry
This step is where the magic happens and I will admit I have never toggled this drop down menu until this process. You can create a call route destination type with a ‘deny’, generally speaking as a voice consultant we are trying to complete calls not stop. Create a Call Route Entry that has the following specific settings:

  • Transformation Table = Block Calls (table from above step)
  • Destination Type = Deny
  • Q.850 Cause Code = 21: Call Rejected

Assign the Transformation Table to a Route Table
Assign the Transformation Table to the Route Table that the call originates from:


The logic of the transformation table is as follows;

  1. The table gets processed for an inbound call session
  2. A Calling Number (tfCallingNumber) field gets matched via regex we have assigned in a line entry
    1. IF TRUE – The output field User Value 1 (tfSGUserValue1) gets updated to the value ‘1’
  3. A mandatory entry of User Value (tfSGUserValue1) equals 1 is matched in a line entry
    1. IF TRUE – The output field User Value 2 (tfUserValue2) is now ‘Block’
  4. Table is successfully matched based on mandatory assignment with User Value 1
  5. Process the session with Route Table Entry ‘Block Calls’
  6. The session will be denied with code 21 Rejected in the session info

Below is a trace of an inbound call session using the LX logging tool (above steps highlighted below)

Line 280: com.sonus.sbc.route.libcommon DEBUG (AFSessionManagementLayer.cpp:650) - SMConnection: Received REQ: id=12:47657/32769/0 session bit=1 moredata bit=0 message=MSG_CR_ROUTE
Line 281: com.sonus.sbc.route INFO (callrouter.cpp:2199) - Handling route request.
Line 282: com.sonus.sbc.route INFO (callrouter.cpp:2278) - Using table From PSTN (2) to route call.
Line 283: com.sonus.sbc.route INFO (callrouter.cpp:2354) - Rule Block Calls (2.1(3)) being tested for selection.
Line 284: com.sonus.sbc.route DEBUG (translation.cpp:1416) - Performing OPTIONAL transformation using entry User Value 0 (9.1(3)).
Line 285: com.sonus.sbc.route DEBUG (translation.cpp:704) - Successful regex match of "tfCallingNumber" field for "(.*)" (updated "(.*)") with input of "411111111"
Line 286: com.sonus.sbc.route DEBUG (translation.cpp:749) - Regex replacement output of "tfSGUserValue1" field is "0"
Line 287: com.sonus.sbc.route DEBUG (translation.cpp:1416) - Performing OPTIONAL transformation using entry Block ID (9.2(1)).
Line 288: com.sonus.sbc.route DEBUG (translation.cpp:704) - Successful regex match of "tfCallingNumber" field for "411111111" (updated "411111111") with input of "411111111"
Line 289: com.sonus.sbc.route DEBUG (translation.cpp:749) - Regex replacement output of "tfUserValue1" field is "1"
Line 290: com.sonus.sbc.route DEBUG (translation.cpp:1416) - Performing OPTIONAL transformation using entry Block ID (9.3(2)).
Line 291: com.sonus.sbc.route DEBUG (translation.cpp:700) - Failed regex match of "tfCallingNumber" field for "881111111" (updated "881111111") with input of "411111111"
Line 292: com.sonus.sbc.route DEBUG (translation.cpp:1416) - Performing MANDATORY transformation using entry User Value 1 True (9.4(4)).
Line 293: com.sonus.sbc.route DEBUG (translation.cpp:704) - Successful regex match of "tfUserValue1" field for "1" (updated "1") with input of "1"
Line 294: com.sonus.sbc.route DEBUG (translation.cpp:749) - Regex replacement output of "tfUserValue2" field is "Block"
Line 295: com.sonus.sbc.route INFO (translation.cpp:1493) - Transformation table(Block Calls:9) is a SUCCESS
Line 296: com.sonus.sbc.route INFO (callrouter.cpp:2412) - Successful route request with entry Block Calls (2.1(3))
Line 297: com.sonus.sbc.route.libcommon DEBUG (AFSessionManagementLayer.cpp:1984) - Sending RSP: state=1 session id=12:47657/32769/0 message=MSG_CR_ROUTE_ACK msg len=557 end session=0 sessions={lvl=1}<parent>0x11000023|0x16721c-[this]0x11013650|0x12f140. Process ID 5912
Line 305: com.sonus.sbc.route.libcommon DEBUG (AFSessionManagementLayer.cpp:1016) - SMConnection (0x167208): Received INFO: session id=12:47657/0/0 message=MSG_CR_CALLREPORT end session=1, moredata=0

Job Done

This is a very simple approach to an annoyance that we all could face at some stage. I’m sure there are many other ways to implement a call scenario like this, but I do enjoy the beauty in this simplicity. By using the standard call route logic of the Sonus we haven’t introduced anything new to the call flow procedure. I’d estimate that a implementation like above would take about 10-15 minutes once you know what you would like to block.

Polycom VVX Phone – Call Transfer Options

During the pilot phase of a Skype for Business Enterprise Voice rollout it is standard practice to get some IP handsets in and do testing on functionality. Its important to try match feature sets between old and new handset functionality to make sure adoption of the new handset is simple.

How did you do it before? Here is how you do it now.

The longest conversation I have with this phase of testing is which transfer type will the business adopt as a default for all phones. There are 3 types of transfer that I like to discuss in Skype for Business;

  1. Blind Transfer – Transfer happens immediately
  2. Consultative Transfer – Transfer happens after a consult with the transferring recipient
  3. Safe Transfer – Returns the call on a blind transfer if the recipient doesn’t answer

The Polycom VVX Business Media phone range is what I prefer to deploy in organisations adopting Skype for Business. Polycom offer flexibility in how you configure the phone. This is done via in-band provisioning process built in by Polycom for a configuration file download. The configuration file allows for a default transfer type to be associated with the transfer soft and hard key in a standard call scenario. Two options are available;


Having a singular transfer type isn’t always optimal, especially when in conversations with workers that do high call volume for a public interfacing number i.e. Receptionist/Admin workers. These users quite often will give me the response when asked the question about which transfer they use in their job pre Skype for Business;

“Sometimes I like blind and other times I like consultative, it all depends on the calling party and how comfortable I feel with the requester in each call”.

This seems like a fair statement but not easily achieved with a VVX phone. I would tend towards default being blind and if the user wanted to do an ad-hoc consultative we would say to put the calling party on hold while you liased with the destination party and stich the call together after. Not perfect. Another method is to create a different configuration file for special cases where the user needed consultative as their default. Once again, not perfect.

My idea was to make soft keys on the ‘in call’ window on the phone for both blind and consultative transfer in my customized configuration file. This is achievable but I never sat down for long enough to pilot the process in its entirety. Older versions of the firmware I believe had consultative as default, during a call you had the option of transferring using the Blind method via a softkey but it wasn’t always on the first page of soft keys. Users wouldn’t always have the time or patience to go find the Blind key on the second page under the ‘more’ button.

But alas, Polycom have come to the rescue with UC 5.3.+ software now available for the VVX range that includes the simplest change in detail of the user guide that got me excited about an addition in functionality. User Guide (Page 46 or below)

To transfer a call:

  1. During a call, do one of the following
    1. Press Transfer to use the default transfer type
    2. Press and hold Transfer and select a transfer type.
  2. Dial a number or choose a contact from the call list or directory.
    1. If the transfer type is set to Blind, the call is transferred immediately.
  3. If the transfer type is set to Consultative, press Transfer after speaking with your contact.

Well there you have it, a very simple method of selecting a transfer method during a call. In some ways almost comical that I never once tried to hold down the transfer key. Now I do it by design. This is definetly something I’ve updated in my ‘how-to’ guides for end users adoption as it was the most common question I get in regards to VVX IP phones.

Federated User – Presence Unknown

Here at Kloud we have just been busy updating our Skype for Business Public Certificate before it expired. Our SAN certificate provided by GoDaddy is used on our Edge Server and Reverse Proxy for all external communication to be encrypted with TLS or HTTPS.

After updating our certificate and restarting services to make the certificate take effect, we started to get some feedback from Kloudies (Kloud Employees) of federated contacts showing up with ‘Presence Unknown’ in their contacts list. These were contacts which they had previously been communicating with prior to the certificate change. The head scratcher was that it wasn’t all federated partner domains.

Here is some of the findings and troubleshooting we performed to get to the resolution of the issue.

First thing to always test is the inbuilt PowerShell cmdlets on your server itself.

Test-CsFederatedPartner -Domain -TargetFqdn kloudedge.kloud.local

Successful domains appear with the following lines:
Target Fqdn   : kloudedge.kloud.local
Result        : Success
Latency       : 00:00:00
Error Message :
Diagnosis     :

While domains that had the issue would have the following output:
ErrorCode=1047,,Reason=Failed to complete TLS negotiation with a federated peer server,fqdn=SIP.Contoso.COM:5061,peer-type=FederatedPartner,winsock-code=10054,ip-address=xx.xx.xx.xx,winsock-info=The peer forced closure of the connection

From the above message we could see that the peer’s (being the federated partner) Access Edge server was actively closing the connection from our server.

But why?? We haven’t done anything wrong….

This can become a hard thing to troubleshoot if you don’t have access or know the SFB administrator at the partner organisation. Lucky for us this isn’t the case for at least one of our troubled SIP domains.

Investigating the Partner Edge Server we did the following:

  1. Start > Run mmc.
  2. File > Add/Remove Snap-in… > Add… > Certificates (Add) > Service Account  > Skype for Business Server Access Edge (Finish) > Close > OK.
  3. In the mmc, navigate to RtcSrv\Accepted Certificates > Certificates.
  4. Look for the certificate named “”

What we found was still a copy of the certificate that had just been expired, but no new certificate with the up to date expiration. We wanted to give this Edge Server a little helping hand and investigate why it would potentially not have added the new certificate into this store. Upon copying the new file to a location on the server and opening the certificate for viewing, we assessed the path of certificate. Bingo! The certificate path was not validated.

The server was missing the GoDaddy Intermediates that are associated with our new certificate. Upon adding the new GoDaddy intermediate certificates to the intermediate store location and restarting the Acess Edge Service to make certificate settings take effect, instant success. The new certificate was downloaded from our Kloud Edge Server into the Accepted Certificates store of this Edge Server whom we were talking with and presence was restored both ways.

So now we have made the assumption of knowing all the federated partners we associate with that don’t patch their Edge Server with Windows Update. I hope I’m not talking about you.

Edge Servers can easily be the servers that you forget to put in a patching cycle due to being in a DMZ restrict zone, also they are workgroup machines so they won’t take the default group policy settings from WSUS. But here is a prime example of how it could have negative impact on your company if you don’t. So the only way to fix the issue is to spread the word. I don’t have access to everyone. Until they read this blog I can’t chat with them online. The moral of the story;

Patch your Edge Server so they can have up to date certificate information or get left behind while the rest of the Skype for Business world keeps moving on


Skype for Business Online to On-Premises Migration

Okay guys – you’ve been told “lets move everyone back from the cloud! We need Enterprise Voice for our users” This will go against most Microsoft sales materials as we should be looking towards cloud.

If you are part of an organisation that has been birthed out of Skype for Business Online (SFBO) as part of your Office 365 subscription, it would make sense that you would have never had on-premises Lync or SFB servers in your Active Directory domain. Very little configuration is needed in SFBO and a busy administrators would have loved enabling the license SKU for SFBO for each users and then wiped their hands of it. Its just that easy, enable and forget.

The main limitation around SFBO is the need for an IP-PBX and/or PSTN connectivity. The time may have come for your organisation to leverage your Microsoft agreement even further and look to your existing technology/application catalogue and see that Skype for Business can fill the requirements of your aging PBX. This trigger point is usually when the PBX asset has reached capacity and there is a cost trade off;

  • Throw more money at the dusty old PBX box for extra expanision cards and possibly cabling to terminal
  • Spend the money to start new in the world of VOIP, but look to an existing technology that can provide this functionality (and hopefully more) before looking elsewhere

Telephones have been around for a long time, its nothing new. Picking up, making, transferring calls is all pretty standard stuff we have been doing for few decades now. If I’m going to invest money in something I should be asking for more! more! more! How do I make sure that my choice keeps my organisation staying relevant in the way it communicates for the next chapter?

Hello Skype for Business as PBX replacement.

That’s enough of ramble. You have come here to understand the process of moving users back from the cloud because there is less documented about this procedure than too the cloud.

Current Environment

  • On-premises Domain Services
  • DirSync/AADSync Server
  • Office 365 Tenant
    • Skype for Business Online SKU enabled
  • DNS for my
    • CNAME
    • CNAME


In this scenario we will look at the steps needed to specifically enable Hybrid and move users back to on-premises.

  1. Add on-premises infrastructure
  2. Connect Hybrid SFB with Office 365 and on-premises
  3. Move Enterprise Voice users back

Add On-premises Infrastructure

  • Add your Front End, Edge and Reverse Proxy Infrastructure
    1. Build the Servers as per TechNet, but leave the SIP Address’s DNS zones to not effect internal and external clients just yet
    2. All discover records should still point to Microsoft (sipdir, webdir etc)
  • Confiure your Edge and Reverse Proxy with Public Certificates
    1. Test the port authentication as best you can;
      1. Telnet to Edge Ports
      2. Test Reverse Proxy URLs
      3. Remote Connectivity Analyzer for Edge
  • Configure Edge for Federation
    1. Assign your Edge as the Federation Route in your Topology Builder
    2. Configure Edge Specific Configuration
Set-CSAccessEdgeConfiguration -AllowOutsideUsers 1 -AllowFederatedUsers 1 -UseDnsSrvRouting -EnablePartnerDiscovery $true
  • Recreate Allowed Federated Domains in On-premises
    1. If you do a get-csalloweddomain in Office 365 you may not get all the correct information specific for your tenant back to you.
      1. If you have federation with only allowed/block lists, you may need to recreate these as there is no nice way of piping the cmdlets from ‘get’ to ‘new’.
      2. Allow open federation to accommodate for all traffic is the simplist approach for migration
  • Set the Global Remote Access and Federation User Policy to Allow
Get-CsExternalAccessPolicy -Identity Global | Set-CsExternalAccessPolicy -EnableFederationAccess $True -EnableOutsideAccess $True


Connect Hybrid Skype for Business

  • Remove existing Lync/Skype for Business Hosting Rule
Get-CSHostingProvider -Identity <SFB/Lync Online> | Remove-CSHostingProvider
  • Recreate the Provider with Hybrid Specific Configuration
New-CSHostingProvider -Identity SFBOnline -ProxyFqdn "" -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl
  • Update External/Public DNS Records
    1. Remember that only updating external DNS records means that your internal users can functions ‘as-is’ until your happy with the progress
      1. Edge Names (SIP Access/Web Conference/ AV  FQDNs)
      2. External Web Services FQDN
      3. Dialin FQDN
      4. Meeting FQDN
      5. LyncDiscover FQDN
      6. SRV
      7. SRV
    2. Remote users that aren’t previously authenticated could have an issue logging in at the time of the change

Test Process

Join On-premises Pilot User with Online Account

This makes your on-premises deployment aware of active directory accounts that are currently cloud enabled.

  • Run the following cmdlet in SFB Management Shell connected to on-premises servers to test a user
Enable-CsUser -Identity &lt;accountname&gt; -SipAddress "sip:<sipaddress>" -HostingProviderProxyFqdn "" -verbose
  • Synchronise AADSync/DirSync
    1. Login to Directory Sync Server
    2. Run >  Delta Import And Delta Sync on the Active Directory Connector
    3. You will see an update count that includes your object

Move a Pilot Users back

This step will actually move the user from SFB Online back to your on-premises pool with contact lists intact. This is initiated from the on-premises server and will need authentication for the Office 365 tenant to perfom the task.

  • Run the following cmdlet in Powershell connected to both on-premises and online sessions
Import-Module LyncOnlineConnector
$credential = Get-Credential
$session = New-CsOnlineSession -Credential $credential
Import-PSSession $session -AllowClobber
  • Get the Online Admin URL for your tenant
    1. Log into Office 365 Portal
    2. Check the URL presented in the address bar, will be admin0x. Where x = a letter specific for you
  • Move the User back
Move-CsUser -Identity <UPN> -Target <FE Pool Name> -Credential $cred -HostedMigrationOverrideURL

Enable All Users

If the above to Pilot Tests worked we need to scale up our migration batches. We need to mass produce the following cmdlet in SFB Management Shell connecting on-premises user accounts to the corresponding online account;

Enable-CsUser -Identity <accountname> -SipAddress "sip:&lt;sipaddress&gt;" -HostingProviderProxyFqdn "" -verbose

To do this practically I used the UPN value which I knew that would resolve to the correct users values in on-premises and Office 365 because they are synced from the source. I also could then understand the logic that the users UPN is in this case the primary SMTP/Mail value and therefor matching SIP Address for Skype for Business that I needed.

  • Get all the Office 365 users that are enabled for Skype for Business
Get-CSOnlineUser | ? {$_.SipAddress -notlike $Null} | Select SipAddress, DisplayName | Export-CSV -Path C:\temp\OnlineUsers.csv -NoTypeInformation
  1. This will give you a list of ‘real’ SFBO users that are licensed but are also registered SFB logins
  2. Review the list for deleted users that haven’t been removed properly, there SIPAddress will include GUID style login, these lines can be removed as we do not wish to migrate them.

Lets leverage this list of known online users and enable their joining in on-premises with a ForEach loop example below;

$Users = Import-Csv C:\updates\OnlineUsers.csv

ForEach($User in $Users)
$SipAddress = $user.sipaddress
$UPN = $SipAddress.replace("sip:", "")
$Enable = Enable-CsUser -Identity $UPN -SipAddress $SipAddress -HostingProviderProxyFqdn ""
  • Update Azure Active Directory of the changes by another AADSync/DirSync > Delta Import & Delta Sync
  • Update Internal DNS to point all associated SFB records to on-premises Skype for Business Server(s)
    1. SRV
  • Add Additional A Records
    3. Pool Name
    4. SFB Web Service URL Names
    5. Admin URL

Visual Indication of Success

Log into your on-premises SFB Admin Control Panel and run a blank user search to discover all users. Noticed the ‘Homed’ field should say ‘SFBOnline’ 

Move All Users

Leveraging the same list of users, run the move cmdlet like the example;

ForEach($User in $Users)

$Displname = $user.displayname
$SipAddress = $user.sipaddress
$UPN = $SipAddress.replace("sip:", "")
$Move = Move-CsUser -Identity $UPN -Target &amp;amp;amp;amp;amp;amp;lt;FE Pool Name&amp;amp;amp;amp;amp;amp;gt; -Credential $credential -HostedMigrationOverrideURL -Confirm:$false
if($Move -eq $False)
Write-host "User $SipAddress didn't move!!"


To get visual status while you move all the users, log into your Office 365 Skype for Business Administration Portal and view the details. Continually refresh the page to see the value for “users synced and homed online” go down as each user becomes enabled on-premises.





Log into your on-premises SFB Admin Control Panel and run a blank user search with a additional filter for Homed or Registrar Pool / is equal to / <registrar server name>.

Client Experience

The client should be unknowning of your changes being made in Office 365 and on-premises until you perform the move-csuser request for their account. During this period a redirect message will be sent to the client with a new registrar server FQDN and a automated logout and login will happen. If the user doesn’t have their client in the forground of their desktop, then this will happen silently in the background. The redirect in my move request had the users logged out and back in within about 1-2 seconds.

Skype for Business External Authentication

Microsoft Lync/Skype for Business has revolutionised the way people can communicate and collaborate in the workplace. With light weight and portable form factors coming into their own, devices have enabled businesses to rethink their communication strategy. Lync not only enables users to communicate using great device form factors, but also from wherever they may be located. The sense of a roaming lync identity brings freedom to how people choose to collaborate and office spaces, desks and name tags mounted above them, seem like a necessity of the past. The enablement of remote connectivity across these devices is pivotal in a Lync deployment, but sometimes isn’t entirely understood. In some circumstances security is of high concern for all forms of connectivity that can be done over the public internet, but you wouldn’t want to go without it. To remove remote access for users would be crippling the UC strategy that you were trying to put in place.

When we think about Lync/SFB with external authentication we first must articulate that there’s more than one form of authentication a user can attempt and there is many device types they can attempt authentication with. Therefore it can also be said that there is more than one endpoint and port on the edge of the corporate network listening, waiting and proxying these forms of authentication. What we need to do is make sure that each case is in a controlled and known measure to best suit your deployment.

Question: “So Arran what is secure?”

Answer: “Well the security policy should govern what is and isn’t classified as secure for you.”

The common device(s) attempting authentication are:

  1. Lync Office Client
  2. Mobile/Tablet app
  3. Windows 8 Store App

With these authentication types:

  1. NTLM
  2. TLS-DSK
  3. Passive (ADFS)

We aren’t going to talk about Kerberos cause we are concerned with external logins.


NTLM is usually well understood as a simple challenge/response authentication but if we look at it in Lync it means that every time a web ticket expires the same challenge authentication must be presented. Usually to make this simple to the end-user we allow them to cache/save the password to the device for re-authentication on our behalf.




NTLM will generally be a big ‘NO’ straight away if these conversations have started with a security team, so let’s look at Transport Layer Security Derived Session Key (TLS-DSK) as a certificate based authentication. Every Lync Front End Server is issuing a Lync User Certificate upon initial successful authentication and once the certificate is saved, the stored AD Credentials aren’t needed for the validity of the certificate which can range from 8 hours to 365 days (your choice). A key point to make about TLS-DSK is that if I have multiple devices I will receive my certificate for each. I will then use my certificate on each device to authenticate to Lync as me. Additionally the certificate I have stored is only trusted by Lync, not my entire domain or ADFS and can’t be used across other application or services.


TLS-DSK allows us to move away from the simple challenge authentication and subsequent re-authentications all together.

TLS-DSK is great!


By disabling NTLM on external registration (shown in the diagram above with Green – Internal and Blue -External) we can then understand that a client has to have obtained a Lync certificate from the internal Front End Servers when on-premises and not provisioned through an Edge proxy. The certificate can NOT be issued from external locations due to the authentication process breaking when the client requests a web ticket to start the process. Currently Skype for Business does not do this natively. The client NTLM authentication against the web services is via the Simple URLs which is controlled via a Reverse Proxy. Currently there are only a few out the box solutions for this, Lync Solutions and Skype Shield are worth investigating.

If you go the extra mile to not allow NTLM authentication from your external network, you are then protected via additional forms of on-premises security;

  • The individual has gotten physical access to a site location through a perimeter locked entrance
  • The individual has gotten network layer 2 connectivity with a device on a access switch
  • The individual has an approved domain joined computer to gain access to domain services on the appropriate VLAN
  • The individual has supplied correct credentials of a provisioned Lync user account.

Sounds like a job for Tom Cruise hanging from the roof if you ask me. The end result is a Lync user certificate in the user store of the trusted machine. We should now be happy for the user to go out in the world with this device knowing that themselves and the managed device are who we think.


What if you would NOT like Lync to do any authentication.

“I have a centralised authentication services called Active Directory Federation Services (ADFS) and I would like to use it with Lync”.

Lync can be integrated with ADFS as your Secure Token Service (STS) and also provide a second factor if needed. You can then leverage forms based authentication or smart cards. There are a few tricks to enabling Lync Server with passive authentication, first of all to enable passive we must disable all other forms of authentication. As this is a ‘big bang’ approach to effectively disable all other authentication protocols per pool make sure you plan and test appropriately.


Lync Mobile Clients

Lync is a free download in each of the mobile stores and we can’t control if a trusted or untrusted device downloads it. So for our external access of the Lync 2013 mobile client we must feel comfortable with the authentication, which comes in the 3 forms that are available;

  • NTLM
  • Lync Certificate
  • Passive

NTLM once again maybe too basic to meet our requirements and we need to look at what else is on offer, James Frost has a great comment at the bottom of this post about products that can be used. As James points out that the certificate web service URL is exposed to the internet via the reverse proxy you are using. Depending on what type of device you are using will indicate what might be possible for you to achieve with validation of approved devices or authentication attempts. The reverse proxy is breaking the connection from front to backend and this is a perfect time to inspect it if necessary. ADFS can be a big leap just to comply with remote authentication with the Lync app, instead we can protect our users and devices via whipping the initial NTLM credentials from the devices disk and memory via PowerShell mobility in band provisioning policy;

Set-CsMobilityPolicy -AllowSaveCredentials <$true/$false>

We can also disable EWS requests which does simple NTLM requests to exchange inside the app also;

Set-CsMobilityPolicy - AllowExchangeConnectivity <$true/$false>

Where does the authentication happen?

When I stated that there is “more than one endpoint on the edge of the corporate network, waiting and proxying these forms of authentication” this is because clients behave differently. Lync Office Client directs its authentication requests to the Lync Edge servers with SIP over TLS, while all mobile device apps will use a reverse proxy that has a published URL rule as all its signalling traffic is SIP over HTTPS while on a 3G/4G data network. So there is more then one ingress point for authentication to monitor. The Edge Server is inspecting all packets, while a Reverse Proxy can inspect the HTTPS traffics as it’s also splitting the traffic from frontend to backend.

Lync External Auth Flow


Options are available to change the way Lync can authenticate to your network. A greater understanding of the authentication endpoints, protocols and flows will aid you in being on top of your environment and smoothly rolling out external devices that are secure and trusted.