Teams AOSP Migration - Device Filters
- Mark Webb
- Jul 28
- 4 min read
While testing migration for Teams Android devices from the "legacy" Device Administrator enrolment profile in Intune to the new AOSP management I wanted to understand the device enrolment process into Entra and Intune in a bit more detail. Mainly due to how the enrolment would interact with Conditional Access since more and more authentication workflows will be impacted by these policies as security teams tighten who and what can access company resources.
Intune Profiles
I'm going to assume anyone reading this is aware of the migration to the new AOSP management of Teams Android devices and has taken steps to prepare their environment. If not, do it now! Unless of course you don't enrol your Teams devices into Intune, in which case you can ignore all of this...I'd recommend doing it though, it gives you better visibility of the devices and means you can report on compliance and add some basic Configuratin Profiles to manage some device settings.
Microsoft are actively moving devices onto the AOSP platform and if you haven't setup your tenant to allow the devices to migrate they will sign out and you'll have to take manual action to get them back online. Details here: https://learn.microsoft.com/en-us/microsoftteams/rooms/android-migration-guide
Initial Device Sign In
When a user (or Common Area Phone account) initially signs in using the code on the screen of a device, the device is registered to Entra before it hits Intune and enrols there. We can see this in the Entra device audit logs as the initial entry shows a very basic set of device information.

The audit logs also show this initial activity with the details of what device attributes are added to Entra.

The "Add device" entry has this set of properties added

Now, the "issue" we have here is that if you've got any Conditional Access policies which are targetting "All Resources" or any policy which includes "Microsoft Teams Services" as a resource then this authentication flow is going to be captured in that.
If any of those policies then check for things like device compliance or apply any other validation before granting access we need to be able to filter these devices out potentially otherwise the sign in flow will fail at this first stage.
For example, I've setup a Conditional Access policy which applies to All Users and All Resource which requires the device to be compliant.
Without adding any filters in, the sign in to Teams will fail

The problem is that because the device hasn't enrolled into Intune yet, no compliance information exists (even if that would result in a Grace state condition) and therefore Entra will block the sign in.
Bit of a chicken and egg scenario going on. So we need some way to filter these devices out of this policy initially so they can sign in and begin their Intune enrolment.
Device Filters
The way we can do this is to use device filters in the Conditional Access policy to exclude them. Normally for a device that already exists in Entra/Intune we'd use something specific like the Manufacturer name or Model name/number to target the specific devices we want but as we can see from the audit log entry above, we get none of that with this initial sign in. All we have is very basic device info.
All that we have that is unique to this device is the display name which in this case is PolyCCX500. Without anything else that's unique, we'll have to use that for our filter.
So we update our device filters in our Conditional Access policy to add an "And" statement to include devices that aren't equal to PolyCCX500. We use an "And" because our policy is a Block one so we're including devices which aren't compliant to then apply a Block. So our updated filter rule looks like this

Now we've added that, if we try signing in again.....I get a failure still!

The device it references looks ok and has the display name we've filtered out

but obviously something is still not right.
To figure out what was going on and could be causing this, I excluded a specific account from this policy to see what happens in Entra/Intune if we're not checking for compliance.
And what we can see is that after the device has been added to Entra (the first sign in we referenced above and had the display name PolyCCX500), once it has passed this it then proceeds to enrol into Intune. As part of that registration, Intune then updates a number of attributes of the device, including the display name of the device. Again, we can see this in the Audit Logs in Entra.

The key update is the top one, where Intune updates the device attributes

Intune updates the display name from the initial PolyCCX500 to whatever either your AOSP Enrolment Profile naming convention is (if you set one in the enrolment profile) or if not it'll set it to the default Intune name of username_aosp_date/time or something along those lines. Basically the display name is now different to our Conditional Access filter condition so it seems to be failing again.
So we need a second filter to take care of this....<sigh>
Now we could use the OS Type to filter as that's been updated from Android to AndroidAOSP but that's not particularly specific if you have multiple devices enrolled using this OS Type. But use that if it suits your needs and you're happy with it.
To make it more specific, we can use the Enrolment Profile name filter in the Conditional Access policy though. This you get from viewing the AOSP enrolment profile you have setup in Intune and adding that name into the device filter. Doing that means our update policy filter now looks like this (replace the value of the enrolment profile name with whatever your one is) called:

Now when we sign in, we don't get any sign in errors and we can see that our conditional access policy is successfully excluding the device.

We also see the right order of events in Entra, with the device being added and then updated by Intune.

Conclusion
If you're working in an organisation that applies a number of Conditional Access policies that check for device properties then you may need to look at this to help include or exclude Teams devices depending on your setup.
It's also quite useful to understand the sign in flow and how the devices onboard to Entra and Intune for documentation and having an understanding of how the devices are presented across the environment.
Comments