Add Surface Hub and SRS Rooms to Microsoft Teams Meetings

(Or any room, as a matter of fact)

If you’re using Outlook and have the Teams Meeting add-on, you can schedule a Teams meeting and add a room to the meeting:

But if you try to schedule a meeting from Teams and look for a room to find its availability, you might face a challenge as Teams would not show any rooms:

Looking at the glass half full, this is a great opportunity to make some order in how users book rooms with Teams:

Teams takes advantage of Exchange’s New-DistributionGroup cmdlet -RoomList switch. The RoomList switch specifies that all members of a specific distribution group are room mailboxes.

You can create as many distribution groups as you need – based on any parameter that you want. In my scenario, I chose to create two lists:

One for rooms equipped with Surface Hubs
One for rooms equipped with Skype Room Systems.

This way my users will know which collaboration devices are available for them when they book a room.

Creation process of the distribution groups is easy.

Connect to Exchange Online:

$365Cred = Get-Credential $365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $365Cred -Authentication Basic –AllowRedirection $ImportResults = Import-PSSession $365Session

Create the new distributiobn groups with the -RoomList switch:

New-DistributionGroup -Name “Surface Hubs” -Roomlist

Add rooms to the distribution groups:

Add-DistributionGroupMember -Identity “Surface Hubs” -Member “SurfaceHub01"

Log back into your Teams client and see the new lists:

Choose the available room from the list:

And you’re all done:

The room is now booked. If you’re using a Surface Hub or a Skype Room System the meeting will be displayed on the device.

This post was originally posted on my TechNet blog: https://aka.ms/y0av.

Surface Hub and the Skype for Business Trusted Domain List

Check out the post I wrote on my Microsoft TechNet blog:

https://blogs.technet.microsoft.com/y0av/2017/10/25/95/

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.

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

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

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 Users’ pictures from URLs

This was out first on the November 2013 update for Lync Server 2013 where Microsoft brought back the (not so) loved Lync 2010 feature feature of allowing users to set their Lync pictures to internet accessible photos.
Soon, all users in the organization were superheroes and Sports Illustrated models.

Users that were not enabled for this feature will only see the following when trying to change their photo:

A short command will add this feature to any policy that you had at the time and you could later control this with the Set-CsClientPolicy -DisplayPhoto, specifying “NoPhoto”,
“PhotosFromADOnly”, or “AllPhotos”

Now, what happens if you have a new client policy that requires this feature? (Or you never enabled it before?)

First, find out which policies are enabled with this feature by running the following:

Get-CsClientPolicy | ft Identity,PolicyEntry

The result should be similar to this:

unless this was never enabled in your environment, then all of the above should be empty with only “{}”.

Now choose the policy you want to assign this feature to and run the following command:

$NPE=New-CsClientPolicyEntry -Name EnablePresencePhotoOptions -Value True

$Policy=Get-CsClientPolicy -Identity <PolicyName>

$Policy.PolicyEntry.Add($NPE)

Set-CsClientPolicy -Instance $Policy

Make sure you replaced “<PolicyName>” with your actual policy and then run the
“Get-CsClientPolicy | ft Identity,PolicyEntry” command again.
The output will now show you have that set for the policy you chose:

And the Client can now change their profile photo:

Remember there’s still a restriction on picture sizes (30 KB Max) and they must be publically available.

Skype for Business Server Response Groups Migration Gotcha

Noticed something weird during a recent upgrade to from Lync Server 2013 to a new Skype for Business Server pool.

I was double-checking my self against Greig Sheridan‘s very detailed guide and as expected, everything worked just fine.
We tested and confirmed that calls are coming through and the response groups are all working as expected – that was easy.

The next week I’m getting a phone call saying the Response Groups’ managers can’t change some of the settings they used to be able to.
Checking AD permissions – OK.
Opening the Workflow – I can’t see the managers and the workflow is set to “Unmanaged”.

I thought it was just a misconfiguration but then I checked the “Get-CsRgsWorkflow” export we did earlier (Never underestimate documenting!) and all workflows that were set to “Managed: True” are now set to “Managed: False“.

I thought it was a bug, but no – it’s by design. I couldn’t see it in the migration documents (nor thought I should look for it!) but the Microsoft planning document for Skype for Business Server 2015 states very ~~clearly~~ vaguely that “When you migrate response groups from a prior version to Skype for Business Server, the type is set to Unmanaged.”
Here, check for yourself.

I’m not sure if this is the behaviour when performing an in-place upgrade to Skype for Business, but assuming it is.

Reset \ Fix Skype for Business and Lync accounts …And a bonus!

Every now and then I run into one account that has something weird about it. Usually it would display an old phone number even when you changed the phone number in AD, ran Update-CsAddressBook and deleted all old records you had.
However, when looking at the user’s contact card you’ll still see the old number AND the new number, resulting in users dialling the wrong number, resulting in call failures, resulting in service desk calls, do I need to go further…?

I read various workaround involving running various scripts against the RTC database, and to be honest – there are some thing I’d rather not touch.

Workaround for the “corrupted” users would normally be disabling them and then re-enabling the for Skype for Business \ Lync.
This will do the trick, BUT has a huge downside: if you didn’t export the users’ data they’ll lose all of their groups, favourites, contacts, etc. Also, you’ll have to re-apply the user’s policies, line URI, private numbers, etc.
This is both time consuming and would require to schedule a maintenance window as the user is going to be kicked out.

So, came up with the following script:

You’ll provide the user’s sip address.
The system will confirm the user’s name so you’re happy to move on.
The user’s data will be exported to a folder on your local C drive (Path is always C:\y0av\users\<username>)
The user’s Get-CsUser data will be exported to a text file in the same folder so you can compare the settings once you’re done.
The user will be disabled, and the script will run Update-CsUserDatabase and pause for 15 seconds.
The user will then be enabled and the script will pause for another 15 seconds. The purpose of the pauses is to allow for the changes to set in. I tested various environments and 30 seconds seems like enough time. I’ll add the option to change the pause in future versions.
The user’s polices will be re-applied.
The system will run Update-CsUserDatabase and Update-CsAddressBook to reflect the changes.
The user’s data dump is saved in the C:\y0av\users folder, and you can manually delete it if you feel you no longer need it.

What’s missing?

If the user is configured with a Private Line you’ll have to use the script with the -PrivateLine switch.
PIN must be reset for the user after the account is recreated.
Conference ID will change – any recurring Skype for Business \ Lync meetings must be re-sent.

What’s the bonus?

All the tests I made show that the script runs fast enough to not interfere with the user’s activity; I ran this against a user during a call, the script completed and the call never disconnected.
Try this on a test account before killing someone’s call in your organization… 🙂

______________________________________________________________________________

Policies this script will save and re-apply:

Hosted Voicemail (True or False)
Archiving Policy
CallViaWork Policy
Client Policy
ClientVersion Policy
Conferencing Policy
External Access Policy
Hosted Voicemail Policy
Location Policy
Mobility Policy
Persistent Chat Policy
Pin Policy
Presence Policy
Third Party Video System Policy
User Services Policy
Voice Policy
Voice Routing Policy

To run the script for a user with a private line, run:

S4BUserRepair.ps1 -PrivateLine

Download the script here.

Skype for Business conferencing disclaimer

This isn’t a new feature, but one I was recently asked about so I thought it’s worth mentioning again.

When we’re sending a Skype for Business meeting invite (either as a planned meeting via Outlook or as an ad-hoc meeting) we can configure the server to send a meeting disclaimer to all meetings (unfortunately this can only be set at a global level and will affect all of your meetings) to confirm the users joining the meeting have agreed to the T&Cs of the meeting and ticked a box to accept them and join the meeting.

The experience is pretty much identical across all platforms:

Skype for Business client: