Last Updated on July 1, 2021 by GrahamWalsh
With the release of the latest Microsoft Teams Room App 184.108.40.206 onwards, Microsoft made some changes to how the app talks to different services. The main one in this release relates to Skype for Business. A summary can be found here. However, there have been reports of missing room name on the MTR console.
So, what has changed? Well Microsoft are slowing removing the dependencies on Skype for Business as they are shutting down Skype for Business Online in July 2021. One of the changes in the latest app is that it removes any sign in errors for Skype for Business as I discussed in the summary here.
One of the other changes here is that the account is no longer using the meeting room name from the Skype for Business sign-in. Microsoft has moved this supposedly to Exchange now. If you use a standard user account with an MTR this is what happens. You can also see it cannot fetch a calendar. This is not an issue if you are using a Resource Mailbox.
Here are the details of the account that is signed in.
You can see here the account does not have an Exchange account which is the reason it cannot fetch the calendar.
But the account has a Microsoft Teams license, hence it could sign in.
Once you assign an Exchange account to the user account, then all is good.
If you assign a Meeting Room Account (which is a resource mailbox too) then all should be fine. The name is no longer pulled from the Skype for Business side of things which would have been the Display Name when you looked at csmeetingroom from the Skype for Business PowerShell.
Microsoft also rolled out an update app version, 220.127.116.11 to allow the name to be shown if the Resource Account is hidden from the Global Address List.
Update – 1st July 2021
So, I’ve had several questions regarding this issue as it appears to be still happening, so I decided to investigate this again. I have an account that is signed into Teams and can make calls. What’s different about this account is that it is licensed with a Common Area Phone license that has also expired in the trial. Wonder if that is the issue?
Let’s look at the other Common Area Phone account I setup as a user (and not as a resource mailbox), and that license has also expired. What is going on? It is not the license that has expired. My next thought is now to compare the two accounts with PowerShell and see where the differences are. Luckily, I wrote a blog post on this here.
Upon comparing the two accounts for Calendar Processing doesn’t really tell us much as one account has a mailbox and one doesn’t.
What next, well if we run Get-User (this is in Exchange), I can see the differences of the accounts, however, I need more information on this.
Name RecipientType interviewroom01 User Interview Room 02 UserMailbox
If we use an AzureAD command, we can run this, get the output for this, and compare.
### Getting User Account information from Azure AD Get-MsolUser -UserPrincipalName $roomname | fl > c:\temp\$roomname-azuread.txt
Now comparing these two accounts, remember Room 01 was working and Room 02 wasn’t. I can’t see anything out of normality here to see what the difference is. Phone Number vs Office Number, which won’t affect the name (or at least I don’t think it will).
I could run some commands in Exchange, but Room 01 doesn’t have an Exchange Mailbox, so it will report nothing. Unless, if the account has an Exchange Mailbox, it overrides what is in AD? So, let’s have a look anyway
Get-Mailbox -Identity "$roomname" | fl > c:\temp\$roomname-mailbox.txt
And here is the output for Room 02. When I run this again Room 01, I get an error as there is no mailbox. I have removed the 100 odd lines of other stuff and kept anything with a Name in the field. The only one I can see that could be possible is SimpleDisplayName. Now this is meant to be used for external emails, so can’t see why an MTR would use this.
The SimpleDisplayName parameter is used to display an alternative description of the object when only a limited set of characters is permitted. Valid characters are:Quote from Set-User (ExchangePowerShell) | Microsoft Docs
I then thought, why not check the Event Viewer logs. In the Skype Room System logs, I found this. There is no Alias and no Display Name. Hence why it is not being shown on the Centre of Room or Front of Room displays
On the working system, I see the following
Now what makes no sense at all is that the Display Name is shown during a call as you can see below.
Now let’s change devices and swap things around to see if the problem follows. And it works. So, the problem lies with my release of software for the MTR which I’ve logged a bug for with Microsoft. That will teach me for trying to compare with two difference revisions. Still, it doesn’t explain why one works and one doesn’t. This issue could appear again, and I am still getting questions as to why it is missing on 18.104.22.168
To conclude, I have no idea what is going on and where the Room Display Name is being pulled from. When I signed a device in on a different tenant, I could see it show the SIP URI/Proxy Address/SMTP address briefly but then showed the Display Name (or whatever the heck it is). When I do find out, I’ll update the article.
Any questions or thoughts, let me know below.
Also published on Medium.