Control how Skype for Business users join meetings

Had an interesting request lately, where a company wanted to control how users join meetings when they click the “Join” on their Skype for Business clients’ calendar tab or when they join Skype for Business meetings from Outlook.

In the client’s options, we have the ability to choose what happens when we join meetings; We can join immediately using the Skype for Business client or choose from four different phone numbers, all of which must be populated in our contact card, and can be seen under Tools -> Options -> Phones.
If your AD is configured right, you should have your Work phone (ideally your Skype for Business line URI), your Mobile phone, your Home phone and maybe even an additional ‘other’ phone.
You can also manually add phone numbers if they’re not automatically updated from AD.

Now if you scroll down the tabs to “Skype Meetings”, this is where all the fun begins:

In the tab above you can choose any of the numbers you have in the ‘Phones’ tab and get to choose whether you’d like to be prompted at the beginning of each meeting which device you’d like to use, or just go with what you chose.

How do you control it?

Like most things, the Registry.
You can make changes to the user’s preferences but not grey-out the options. If the users want to bypass the setting they can, but they’ll be defaulted to your setting at logon.

First, decide if you want the user to be prompted with each call. If yes, we need to tick the “Before I join meetings, ask me which audio device I want to use”.

The registry setting fro this checkbox is located at

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Lync

The key is

AllowOverridingDeviceAtJoinTime

If it’s set to 1 – it means the box is ticked and the user will be prompted to choose which device they’d like to join the meeting from.
If it’s set to 0 – it means the box is unticked, and the user will automatically join via the configured device.

Choosing a device is the next funny setting:
Same registry location as above, look for the following key:

JoinAudioConferenceFrom

The setting of the last binary bit is as follows, as reflected in the users’ “Phones” tab:

0 – Do not join Audio.
1 – The Skype for Business client.
2 – Work Phone (If different from your Skype for Business line uri).
3 – Mobile.
4 – Home.
5 – Other.

If one of the above is not configured or missing, the client will default to “Do not join Audio”.

For example, if I want to set my users to join from their mobile phones without being prompted, I’ll set the AllowOverridingDeviceAtJoinTime registry key to 0 and the JoinAudioConferenceFrom key to 3.

“The odd call drops” of the Mediation Server

I had a very annoying issue lately when an installation of a new gateway resolved in some calls (specifically to US numbers) dropped by the Skype for Business mediation server saying “A call to a PSTN number failed due to non availability of gateways.”

The cause, according to the mediation server, was that “All gateways available for this call are marked as down“, and the resolution, surprisingly, was to “Verify that these gateways are up and can respond to calls.”

It seemed funny, because all other calls were successful, I have not exhausted the available PRI channels I had, the gateway didn’t seem to lose connectivity for a split second and SIP options are accepted and replied to on both ends.

Looking further at the Lync Monitoring Reports, I noticed the following:

Reported by Client
12000; reason=”Routes available for this request but no available gateway at this point”

Reported by Server
12000; reason=”Routes available for this request but no available gateway at this point”

I went to the gateway (AudioCodes M1000B) for answers and the logs were showing something very weird;

Every call starts with the same flow:

The mediation server sends a SIP Invite that will normally be answered immediately by the gateway with a “100 Trying”. This, for me, will close the deal on the “Gateway no responding” – this is a great response if you ask me.
The next phase would be the gateway immediately sending a “PSTN Place call” to the PSTN, hopefully receiving a “Proceeding” instantly from the PSTN, meaning so far we’re fully communicating. So for the time being I’m not really buying what the Lync mediation server is selling.

Looking further at the logs, I see the following strange behaviour:
As I’m still waiting for the PSTN to connect the call (this would normally be a “PSTN Call Alerting” message), I see that the mediation server decided to abandon ship!
This is what I see in the logs:

Within 10 seconds after initiating the call, the mediation server will send a “Cancel” request to the gateway and will terminate the call:

19:25:49.640 [S=660986] [SID:1327438938] INVITE sip:+353857560598@10.10.10.1;user=phone SIP/2.0 
19:25:49.729 [S=661027] [SID:1327438938] SIP/2.0 100 Trying 
19:25:49.730 [S=661035] [SID:1327438938] (   lgr_psbrdif)(    656225)   pstn send --> PlaceCall
19:25:50.087 [S=661039] [SID:1327438479] (   lgr_psbrdex)(    656229)   pstn recv <-- CALL_PROCEEDING
19:25:59.020 [S=661055] [SID:1327438938] CANCEL sip:+353857560598@10.10.10.1;user=phone SIP/2.0 
19:25:59.052 [S=661061] [SID:1327438938] SIP/2.0 200 OK 
19:25:59.058 [S=661065] [SID:1327438938] SIP/2.0 487 Request Terminated 
19:25:59.079 [S=661074] [SID:1327438938] (   lgr_psbrdif)(    656265)   pstn send --> PSTNDisconnectCall

Clearly, the gateway is available and responding, but the mediation server is somewhat impatient.

Doing a bit of digging around, it appears there’s a setting for this.

The Lync mediation server is expecting a “SIP 180 Ringing” within 10 seconds of initiating the call. Failing to provide that (183 “Session in Progress” can be pushed here but that won’t benefit you if you’re still waiting for that ring…) will cause the mediation server to decide that the call didn’t respond and to mark the gateway as unavailable. A little too harsh? In my opinion yes. This will generate errors (2 per failed call) on your Lync servers and is actually a Lync self-inflicted error.

To work around this issue you can go to:
<Lync or Skype for Business installation folder\Server\Core
and look for a file called “OutboundRouting.exe.config“.
When you open that file, the first configuration line is:
<add key=”FailOverTimeout” value=”10000″/>
This actually determines how long should a call wait for the gateway until it declares it “Offline”. the value is in milliseconds, meaning the default setting is 10 seconds.

This will impact your environment if you have two or more gateways, and it means that it’ll take the mediation servers more than 10 seconds to declare that gateway as offline if it actually fails.

For me to workaround that issue I extended the wait time to 20 seconds, restarted the front-end and mediation services, and all of a sudden no call was dropped.

It appears it took the carrier approx. 12 seconds to generate the “PSTN Call Alerting” command to the gateway. For some reason, only calls to the US (and only with this specific carrier) were affected by this issue.

Now, I can see all my calls working perfectly and the errors have disappeared from the serves too.

Irish Public Holidays 2016 set for Skype for Business Server

New year, new holiday set.

This updated script will add all 2016 public holidays (and 2017 new years day) to your Skype for Business Server \ Lync 2013 Server environment as a holiday set.

Holidays in this script:

St. Patrick’s day.
Easter Monday.
Bank holidays for May, June, August, October.
Christmas day.
St. Stephen’s Day.
New years day 2017.

This will then become an option to tick on your response group workflows:

The script can be downloaded here.

Skype for Business for Windows Phone updated

The Skype for Business client for Windows Phone received an update last night.

No major changes or additions (as far as I can see).
No changelog for the app at the Windows Store.

App version is now 6.3.1551.0

Skype for Business VCFG Viewer

When preparing documentation for a customer or trying to survey an existing deployment, I usually ask for a copy of the Voice Configuration files (.vcfg) of Lync \ Skype for Business to see how things are set up.

Currently there’s no option to view the vcfg file in a readable format.
Sure, you can open the vcfg file in a text editor or even a web browser and browse through the xml. Alternatively, you can import the configuration to your servers – but good luck trying to read it between the “Committed” and “Uncommitted” text.

The vcfg viewer is a “PowerShell executable” that runs through the vcfg file and renders it to a readable html file.
Simply run the ps1 file, choose the vcfg file you wish to open, and you’ll have a browse able page to examine the vcfg file:

Download the ps1 file here.

November 2015 update for Skype for Business and Lync 2013

Microsoft released an update for Skype for Business and Lync 2013.

The update resolves vulnerabilities in Microsoft Lync 2013 and Skype for Business as described in Microsoft Security Bulletin MS15-116 and Microsoft Security Bulletin MS15-123.

This security update also fixes the following issues:

Note that this update will upgrade your Lync 2013 client to Skype for Business.

*** The download link was removed by MS – I will update as soon as it’s available.

*** Update is available again.

Download (32-bit)

Download (64-bit)

Source: Microsoft

Exchange UM and SDP 180\183

So, had a pretty funny (well, it started funny…) discovery a couple of weeks back:

I have a pretty simple environment that looks pretty much like this:

There’s a Lync 2013 pool.
There’s an Exchange 2010 UM server.
There’s an old QSIG PBX.
There’s an AudioCodes M1000 SBC to connect the above.

Users on Lync can dial users on the old PBX and vice versa via the AudioCodes SBC, voicemail works for users on both platforms; Lync and Exchange communicate directly over TLS, the old PBX and Exchange are communicating via the AudioCodes SBC over TCP, messages can be heard on the Outlook clients for both platforms, but one (apparently) critical feature is missing:
When users on the old PBX hit the “Play on Phone” button on their Outlook client to play their voicemail on their handset, the call rings, but we can’t hear any audio.
It works perfectly for Lync users, but users on the PBX’s UM dial plan can’t play their messages on the phones.

I immediately blames the SBC as there was no reason why any other call would connect, except for calls originating at the Exchange UM server.

Traces showed the following:

The gateway is doing everything you’d ask it to do, everything looks ok, but still, no audio could be heard.

Next I went to the Exchange UM server. Using Wireshark, I traced a one of the calls from the Exchange UM server to the user’s handset.
Using the Wireshark’s VoIP Calls player, I could actually hear myself speaking on the handset, but there was nothing playing on the Exchange side.

Took me some time and some assistance from the nice guys at Microsoft to discover the following:

There’s a UCMA design limitation, where SDP can only be sent in 183 and in 200 OK.
If the “180 Ringing” contains SDP, UCMA will freak out.
My SBC was sending two provisional responses with SDP – 183 with SDP and 180 with SDP, before sending the 200 OK with SDP.
Apparently, we could send only 183 with SDP or 180 with SDP.
Sending both would cause the UCMA to get stuck and not initiate the Audio channel.

Who would have thought!

Once we suppressed the 183 packet, Exchange UM immediately started playing audio.

Exchange UM and SDP 180\183

So, had a pretty funny (well, it started funny…) discovery a couple of weeks back:

I have a pretty simple environment that looks pretty much like this:

There’s a Lync 2013 pool.
There’s an Exchange 2010 UM server.
There’s an old QSIG PBX.
There’s an AudioCodes M1000 SBC to connect the above.

I immediately blames the SBC as there was no reason why any other call would connect, except for calls originating at the Exchange UM server.

Traces showed the following:

The gateway is doing everything you’d ask it to do, everything looks ok, but still, no audio could be heard.

Took me some time and some assistance from the nice guys at Microsoft to discover the following:

Who would have thought!

Once we suppressed the 183 packet, Exchange UM immediately started playing audio.

Skype for Business Response Groups Diagrams

This is something I was looking for every time I had a deployment with multiple Response Groups.

Customers and management would usually like to see a graphic chart of how the Response Groups’ workflows work, what are the timeout and over flow options, what’s the chosen routing method for each group, and who are the users in each group.

Looking at Matt Landis‘ great Get-csRgsWorkflowDiagram script, I was inspired (and in need) to do something similar.

Took a while to get it where I wanted, but the version published here now is one I’m very happy about and it actually gives me everything I was looking for.

It’s actually two files;

One file is the script that you should run from your PC.
The second file is a custom Visio stencil (.vss file) that will be downloaded to your “My Shapes” folder (That’s always in your “My Documents” folder after you install Visio) and will provide the Visio images for the script. You can find it here if you wish to download it to your machine beforehand.
The script will detect proxy\download issues and will prompt you to download the VSS file manually if required.

Prerequisites

Run this script from your workstation – not from the server. It doesn’t matter if your workstation is in the domain or not.
You’ll need an installation of Visio on that machine.
PowerShell 3.0 is a must.
ADDS RSAT is required if you’re sing Active Directory Distribution Groups for some of your Response Groups’ groups. We’re using the AD PowerShell Module to expand these groups and list their users.
Your Lync\S4B pool’s FQDN and administrator credentials.
Your Execution policy set to Bypass, at least until I start signing my scripts…

Running the script

From PowerShell, run the file, it will immediately prompt you for your Pool’s FQDN:

Enter your pool’s name and you’ll be prompted for credentials:

The script will generate a list of all your Response Groups. Pick up a Response Group nunmber from the list, or hit 0 for all Response Groups. Each workflow will be drawn in a new page:

If required, it will download the Visio stencil and place it in your “My Shapes” folder:

The script will start drawing the diagram in the background:

Upon completion, the script will auto-save the file to your My Documents folder:

The file is saved with the workflow’s name and the creation date:

And is ready to be opened:

For multiple Response Groups you’ll have multiple pages, each with the Workflow’s name.

Diagrams are scaled to fit the pages, but might be larger due to large number of agents in a group.

Known Issues

This script was tested in English, you might experience some issues if you’re running Visio under a different language.
Windows 10 OS build 10565 can’t install ADDS RSAT – the script will not expand Distribution Groups.

Download

Please download the script here.

Skype for Business Online updates

Announced today, Microsoft is expanding some Skype for Business Online services and offering new ones;

PSTN Conferencing preview will now be available to customers in the following countries:

Belgium
Canada
Denmark
France
Germany
Italy
Netherlands
Spain
Sweden
Switzerland
United Kingdom

Finland, Norway and South Africa will be able to use this feature in November.

Cloud PBX Preview now available worldwide, allowing customers to get rid of separate PBXs globally and still break out locally. This is option still requires an om-premises S4B server installation.

Polycom CX is not dead yet – Skype for Business customers can use Polycom CX600 and CX3000, HP 4120, and Mitel Mivoice 6725 to connect to the cloud directly. Polycom VVX series Can be used as well.

source and more details: Microsoft.