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.
Surface Hub takes advantage of all the automatic configuration options Microsoft’s Productivity tools has to offer; it will use Exchange’s autodiscover to find the Room Mailbox’s account and policies, and will use Skype for Business’ Lyncdiscover to locate the Conference Room’s registrar.
Due to the nature of Surface Hub’s OS (Windows 10 Team Edition), and due to the fact that it’s a locked-down, secured, communal device, it will not show you any popups during the step-by-step configuration (OOBE) or later when it attempts to connect to services and servers. This makes the environment preparation task even more critical: When installing them, Surface Hubs can be configured individually by the installer if they have the required information, or using a PPKG file for mass deployments. In any case, having all the required information is crucial – as the installation will not complete if it hits an issue along the way.
One of the most common issues with Surface Hub installation and Skype for Business is the Trusted Domain List.
What is the Trusted Domain List and how to get it right?
The Trusted Domain List, also referred to as the “TrustModelData” is a List of the trusted domains that don’t match the prefix of the your SIP domain.
When a user (or a device, in this case) connects to the Skype for Business server, the client validates the connections against a list of trusted servers.
Who are the trusted servers?
The users’ SIP URI domain
Any server that the client connected to in the past, and that was added to the Trusted Domain List (More on this below)
The domain of the server that the client last connected to
Let’s break these down:
Scenario 1 is pretty straight forward; if the users’ SIP URI domain and the servers’ domain are the same, there’s an automated trust and the client will sign in immediately.
User’s SIP URI
Alan@contoso.com
Server’s FQDN
SfBFE01.contoso.com
Scenario 2 is where the users’ SIP URI is different than the servers’ domain (due to internal naming convention – for example: domain.local, or due to users\resource forests, etc.)
User’s SIP URI
Alan@contoso.com
Server’s FQDN
SfBSVR.01.Resource.contoso.local
In this case, the Trusted Domain List can be prepopulated by the admin via GPO or manually configuring Registry keys, and also by the user:
Every time the client connects to a new server – an untrusted server – the user will receive a prompt saying “Skype for Business cannot verify that the server is trusted for your sign-in address. Sign in Anyway?”
Once the user clicks Connect, the server is added temporarily (See Scenario 3) to the Trusted Domain List. If the user will go ahead and check the “Always trust this server” box, the server will be added to the Trusted Domain List and the warning will never appear again.
Scenario 3 is what’s happening when the user connects to an untrusted server and acknowledges the ‘Sign in Anyway?’ popup. The server we’re connected to is saved in the registry and will remain there until the user connects to a new server. As long as the server is there, the user will not be prompted to trust the server:
For most workstations, the Trusted Domain List will be pushed via using Skype for Business Server 2015 in-band provisioning, but it can also be pushed using Registry keys or GPO.
What does this have to do with Surface Hub?
Surface Hub will not prompt you to ‘trust a server’ if its not on the Trusted Domain List. Instead, you’ll have to make sure that all possible domain names are represented in Surface Hub. Otherwise, the Skype for Business client will not connect:
However, other features, like Emailing the whiteboard, will work, as Exchange doesn’t require a Trusted Domain List:
The Trusted Domain List on the Surface Hub can be edited in one of the following ways:
Add the domain name in the “Configure domain name” window , under Settings -> Surface Hub -> Calling and Audio
Using the Windows Configuration Designer, perpare a PPKG file that contains the domain name under RuntimeSettings/WindowsTeamSettings/SkypeForBusiness/DomainName
Using Microsoft Intune, crate a new custom configuration policy for Windows 10 Desktop and add the following OMA URI:
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
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.
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.
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.
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|ftIdentity,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:
Make sure you replaced “<PolicyName>” with your actual policy and then run the
“Get-CsClientPolicy|ftIdentity,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.
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.
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… 🙂
