August 23rd, 2023 | Tags:

I’ve been experiencing a weird certificate error when opening Outlook for M365, something to the effect of this seen inline:

I have a pretty good grasp of Outlook, certificates and DNS – but this had me scratching my head for some time, especially as I’d not loaded a certificate manually.

It turned out that the error in question was linked to the Outlook Autodiscovery process, my DNS in this regard was configured correctly and successfully passed the domain verification process within the M365 Admin Portal. However whilst the autodiscover CNAME was in place correctly, Outlook also likes to check for other records.


When you add your domain to GoDaddy DNS hosting it creates a default record or catch-all, see inline:

This resulted in Outlook retrieving a default certificate installed by GoDaddy which in turn caused a security alert prompt. This could have been worked around via various registry keys, but given my machines are unmanaged this approach would have required more client-side work.

Instead I updated/removed this DNS entry and presto, security error solved!

December 8th, 2022 | Tags:

So it’s been a while since I’ve posted here, primarily due to the fact I’ve changed jobs a few times. I had a brief hiatus from the Unified Communications world, but I’m back where I guess I belong – this time at Microsoft.

One of the first feature items I picked up was associated with my old friend CVI, specifically in relation to how lobby permissions are handled.

For those familiar with CVI there’s a number of layers whereby permissions in respect to lobby are managed.

  1. CVI Bot can be configured as “trusted”, this essentially allows all VTCs joining calls scheduled within said tenant to bypass the lobby. Resulting in VTCs being treated as participants homed within said tenant (instead of guests). The PowerShell that enables this experience is AllowAppGuestJoinsAsAuthenticated with the parameter set to ‘$true’ 
  2. The next layer is set at a service and CVI vendor-specific level. This varies between each CVI provider, but the goal here is to limit the scope of item #1 to specific known devices or networks

In the case of item #1 above there was a problem, if someone took advantage of the meeting options highlighted below, people I invite or only me and co-organizers, this option was ignored. The good news is that is meeting option is now honored!

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.