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
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:


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

“Description”=”Microsoft Teams Meeting Add-in for Microsoft Office”
“FriendlyName”=”Microsoft Teams Meeting Add-in for Microsoft Office”

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

December 31st, 2018 | Tags: ,

With Exchange and Skype for Business Server 2019 now GA I decided to created a new lab environment, both are Hybrid installations and I opted to create a brand new Office 365 tenant.

For those not already aware Skype for Business Server 2019 (when paired with Exchange Server 2019), no longer has the ability to provide Unified Messaging and Microsoft expects customers to instead leverage Azure or “Cloud” Voicemail. There’s a great table (I’ve stolen from TechNet below) that illustrates supportability across the various versions.

Exchange Server 2013 Exchange Server 2016 Exchange Server 2019 Exchange Online
Skype for Business Server 2019 Exchange Server UM Exchange Server UM Cloud Voicemail Cloud Voicemail
Skype for Business Server 2015 Exchange Server UM Exchange Server UM Cloud Voicemail Exchange Online UM
Lync Server 2013 Exchange Server UM Exchange Server UM Cloud Voicemail Exchange Online UM

The planning and setup is well documented here and I followed this guide without any issues, however when I placed a call to voicemail I was seeing call failures, specifically:

“Failed to route to Exchange Unified Messaging Server”;source=”FE.DOMAIN.COM”



The first thing I checked was the licensing, now Microsoft’s requirement is that at least a single user is licensed for Skype for Business with a Teams license assigned. This new tenant met all the prerequisites, but still voicemail would not route correctly and was being rejected by Office 365.

Next step, I logged a ticket with Microsoft. It turned out that the issue was due to the fact that because no calls had been made between any cloud homed users voicemail had not yet provisioned itself correctly. As a workaround I was asked t0 log into two Teams users within the tenant in question and place calls in both directs. Voila – Cloud Voicemail immediately started working!

I was given the impression by Microsoft support that this is a temporary issue and will be addressed in the near future, in the meantime I’m sharing this workaround with other folks.