Hi friends! I’m back again with another post on Teams Devices. I’m sure you’re shocked – shocked I say!
Today, I want to focus on Teams Devices Management. Since the launch of Native Teams Devices, they have been “managed” in Teams Admin Center and Intune with the “Android Device Administator” management tools. This is an older and deprecated management tool. Over the last period of time, Microsoft has been deprecating and end-of-lifing Device Administrator for all GMS-based (Google Mobile Services based) devices and this came to end December 2024.
But this is not the same as non-GMS-based devices like Teams Phone, Teams Panels, and Microsoft Teams Rooms on Android. These devices have continued to be managed via Android Device Administrator mediated by the Company Portal application baked into the firmware of each device.
For the last little while, Microsoft has been working closely with our Device OEM partners to move away from Android Device Administrator to the *new* method known as AOSP – Android Open Source Project. We made this announcement a year or so ago and this blog post has remained the definitive set of details to get you from here to there. Our Teams Devices Deployment Playbook found on Teams Academy is still full of the standard Android Device Administrator method for device enrollment and compliance. This will be updated to reflect these changes, but in the meantime, I thought I’d provide a few practical things to get you going – again, these are covered in the Tech Community blog post above and in our Admin guide on learn.microsoft.com but sometimes people enjoy a few more details. That’s where I come in. Let’s get going.
Identities & Licensing
All of the Identity (users and shared devices) and licensing guidance for Teams Devices remains the same. Go back to the playbook. Follow our guidance for identity creation and licensing. Be sure to include and activate the Intune licenses/service for device enrollment/compliance and of course Entra ID for any Conditional Access needs. These are covered in the Playbook and I’ve written a few articles here too.
Intune Enrollment
Let’s start in Intune – https://intune.microsoft.com – and let’s make sure we address Device Enrollment. If you’ve followed our playbook, you’re already set on Android Device Administrator. Just to validate that, you can head to Intune Admin -> Devices -> Device Onboarding -> Enrollment and check the Android Device Administrator box.

Easy peasy. Now, let’s enable Enrollment for AOSP. You can follow the Admin Guide I linked to above as well. We’ll navigate to Intune Admin -> Devices -> Device Onboarding -> Enrollment and head into Android Open Source Project (AOSP) and create an Enrollment Profile for “Corporate-owned, user-associated devices”.

Let’s Create Policy

You’ll notice the default “token length” is 65 years – I’ll be long dead. I just changed it to 5 years – 2030. This lab will be rebuilt a few times between now and then 🙂 Also make sure you set the Teams Devices setting to Enabled. This is required. Click Next.

Once you “upgrade” the device to an AOSP firmware, if you haven’t done these pre-requisites, including this setting, bad things will happen. Be sure to read those blogs I linked to above for depth. I’m offering you the “filet” – the practical things you need to do!

Great. You’re done here. You’ve created the enrollment profile. Super easy.
Intune Compliance
Let’s stay in Intune – https://intune.microsoft.com – and let’s make sure we address Device Compliance. If you’ve followed our playbook, you’re already created a number of Intune Compliance policies properly scoped to the identity associated with the “type” of device in question – Shared Devices like Common Area Phones, Teams Rooms, Panels – and personal devices like end-users who use Teams Phone devices. All of those were created as Device Administrator compliance policies. Just to validate those, you can head to. Just to validate that, you can head to Intune Admin -> Devices -> Manage Devices -> Compliance and review your compalince policies. Here are a few of mine.

As you review the various AOSP articles I linked above, you’ll notice that we will *not proactively* create any Enrollment or Compliance policies for you. That’s your responsibility. In essence, you’ll take what exists and create a copy – but instead of it being an Android device administartor platform, you’ll focus on AOSP platform. So, taking Common Area Phones, let’s make a new one. Click on Create policy.

This needs to be Android (AOSP) platform. Now create an appropriate policy for your devices. In my case, I’ll create “copies” of my compliance policies for AOSP. I did this a few months ago when I was doing early testing. So, with blog-magic – here you go!

Teams Admin Center – Software Health
You’ve now handled the Intune work. Let’s go to TAC – Teams Admin Center – and validate the current state of a device that you wish to move to AOSP. Now that you’re ready for Intune enrollment and compliance, you’re ready to upgrade the firmware!
Here’s what a “current” Device Administrator Firmware looks like under Software Health. Notice the presence of the Company Portal application. This is your clue.

If a firmware update is available, the green “Up to date” text will instead be purple “See available updates” text.

For example, this is a firmware update available for one of my Yealink Phones

Notice this clearly is a Company Portal firmware – it says “Company Portal” under the version number.
But, what if it was an AOSP firmware? Well, that would look like this.

This was when I was testing AOSP upgrades for the Cisco Roombar Teams Room on Android. Notice that the firmware is clearly marked as AOSP. And if you “check the firmware” to install it, the text pops up in red and tells you that there are Significant changes in the update! This is your clue. Be sure you’ve read the admin guides linked above and be sure you’re ready! We’ve been warning you for some time now, and this is your last chance warning. If you are not prepared, and you update this firmware, your device will logout and you’ll need to go back through the enrollment and login process. Go read. I’ll wait.
Great. You’ve done the work (like this blog). You’ve updated the firmware. And that causes the device to reboot. That’s easy. What should now happen is… well… nothing to the end user. The device should stay logged in. So, how can you know something actually happened? Let’s re-check TAC.

This is that same Cisco Roombar. Notice I *do* have the firmware installed from above. Also notice that Company Portal no longer appears in Software Health. Instead, we have the new AOSP Device Management apps of Authenticator and Microsoft Intune. This is good! The update was successful!
Another particular place you can check is back in Intune.
Intune Devices -> OS
The last place I want to point you for clues that you’ve successfully upgraded your firmware from Device Administrator to AOSP is Intune. Let’s navigate to Intune Admin -> Devices -> All Devices. And you can sort by OS – this is the “method” by which the device was enrolled. Here’s this current lab.

Notice I have just a few devices at the top left to update. They are still “Device Administator” devices. Everything else of note is AOSP including the Cisco Roombar device you can see towards the bottom of the screen shot above. This is just another place you to can go to report on what devices you have and get a plan to get them upgraded to AOSP. I’m almost completely done. Just waiting on a few stragglers to test.
Wrap Up
This takes us to the end. This again was designed to be more of a Practical guide. We have a tech community post and an admin guide I linked above. What you see in this blog post are the specific annotated steps I took to make the magic happen. And I know one of your very next questions will be: What about my devices? When will I have AOSP firmware available? Great question. I’ll point you BACK to the Tech Community post above – I’ll link it again here. Click on that post and scroll to the chart. Our Product Group is actively keeping that up to date to show you what devices have currently (as of today February 21, 2025) gone GA – those are an AudioCodes phone, AudioCodes MTRA + Panels, and then just this week, more MTRA + Panels from Cisco, DTEN, Jabra and Yealink. Go check the chart and get your homework done. We are anticipating hitting our dates in the chart. If that changes, we’ll update the chart accordingly.
Happy Device Management!