September 24th, 2021 | Tags:

So last week the one of the biggest Microsoft UC events took place in the UK, Commsverse. I was planning on travelling over, but in the end I opted to present virtually. I’d usually jump at the chance to go back to blighty, but it still felt a little too soon for transatlantic travel.

I decided to re-present my Ignite session on Teams Rooms, but made some significant updates. There’s some excellent content from Microsoft that’s now available to help troubleshooting and also some new features bringing feature parity closer than before.

My presentation is available for download here and if you didn’t get a chance to join then there’s always next year and Commsverse 2022!

April 23rd, 2020 | Tags:

So my day job, at Poly, requires that I test a load of native Microsoft Teams devices – it’s a hard job, but somebody got to do it! 😉

This can throw into the mix some interesting scenarios, one of which is reaching the cap of maximum registered Intune devices (to a user), which by default is 15. This can be increased to 50, see here.

However I’m still seeing this threshold being reached which subsequently throws an Intune enrollment error – device cap reached.

The removal of devices via the Azure Active Directory web interface is great for removing a few devices, but anything more and it just falls down. But never fear PowerShell to the rescue!

First up I want to create a CSV that contains all devices that have not registered since December 31st 2019 (this date can obviously be modified to suit your needs)

$dt = [datetime]’2019/12/31’
Get-MsolDevice -all -LogonTimeBefore $dt | select-object -Property Enabled, DeviceId, DisplayName, DeviceTrustType, ApproximateLastLogonTimestamp | export-csv devicelist-olderthan-Dec-31-2019-summary.csv

This will create a CSV file with all devices, their IDs, names and last logon time.

Once you’ve pruned the CSV you can use this as a template to go ahead and perform bulk removal.

$list=import-csv devicelist-olderthan-Dec-31-2019-summary.csv
Foreach($device in $list){ Remove-MSOLDevice -DeviceId $device.DeviceId -force }

This can take some time to complete and once done you can always re-execute the first step to validate devices have been removed successfully.

November 21st, 2019 | Tags:

Microsoft’s Teams device strategy leverages Android as a platform, this currently includes IP Phones and will also incorporate a new category of devices recently announced at Ignite – Collaboration Bars for Microsoft Teams, more on this here.

One common occurrence is that when these devices are connected to Azure Active Directory, Mobile Device Management (MDM) policies can cause various provisioning errors due to lack of compliance.

Whilst these devices are running Android, they should not be considered as smartphones, they each run hardened versions of Android that are closely coupled with SoC-specific drivers. As such they need to be treated differently, whilst Microsoft publicly announced deprecation of mainstream support for Android 4.x within Intune, Intune will continue to support any Teams Android-based devices.

To that end as an admin we need to have a way of excluding Teams devices from MDM policies. To handle this Microsoft recently introduced a new Dynamic Device group within Azure Directory. In this short guide we will create a group, define membership rules and then exclude this group from an existing MDM compliance policy.

First we need to access the Azure Active Directory group administration portal, here. We need to ensure we have the appropriate admin permissions for perform this task.

The first thing we’ll do here is create a new group, as per the example below I’ve set the group type to Security and given a friendly name/description. We then need to set our membership type to Dynamic Device.

Next, we need to add a dynamic device query, this will ensure that any new devices are automatically added to this group upon enrollment.

Once the add dynamic query dialogue is clicked the user interface below is presented. In this example we’re going to manually define a Rule syntax by clicking edit.

Now we can add our Rule syntax, in this example we’re setting all devices with the OS type Android, with model names of CCX400, CCX500, CCX600, Trio 8500, Trio 8800, Trio C60, Studio X30 and Studio X50

Rule syntax:

(device.deviceOSType -eq “Android”) and (device.deviceModel -eq “CCX400”) or (device.deviceModel -eq “CCX500”) or (device.deviceModel -eq “CCX600”) or (device.deviceModel -eq “Trio8800”) or (device.deviceModel -eq “Trio8500”) or (device.deviceModel -eq “PolyTrioC60”) or (device.deviceModel -eq “PolyStudioX30”) or (device.deviceModel -eq “PolyStudioX50”)

This syntax has recently been updated, instead of referencing the device.deviceModel property we now use device.displayName. Therefore the syntax should now be:

(device.deviceOSType -eq “Android”) and (device.deviceModel -eq “CCX400”) or (device.deviceModel -eq “CCX500”) or (device.deviceModel -eq “CCX600”) or (device.deviceModel -eq “Trio8800”) or (device.deviceModel -eq “Trio8500”) or (device.deviceModel -eq “TrioC60”) or (device.deviceModel -eq “PolyStudioX30”) or (device.deviceModel -eq “PolyStudioX50”)

This can also now be validated as per below:

We can then click, OK which dismissed this dialogue and then click Save. This returns us to the initial new group creation screen where we can complete the group setup by clicking Create.

We can validate the group creation by looking at the members populated automatically by this rule.

Next, we need to access our existing MDM compliance policy and exclude this group. MDM compliance policies can be edited via Microsoft portal here.

In this example we have a simple compliance policy that is configured to block any devices that are running older versions of Android, specifically 4.x or lower. If we configure the policy Assignments, we can now go ahead and add our group created previously and Exclude this so to ensure our Poly devices are no longer impacted by this check.

I hope this was of help, feel free to comment below and if you would like to see this demonstrated live please view my presentation from Ignite here.

November 21st, 2019 | Tags:

Ignite was great this year and I was lucky enough to have the opportunity to speak again. This year I decided to focus all up on Teams device deployment gotchas, more specifically issues that have been raised via customers.

A video and the deck has now been posted here.

April 26th, 2019 | Tags:

Yesterday Microsoft published a blog article, which announced their plans to revoke support for the existing Azure application ID leveraged by their 3rd party device vendors.

The existing application ID is embedded within each respective device firmware and today this is pointed at an Azure application hosted within Microsoft’s tenant. Microsoft’s goal here is for each respective device vendor to deploy their own Azure application with the permissions required for the device to register to Azure Active Directory.

The change from a device standpoint is a simple one and speaking from a Poly perspective, my employer, we’ve tested this across our VVX, Trio and Group Series lines of product. However…once this change is implemented within our firmware it requires that the customer or specifically the customer’s administrator, performs a tenant-wide consent as our Azure application is not whitelisted like Microsoft’s.

This consent would grant the Poly Azure application with the rights required to perform authentication on behalf of the device against the respective customer’s Azure Active Directory.

Full list of rights can be seen below:

I will update this post as soon as Poly have a date for each respective device firmware, but rest assured our friends at Microsoft won’t pull the plug on the existing application ID until this transition is completed.

In the meantime for those that want to be ahead of the curve the Poly consent URL is here.

Timelines for updates below, please note these are targets and could be subject to change. Also note: prior to upgrading to these releases online customers must perform the consent via the URL above.

Device nameSoftware VersionTimelineDownload
VVX Phones5.9.4.3247Late-SeptURL
Poly Trio5.9.1.10419Late-SeptURL
Group Series6.2.1.1Mid-JuneURL
CX55001.3.5Late-AprilURL
January 31st, 2019 | Tags:

So apparently I’m not alone here. One day you can be happily scheduling Microsoft Teams meetings to your heart’s content and the next the add-in just vanishes into thin air. Whilst I don’t know why this happens I have a solution I’d like to add to the existing repertoire of blog posts within the wild.

The most informative post, that extends beyond the basic troubleshooting is one from fellow MVP Michael LaMontagne, in this post he shares registry settings from a PC where the add-in is loading successfully. This approach did work for me, but I also identified a vastly reduced set of registry settings that seemed (for me anyways) to resolve my issue.

The issue in my case was that Outlook no longer loaded this add-in or gave me the option to add it. When I looked within the registry I found that the add-in didn’t have a key at all when I looked at:

Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\

Shouldn’t there be a key called TeamsAddin.Connect here?

So I manually created the key by adding the following to a text file (renaming the extension from .txt to .reg)

Windows Registry Editor Version 5.00


[HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\TeamsAddin.Connect]
“Description”=”Microsoft Teams Meeting Add-in for Microsoft Office”
“FriendlyName”=”Microsoft Teams Meeting Add-in for Microsoft Office”
“LoadBehavior”=dword:00000003

After importing this, I re-started Outlook and voila – the add-in had returned!