Set-CsTeamsMessagingPolicy -Identity MyMessageTranslationPolicy -AllowUserTranslation $false

Teams Room Devices Need Proper Licenses by July 1, 2023

On March 24, Microsoft announced a major change in the licensing regime for Teams Rooms devices. In a nutshell, Microsoft wants to stop tenants assigning user subscription licenses (like Office 365 E3 or Microsoft 365 E5) to certified Teams Rooms systems like a Surface Hub. Instead, they will require tenants to assign a Teams Rooms Basic or Teams Rooms Pro license to each device (details of the licenses are available here).

In fact, you don’t assign licenses to a Teams Rooms device. Instead, you assign the license to the Exchange Online room mailbox that manages the calendar for the device. An Exchange Online room mailbox comes with an Azure AD account that holds the license.

Microsoft says that after July 1, 2023, tenants cannot assign user subscription licenses to Teams Rooms devices. More importantly, Microsoft will block sign-ins from devices with user subscription licenses until the devices receive a Teams Rooms license.

License Types

Small organizations can rely on the Basic (no cost) license. The basic license covers “core meeting experiences” meaning that the device can schedule and join meetings and share content and whiteboarding during meetings. However, Microsoft limits these licenses to 25 Teams Rooms devices per tenant and doesn’t allow tenants to assign basic licenses to Teams panels, which require Teams Rooms Pro or Teams Shared Device licenses.

After a tenant operates more than 25 Teams Rooms devices, they must buy Pro licenses (each costing $480 for the annual subscription). If you’ve assigned user subscription licenses to Teams Rooms devices in the past, this is roughly equivalent to the annual cost of an Office 365 E5 license. The extra cost pays for “enhanced in-room meeting experiences” like better audio and video and “advanced management” like remote device management. For more details about the functionality enabled by Teams Pro licenses, see Microsoft’s comparison.

Using PowerShell to Find Licensed Room Mailboxes

The process of switching from user subscription licenses involves finding devices with those licenses, removing the licenses, and assigning a new license. To help, Microsoft created a script using Microsoft Graph PowerShell SDK cmdlets to examine and report the licenses assigned to the accounts used by room mailboxes.

Microsoft’s script uses this code to find the room mailboxes.

$Room_UPNs = get-mailbox | Where-Object { $_.recipientTypeDetails -eq "roomMailbox" } | Select-Object DisplayName, PrimarySmtpAddress, ExternalDirectoryObjectId

It’s a good example of code that works perfectly in a test environment that will be horribly slow in production. First, the code uses the old Get-Mailbox cmdlet to find mailboxes. Second, it uses a client-side filter to extract room mailboxes from the set of mailboxes. That set could be tens of thousands, so deriving the set of room mailboxes will be very slow. This version is better:

[array]$Room_UPNs = Get-ExoMailbox -Filter {recipientTypeDetails -eq "RoomMailbox" } | Select-Object DisplayName, PrimarySmtpAddress, ExternalDirectoryObjectId

Apart from using Get-ExoMailbox to fetch mailboxes and taking advantage of the much better performance of the new REST-based cmdlets together with their ability to survive transient network failures, the code uses a server-side filter to force Exchange Online to do the heavy lifting of finding room mailboxes and only transmitting their details to the client. The golden rule is that time the Get-ExoMailbox cmdlet needs to filter objects, use a server-side filter.

Oddly, the original code doesn’t declare the variable to receive the result of Get-Mailbox to be an array and ends up reporting the count of room mailboxes using the Length rather than the Count property. Another golden rule is to always declare an array to receive results from cmdlets that return PowerShell objects as it makes it much easier to check the returned values.

Always Best to Be Efficient

A case exists that this script is a one-time operation that doesn’t need to be ultra-efficient. That might be so, but it’s nice when a few tweaks make the code run much faster, especially for large tenants that are likely to have many Teams Rooms devices that might need a license check.

Know What Operating System Used by Azure AD Registered Devices

After reading an article about populating extension attributes for Azure AD registered devices, a reader asked me how easy it would be to create a report about the operating systems used for registered devices. Microsoft puts a lot of effort into encouraging customers to upgrade to Windows 11 and it’s a good idea to know what’s the device inventory. Of course, products like Intune have the ability to report this kind of information, but it’s more fun (and often more flexible) when you can extract the information yourself.

As it turns out, reporting the operating systems used by registered devices is very easy because the Microsoft Graph reports this information in the set of properties retrieved by the Get-MgDevice cmdlet from the Microsoft Graph PowerShell SDK.

PowerShell Script to Report Azure AD Registered Devices

The script described below creates a report of all registered devices and sorts the output by the last sign in date. Microsoft calls this property ApproximateLastSignInDateTime. As the name indicates, the property stores the approximate date for the last sign in. Azure AD doesn’t update the property every time someone uses the device to connect. I don’t have a good rule for when property updates occur. It’s enough (and approximate) that the date is somewhat accurate for the purpose of identifying if a device is in use, which is why the script sorts devices by that date.

Any Windows device that hasn’t been used to sign into Azure AD in the last six months is likely not active. This isn’t true for mobile phones because they seem to sign in once and never appear again. The report generated for my tenant still has a record for a Windows Phone which last signed in on 2 December 2015. I think I can conclude that it’s safe to remove this device from my inventory.

Figuring Out Device Owners

In the last script I wrote using the Get-MgDevice cmdlet, I figured out the owner of the device by extracting the user identifier from the PhysicalIds property. While this approach works, it’s complicated. A much better approach is to use the Get-MgDeviceRegisteredOwner cmdlet which returns the user identifier for the Azure AD account of the registered owner. With this identifier, we can retrieve any account property that makes sense, such as the display name, user principal name, department, city, and country. You could easily add other properties that make sense to your organization. See this article for more information about using the Get-MgUser cmdlet to interact with Azure AD user accounts.

The Big Caveat About Operating System Information

The problem that exists in using registered devices to report operating system information is that it’s not accurate. The operating system details noted for a device are accurate at the point of registration but degrade over time. If you want to generate accurate reports, you need to use the Microsoft Graph API for Intune.

With that caveat in mind, here’s the code to report the operating system information that Azure AD stores for registered devices:

Connect-MgGraph -Scope User.Read.All, Directory.Read.All
Select-MgProfile Beta

Write-Host "Finding registered devices"
[array]$Devices = Get-MgDevice -All
If (!($Devices)) { Write-Host "No registered devices found - exiting" ; break }
Write-Host ("Processing details for {0} devices" -f $Devices.count)
$Report = [System.Collections.Generic.List[Object]]::new() 
$i = 0
ForEach ($Device in $Devices) {
  $i++
  Write-Host ("Reporting device {0} ({1}/{2}" -f $Device.DisplayName, $i, $Devices.count)
  $DeviceOwner = $Null
  Try {
    [array]$OwnerIds = Get-MgDeviceRegisteredOwner -DeviceId $Device.Id
    $DeviceOwner = Get-MgUser -UserId $OwnerIds[0].Id }
  Catch {}

  $ReportLine = [PSCustomObject][Ordered]@{
   Device             = $Device.DisplayName
   Id                 = $Device.Id
   LastSignIn         = $Device.ApproximateLastSignInDateTime
   Owner              = $DeviceOwner.DisplayName
   OwnerUPN           = $DeviceOwner.UserPrincipalName
   Department         = $DeviceOwner.Department
   Office             = $DeviceOwner.OfficeLocation
   City               = $DeviceOwner.City
   Country            = $DeviceOwner.Country
   "Operating System" = $Device.OperatingSystem
   "O/S Version"      = $Device.OperatingSystemVersion
   Registered         = $Device.RegistrationDateTime
   "Account Enabled"  = $Device.AccountEnabled
   DeviceId           = $Device.DeviceId
   TrustType          = $Device.TrustType }
  $Report.Add($ReportLine)

} #End Foreach Device

# Sort in order of last signed in date
$Report = $Report | Sort-Object {$_.LastSignIn -as [datetime]} -Descending

$Report | Out-GridView

Figure 1 is an example of the report as viewed through the Out-GridView cmdlet.

An Incomplete Help

I’ve no idea whether this script will help anyone. It’s an incomplete answer to a question. However, even an incomplete answer can be useful in the right circumstances. After all, it’s just PowerShell, so use the code as you like.

---

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.