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.

Understanding: Lync client Configuration Information

We use many tools to troubleshoot Lync.

the “Lync Configuration Information” option on the Lync client actually provides a lot of useful information about how the client connects to the server and can help identifying issues.

To access the Lync client’s configuration information, go to your computer’s Notification area and look for the Lync icon:

Hit Ctrl and right-click the Lync icon, then choose “Configuration information”:

A new window will open up, showing you your client’s configuration:

This Windows will provide you with all the information your client is retrieving from the server and from your settings.
You can copy the contents of this windows to a text editor by clicking “Copy”, or close it by hitting “Close”.
“Refresh”, however, will surprise you and do nothing. If you want to refresh the information displayed in this window you’ll have to close and reopen it…

Let’s cover this Windows’s contents line by line. Note you might not have all the information populated. This might depend on your actual implementation or connection state:

DG URL Internal	Lync Server 2013 will populate the Lync address book with all the Distribution Groups it finds in your Environment. If in the organization’s network, your client will use this URL to connect to the server and expand these groups to show theirs members. This should normally point to the address of your Front-end pool or server.
DG URL External	Same as DG URL Internal, only for external users. Your client will use this URL to connect to the server and expand these groups to show their members when you’re connected to Lync from outside of your organization’s network. This should normally point to the address of your Reverse-Proxy server, representing Lync’s External base URL.
Quality Metrics URI	This should represent the address of the Front-end server you’re connected to. The Front-end server will in turn use the MSMQ feature to send your quality metrics to the Monitoring Server. If this field is populated, it means you have monitoring enabled for the pool you’re connected to.
ABS Server Internal URL	If configured to download the Lync address book via web service, your client will use this url when connected inside the oraniztion’s network.
ABS Server External URL	Your client will use this url to download the Lync address book when connected outsidde of the oraniztion’s network.
Voice mail URI	This string shows how other clients and services are calling your voicemail.
Exum URL	This field represents how calls are routed to your mailbox. It would normally show a familiar dial plan’s name or just say “destination=default”. Having this fileld populated usually means you’re enabled for Voice mail.
MRAS Server	MRAS stands for “Media Relay Authetication Service”. This service provides your credentials to the AV Edge Server. when this field is populated, it means you successfuly authenicted against the AV Edge server.
GAL Status	This field shows which server was used to download the address book and if it was successful.
Focus Factory	The “Focus Factory” is where all your conferences are created. The server will use the URI listed in this field when you create a new conference or Lync Meeting.
Line	This shows your line URI.
Line Configured From	“Line configured from” shows where the line was configured. In this case, the line was configured on the server.
Location Profile	This setting is actually pulled from your Exchange server, and represents the location profile of your Exchnage UM Dial plan.
Call Park Server URI	If you enabled Call Parking for this environment, your call park server URI will be displayed here.
Server Address Internal	If you configured your Lync client to use a manually entered internal address (see This post), the configuration will be displayed here. Note that even if you switched to automatic configuration but haven’t cleared the names, it will still be displayed here.
Server Address External	Same as Server Address Internal, but for external access addresses.
Server SIP URI	Denotes the SIP uri that’s signed against the server.
Exum Enabled	will say “TRUE” if you’re enabled for Exchange UM or “FALSE” if, well, you’re not.
Controlled Phones	This will display your phone’s model if you have a Tanjay-compatible device connected.
GAL or Server Based Search	Depending on your Client Policy Configuration, this will display whether you’re retrieving the adress book using the web service or the Lync Shared Folder.
PC to PC AV Encryption	Should usually say “AV Encryption Enforced” unless you changed it to “DoNotSupportEncryption” or “RequireEncryption” on your Media Configuration settings.
Telephony Mode	This will display either “Telephony Mode UC Enabled” if you’re Entreprise Voice enabled, “Telephony Mode Disabled” if you’re set to PC-to-PC only, “Telephony Mode No Audio” If you have Audio/Video disabled, “Telephony Mode RCC Enabled” if you have RCC turned on, or “Telephony Mode RCC Only” if you enabled RCC only for this user.
Line Configured From	I have only seen this one set as “Auto Line Configuration”.
Configuration Mode	“Auto Configuration” means you’re set to automatically find and connect tho the server. “Manual Configuration” means you’re using the values provided in “Server Address Internal” and “Server Address External” to connect to the server.
EWS Internal URL	This should point to the internal url of your EWS virtual directory, i.e. your internal Exchange CAS or CAS Array. If this setting is misconfigured (automatically retrived from Exchange), you might not be able to access Outlook free-busy from you Lync client and Lync phone.
EWS External URL	Points to the address of your external EWS virtual directory, based on the settings of your organizations’ Exchange Autodiscover configuration. If you’re using Office 365 Exchange Online, you will see only this field populated, pointing to https://outlook.office365.com/EWS/Exchange.asmx/WSSecurity.
SharePoint Search Center URL	points to your organization’s SharePoint Search Center URL if you configured Lync-SharePoint integration.
Skill Search URL	points to your organization’s SharePoint Skill Search URL if you configured Lync-SharePoint integration.
Connected Lync Server	Shows which server you’re connected to at the moment.
Local Log Folder	Shows the location of the Lync logging folder. This usually points to %userprofile%\AppData\Local\Microsoft\Office\15.0\Lync\Tracing.
Inside User Status	If set to “TRUE” – the user is connected directly to a Front-End server or a director. If set to “FALSE” – the user is connected to the organization via the Edge server.
Contact List Provider	Will display “Lync Server” if Lync is providing the contacts list, or “UCS” if Exchange Unified Contact Store provides it.
Pairing State	Will determine wehther Pairing is enabled or not, and will display the phone’s model if paired.
UCS Connectivity State	Will display “Exchange connection Down” if UCS is not your Contact List Provider or if Lync can’t make a connection to the UCS.
MAPI Information	“MAPI OK” means Lync was able to communicate with Exchange via Outlook. “UCMAPI is connected to Outlook, but one or more folders are not updating.;MAPI unavailable” means either the Lync user and the Outlook profile don’t match, or Outlook is closed.
EWS Information	“EWS Status OK” means Lync was able to contact Exchange through EWS, “EWS has not fully initialized” means it’s in the process of Autodiscovering EWS, “EWS not deployed” meand Lync was not able to communicate with Exchange via EWS.
License State	Shows if Lync is licensed and what sort of licesnse is assigned.
Hanging Notification Status	This will either appear as “Connected” or “Disconnected”, any input on this field is appreciated!
pChat Room Mgmt Int URL	Denotes the internal url for Persistent Chat Room Management
pChat Room Mgmt Ext URL	Denotes the external url for Persistent Chat Room Management
pChat URIs	Will display all Persistent Chat URIs
pChat Default URI	Will display the defualt Persistent Chat URI
pChat Enabled?	“True” means you’re Persistent Chat enabled and the above filelds shoud be populated. “False” means you were not enabled for Persistent Chat, and the above fields shoud be blank.

My adventures with the Lync Edge AV service

A call came in last week from a customer that’s using Lync 2013 on premises and Exchange Online. “We can’t reach our voicemail anymore”. Lync to Lync calls, PSTN to Lync calls, none could be forwarded to the Office 365 UM services. Funny enough, if I wanted to leave them a voicemail (being a federated partner), I managed to do so without any problem.

That did make sense in a way, since I’m being forwarded by Office 365 to contact the UM servers directly when using Lync. Then again, this would not solve the internal issues.

First discovery I made was that the Edge server in unable to resolve any external DNS queries. Having some firewall changes lately, I blamed it on the firewall and waited for that to be tested again. Indeed, something was preventing the Edge from sending DNS queries to the internet. That’s fixed now, but still – same issue. Additionally, it was not affecting only communications with the Office 365 UM service, all external communications that required the usage of the AV service failed.

Needless to say, throughout the entire process – No errors on the Edge server. Management store replication is ok, certificates are ok, server is patched, restarted – It’s all dandy and happy in Edge kingdom.

I insisted on rechecking all the firewall rules again – all seemed to be in place. I used James Cussen‘s great tool to test Edge connectivity – All results were successful.

After examining the UCCAPI log files of the clients and tracing the Edge server’s logs – everything was still ‘working’ as far as the Edge server was concerned. We could see the SIP traffic working perfectly (plus, we had IM and presence functioning), and the sessions would only drop as soon as the other party “picked up” the call.

This is where things are getting a little interesting. Back to Networking 101, if I’m testing a TCP connection – I will only accept the session as “Successful” if the handshake is completed:

This means that if the service is not responding, I will not get the server’s ACK, and the connection will time out.

When using UDP, it’s a different story:

So “testing” a UDP service might be a little tricky…

This had me suspicious about the AV service, being the one in charge of our RTP traffic.

With no other options left, I started tracing the actual UDP sessions.
Here’s how it looks when the AV service is not cooperating:

lync.exe 172.25.20.99 AV.Edge.com TURN TURN:TURN:Allocate Request {UDP:59, IPv4:58} lync.exe 172.25.20.99 AV.Edge.com TCP TCP:Flags=......S., SrcPort=10963, DstPort=HTTPS(443), lync.exe AV.Edge.com 172.25.20.99 TCP TCP:Flags=...A.R.., SrcPort=HTTPS(443), DstPort=10963, lync.exe 172.25.20.99 AV.Edge.com TCP TCP:Flags=......S., SrcPort=10851, DstPort=HTTPS(443), lync.exe AV.Edge.com 172.25.20.99 TCP TCP:Flags=...A.R.., SrcPort=HTTPS(443), DstPort=10851, lync.exe 172.25.20.99 AV.Edge.com TURN TURN:TURN:Allocate Request {UDP:59, IPv4:58} lync.exe 172.25.20.99 AV.Edge.com TURN TURN:TURN:Allocate Request {UDP:59, IPv4:58} lync.exe 172.25.20.99 AV.Edge.com TCP TCP:Flags=......S., SrcPort=10963, DstPort=HTTPS(443), lync.exe AV.Edge.com 172.25.20.99 TCP TCP:Flags=...A.R.., SrcPort=HTTPS(443), DstPort=10963,

Digging a little dipper into the TURN Allocate Request, we can see all the right details:

Frame: Number = 194, Captured Frame Length = 232, MediaType = WiFi + WiFi: [Unencrypted Data] .T....., (I) + LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol) + Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION + Ipv4: Src = 172.25.20.99, Dest = AV.Edge.com, Next Protocol = UDP, Packet ID = 22808, Total IP Length = 168 + Udp: SrcPort = 8588, DstPort = 3478, Length = 148 + TURN: TURN:Allocate Request

This is where I should be getting back a TURN:Allocate Response from the application. Yet, no reply.

Tried stopping the Edge AV service – it said “Stopping” for 30 minutes but never stopped, even when using the -Force switch. Trying to kill the process and the task was unsuccessful either.
This is where I tried to remove the Lync Edge components from “Programs and Features”. This failed as well, saying there was a problem with the “Lync Server Media Relay Driver” on the Local Area Connection interface.
Immediately went to “Network Connections” and what do you know?! This is what I see:

I uninstalled it, ran Bootstrapper again, and retried the connection. The result was clear:

lync.exe 172.25.20.99 AV.Edge.com TURN TURN:TURN:Allocate Request {UDP:40, IPv4:39} lync.exe 172.25.20.99 AV.Edge.com TURN TURN:TURN:Allocate Request {UDP:45, IPv4:39} lync.exe 172.25.20.99 AV.Edge.com TLS TLS:TLS Rec Layer-1 HandShake: Client Hello. {TLS:47, SSLVersionSelector:46, TCP:44, IPv4:39} lync.exe AV.Edge.com 172.25.20.99 TURN TURN:Control message, TURN:Allocate Error Response {TCP:41, IPv4:39} lync.exe AV.Edge.com 172.25.20.99 TURN TURN:TURN:Allocate Error Response {UDP:45, IPv4:39} lync.exe AV.Edge.com 172.25.20.99 TURN TURN:TURN:Allocate Response {UDP:40, IPv4:39} lync.exe AV.Edge.com 172.25.20.99 TLS TLS:TLS Rec Layer-1 HandShake: Server Hello. Server Hello Done. {TLS:47, SSLVersionSelector:46, TCP:44, IPv4:39}

Almost Immediatley you can see that the application is responding and we can get both the TURN:Allocate Response and the TLS sessions complete.

Remember this next time you’re having issues with the Lync Edge AV service.

Lync 2013 and Exchange Online UM – notes from the field

One of my recent posts was about Configuring Lync 2013 On-premises and Exchange Online to work together. After dealing with some feedback from customers and readers, I thought it might be worth to spend some time clarifying things: Edge Server You Edge Server must be configured as described in the post and enabled for federation. Confirm you have all the firewall rules in place between your Front-End and your Edge server, and your Edge server and the internet. Alternatively, you might want to restart your edge server or services just to be sure it’s all running… It’s all about the sequence There’s some logic in the order you’re committing the changes, especially if you’re migrating mailboxes from Exchange on-premises to Exchange Online. The steps are:

Before you do anything, make sure the user is already in Office 365, synced using DirSync. If you’re migrating from Exchange On-Premises to Exchange Online, you’ll have to disable the existing UM option for these users. Don’t worry, all the data will still be there when you re-enable UM later.
Run the Lync 2013 UM commands first. If the user is already synced or migration was completed, that’s the time to run the following: Grant-cshostedvoicemailpolicy –identity LocalDomain\<user> –policyname <PolicyName> and Set-csuser –identity LocalDomain\<user> –hostedvoicemail $true
Let it sync. Although it should usually work immediately, go get a cup of coffee. Or something.
Enable the user for UM in Exchange Online.

Just follow the steps… If you try to grant the on-prem policy to a user and you’re getting an error saying that the command cannot be found – it means you probably missed or skipped one of the steps. The workaround is simple: Disable UM for that user in Office 365 and wait a while for the attributes to reset. then, run the Grant-cshostedvoicemailpolicy command and voilà- it’ll work.