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.

Specifically:

https://domain.com/AutoDiscover/AutoDiscover.xml

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!

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!

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!

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.

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.

A video and the deck has now been posted here.

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.

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!

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.

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”

;dialplan=“Hosted__exap.um.outlook.com__YourDefaultDomain.onmicrosoft.com”

;appName=”ExumRouting”

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.