The purpose of this article is two-fold. Primarily it introduces and explains a new provisioning capability in Microsoft Teams which is applicable to Teams-certified devices across all Android-based categories: Teams Phones, Teams Displays, Teams Panels, and Teams Rooms on Android. Secondly the overall concept of device provisioning in Teams is explained along with real-world scenarios to provide some additional guidance and clarity.
At the beginning of 2021 Microsoft quietly added a new item to the Microsoft 365 Roadmap entitled Zero Touch provisioning for Teams devices under the Microsoft Teams category (Feature ID: 70675). The feature description simply states that it will “allow Remote Provisioning of Teams Android devices from Teams Admin Center” with no further details provided other than a targeted release of March 2021. Given that the title includes the phrase “Zero Touch” many Teams customers were eager to learn more about this.
Then in early March on the heals of the Microsoft Ignite 2021 digital event an article was posted to the Microsoft Teams Blog outlining what was new in Teams which outlined some new management capabilities. Included in that article was the following statement:
Remote device provisioning
We are simplifying the experience of setting up Teams Android devices remotely from the Teams Admin Center. Remote provisioning eliminates the need to physically handle devices to sign in. Instead, once the MAC address is added in the Teams Admin Center, technicians just need to install the device, connect to the network, and enter a verification code. After that, IT admins can successfully completely the provisioning remotely.
This remote provisioning functionality required two things to occur before it could be used by Microsoft Teams customers. First Microsoft needed to enable the options in a customer’s Microsoft 365 tenant and then any supported Teams devices required an updated Teams client which supports the new feature. Late in March Microsoft performed the first step by exposing the Provision new devices action underneath each Android-based device category within the Teams Admin Center for all Microsoft 365 tenants in the commercial public cloud. The second half of the puzzle requires an updated Teams Android client for each device category, which as of the time this article was posted was only initially available on a handful of phones as documented here.
After spending some time getting familiar with the provisioning process prior to the recent public release a few things have become evident which are worth dissecting further. Foremost the phrase ‘zero touch’ used in the roadmap is a bit misleading, as this process still requires a person to interact with the device to kick off the provisioning process. Traditionally ‘zero touch’ in the IP telephony world is meant to indicate a process where a device only simply needs to be powered on and connected to a network. Obviously this still requires someone to physically handle the phone to accomplish those tasks, but nothing is required beyond providing power and network connectivity. Once online the phone would automatically be provided all the information it requires from the network (e.g. DHCP/DNS) to locate a defined provisioning server to which the phone would receive any applicable configuration information, potential updates, and possibly even registration/authentication details. The essence is that of a “plug it in and walk away” approach where once the phone is brought online it would automatically proceed to fully functional state where anyone could simply walk up to it and place a call.
Yet, that is not quite the device provisioning experience that Teams has been able to provide, even with this new capability. It is not ‘zero touch’ by comparison as once the Teams device is connected to power and network it will sit in a signed-out state until someone physically interacts with it. Previously that interaction could be signing in by simply entering user credentials directly on the device or by using the Microsoft Device Login web portal on a computer. There is now a third option available on devices running the updated software called Provision Phone. Selecting this option brings up a dial pad, asking for verification code to be entered. That code is something which would need to be provided by an administration to the personnel with physical access to the device and is the foundation of this new provisioning process. Clearly someone is going to need to manually enter these codes on each device, so the level of physical interaction with the device hasn’t really changed. It is only the type of information that is shared, how it can be communicated, and the order of events which is different. As will be discussed later in this article the core benefit of this feature mainly applies when provisioning large numbers of phones at one time by extending the current 15 minute window of time required for administrators and on-site personnel to synchronize their tasks out to a full day.
The following steps outline the process of defining multiple Teams devices in a tenant and then successfully provisioning and signing one them into Teams. For this article three different Teams-certified IP phones are added to the tenant: a Poly CCX 500, CCX 600, and Trio C60. The documented provisioning and registration processes have been performed explicitly on the CCX 600.
The general actions in this process are as follows:
- A administrator prepares the device by defining it in their tenant via the unique Media Access Control (MAC) Address. They then generate a provisioning code and provide it to the personnel with physical access to the device.
- The on-site personnel enters the provisioning code directly on the phone in order to provision it to the desired tenant.
- The administrator can then sign-in the phone remotely by retrieving the device login code from the now-provisioned phone using the admin center.
- Open the Teams Admin Center and navigate to Devices, then select the appropriate category for the Teams device(s) to be provisioned, for example IP phones.
- On the Actions menu in the upper-right corner select Provision new devices.
The following screen appears providing two new views and two new options. The initial Waiting on activation tab is where new devices can be identified for the tenant either by manually entering the device MAC address in the administrative console or by uploading a file containing the device MAC address. Once that process is completed the Waiting for sign in tab can be used to view any devices which can been provisioned into the tenant but not yet signed into Teams.
Note that both options for adding MAC addresses can be used to add a single device or multiple devices so there is no requirement to create and import a CSV file attempting to add multiple devices. Largely depending on the number of devices to be added only one of the following two steps should be performed.
- To enter the device information manually select the Add MAC address option and then enter the MAC address of each device along with a descriptive name for site and/or device in the Location field. When all desired devices have been entered then select Apply.
- To instead import the device information from a file select the Upload MAC addresses option and then click on the download the template link. Using any text editor or Microsoft Excel open the downloaded Template_Provisioning.csv file and add the desired MAC address and Location information to the file. Save the file in CSV format, saving as a new file if desired (e.g. devices.csv). Then click the Select a File button, browse to the saved CSV file, and select Upload.
Regardless of which processes above was used both should produce the same results by adding the supplied device information in the Waiting on activation view.
Up to this point the current state of the devices does not matter, so they could all be sitting in boxes waiting to be shipped or deployed. Or they could be powered up and online, waiting at the initial sign in screen. If any of these devices are currently signed into the tenant or being used with any other Microsoft 365 tenant then they must be factory reset prior to using this process. From this point forward though the proverbial clock is ticking as once a verification code has been generated for a device it must be used within 24 hours, otherwise the administrator will need to generate a new verification code.
For this scenario the Poly CCX 600 has been powered on and is sitting at the initial Teams sign-in screen after a factory reset was performed on the phone.
- Select the desired device (e.g. Home_CCX600) and then click the Generate verification code option at which point the Verification Code field for the selected device will be populated. (Note the message at the top of the screen indicating that the generated code is only valid for 24 hours.)
Now that the device has been added to the Teams Admin Center and a fresh verification code has been generated the next series of steps will need to be performed directly on the device which should be powered on and waiting at the initial Teams sign-in screen as shown below.
It does not matter if a device login code is currently being shown on the device or if the Refresh code button is being shown instead. That is the alpha-numeric device login code which is used later for user authentication during the actual sign-in process. It should not be confused with the numeric verification code used for provisioning the device that was manually generated in the previous step.
- Tap the gear icon in the upper right corner to bring up the Settings menu and then select Provision phone.
- Enter the verification code that was previously generated in the TAC for this device (e.g. 697150) and then tap Next.
The device will take several seconds to process the request, as indicated by the pulsing purple line at the bottom of the screen. Once complete the following screen should appear.
The device will then return to the initial Teams sign-in screen just as it was before, but with one important difference. The Organization Name of the Microsoft 365 tenant where the device was provisioned is now displayed on the device, indicating that it is now associated specifically with that tenant, although it is still not signed in.
- In the Teams Admin Center this device should no longer be listed under the Waiting on activation list and would have been moved to the Waiting to sign in list, reporting a Device user status of Signed Out.
Sign In to Teams
At this point there is no further interaction required with the device itself as the administrator will perform the actual sign-in process from a workstation. Screenshots of the phone will still be included in the following steps for informational purposes, but no intervention is required on the device.
- Click on the Signed Out link next to the desired device and then wait while the Teams Admin Center attempts to connect to the device to retrieve a device login code and place it into a provisioning state.
During this time the device will display the following screen to prevent anyone from attempting to use the device or sign it in manually.
Once complete the Sign in a user window will automatically refresh to show the login code retrieved from the device.
- Go to the Device Login portal as instructed and enter the provided device login code (e.g. EV9PGNQN8) and then select Next. (This alpha-numeric code is not case-sensitive.)
- Given that the device being signed-in is likely going to be using a different account than that of the administrator then select the Use another account option when prompted to select an account.
- Enter the credentials of the desired Teams account to be signed-into the selected device. In this example the CCX 600 will be signed in using a Teams user account which has been configured for the Common Area Phone experience (e.g. email@example.com)
- Once authentication has completed successfully the browser window can be closed.
At this point the device will begin the sign-in process and display several different screens as the Company Portal and Teams applications connect to the Microsoft 365 tenant.
Once the sign-in process is completed the device will automatically go to the home screen, showing the appropriate interface based on the account’s assigned device policy (e.g. Common Area Phone mode).
- In the Teams Admin Center close the Sign in a user window and (if needed) refresh the Waiting for sign in view. It should no longer display that device and notice that the provisioning summary indicates that there is one less device in the “Added MAC Addresses” list and no devices are waiting to sign in.
As seen in one of the previous steps the Teams Admin Center displays the following message when signing into a phone using the retrieved device login code:
Note: A device that doesn’t have a user logged in can only be signed in as a shared device, like a conference phone or common area devices that are IP phones. Remote sign in doesn’t support personal user credentials. All device user accounts must be created in Azure Active Directory.
This statement appears to be more of what Microsoft does and does not support versus what is actually functional. In Teams there is absolutely no difference between what would be considered ‘personal’ and ‘shared’ user accounts. As far as the actual user account configuration in Azure (and the assigned Office 365 licensing) these types of accounts are identical. It is only how IP Phone policies are assigned to these accounts which makes any difference only they sign into a device, which primarily controls the user interface. The reality though is that provisioning devices with this process which are to be signed into be a regular user would not make any sense as it would require the administrator to know the user’s password, which not a good security practice. So what this statement is really attempting to convey is that this process is really designed for dealing with shared devices leveraging user accounts which fall more into the ‘service account’ realm where only administrators would know the password.
Another important thing to be aware of is that this process does not do anything special to the signed-in device in terms of managing the active credentials. For example, if the signed-in account has a password expiration policy enforced then when that password expires phone will require that the new password is entered directly on the device before it can function normally again. An administrator cannot resolve this scenario remotely other than asking someone with physical access to the phone to perform a factory reset so that the entire provisioning process can be repeated from the very beginning. This is because the administrator is not using any new functionality built into the Teams Admin Center to actually manage the sign-in process. They are simply using the device login method which have always been available on Teams Android devices, only now they have a way to retrieve (and reset, if needed) the device login code without requiring someone to physically interact with the device. This same limitation also seems to apply to devices which have been manually signed out of as they will not return to the ‘Waiting for sign in’ list in the TAC and the provisioning process cannot be attempted again on the device as it was already provisioned into the tenant (as confirmed by seeing the tenant’s Organization Name displayed on the device’s sign-in screen).
This all means that the new process is only addressing initial provisioning needs and does not add any new functionality to the act of signing a device into Teams, nor any ongoing management controls. This is a one time process which can be used to deploy a device which ideally should leverage a user account configured with a non-expiring password. If the device is manually signed out by a local administrator or the password expires then a factory reset on the device is required to re-provision it.
Thus, there are essentially now two ways to remotely sign in a Teams device. Both still require someone to physically interact with the phone at least once beyond simply powering it on, yet neither requires that the person handling the phone needs to know the user credentials. The difference between the two options really comes down to looking at the process of getting a single device online versus many devices. The value provided with the process is not really apparent when looking through the lens of getting a single phone signed in, as technically it is more work than using previously available methods. But, when dealing with deploying potentially hundreds of phones in a location where there is little to no IT staff then what was once slow and difficult is now much easier to coordinate and accomplish.
The following scenarios can be used as general guidance when needing to remote provision a device when the person handling the physical device does not, or should not know the user credentials needed to sign into the phone. That step will be performed remotely by an administrator and is most commonly used with devices in shared spaces like conference rooms and hoteling spaces. When a device is used in a personal scenario then typically that person signs in with their own credentials (which inly they should know) and there is no need to perform and remote provisioning.
Remotely Provision Some Devices
In this scenario the personnel with physical access to the device provides a device login code to the remote administrator.
This approach does not leverage any of the new provisioning options and works on any Teams Android-based device. It is the simplest and fastest when only deploying a few phones at a time and both the on-site personnel and remote administrator are available to interact with each other in near real-time. (Because the device login code provided on the phone expires after 15 minutes then the administrator has a short window to perform the sign-in process before the on-site personnel needs to revisit the phone to generate a fresh code for the administrator.)
- On-site personnel powers on a device from an out-of-the-box or factory reset status and waits for the initial sign-in screen to appear.
- They record the sign-in code which is automatically displayed on the device’s screen and provide that code to the administrator.
- The administrator uses the Microsoft Device Login portal, enters the provided device code, and then enters the preferred user credentials for that device.
- The device signs-in automatically without any additional intervention from the on-site personnel.
Remotely Provision Many Devices
In this scenario the administrator provides a verification code to the personnel with physical access to the device .
This approach leverages the new provisioning options and is ideal when many phones are being deployed at the same time. Clearly the time-limit in the previous scenario would make it difficult to near-impossible to manage if attempting to setup many devices either in a short time period or sporadically throughout a day. This is where the new provisioning process helps by breaking up the order the events and (nearly) removing the time limits on coordination between on-site and remote staff. In this approach though the administrator instead provides codes to the on-site personnel which are valid for up to 24 hours. Once the on-site personnel uses the provided code to complete their task then the administrator can come back and perform the sign-in process at their convenience, even after 24 hours.
- Either the on-site personnel or remote administrator gather/record the MAC address of each device and the administrator enters them into the Teams Admin Center. This can be performed by manually entering the addresses or by importing them in bulk from a CSV file.
- The administrator generates a verification code for each defined device and provides the codes to on-site personnel.
- On-site personnel powers on a device from an out-of-the-box or factory reset status and waits for the initial sign-in screen to appear.
- They select the Provision Phone menu option and then enter the verification code provided by the administrator for that specific device. The administrator locates the provisioned device in the Teams Admin Center and retrieves the device login code directly from the phone
- The administrator uses the Microsoft Device Login portal, enters the retrieved device code, and then enters the preferred user credentials for that device.
- The device signs-in automatically without any additional intervention from the on-site personnel.
20 thoughts on “Provisioning Microsoft Teams Android Devices”
[…] http://blog.schertz.name/2021/03/provisioning-teams-android-devices/ […]
The most important question about this process is if the picture of the administrator that is signing on to the device is suppose to be you Jeff? 😉
ha! I do have a cat, but that guy seems a bit taller than I 🙂
Great write-up! I’m disappointed to see there is still no way to re-sign-in to a CAP phone remotely after a sign-out event without factory resetting it. We are also facing an issue with MFA and Teams phones where it attempts to re-auth after some time, spamming the end user with MFA auth app requests which leads to false positive MFA fraud reports. Do you have a write-up for the best method to handle MFA on Teams devices so it won’t prompt them after the initial sign-in?
I don’t think there is anyway to resolve that currently without disabling multi-factor authentication on the accounts used to sign into the phones. Microsoft does not support MFA with Teams Rooms on Windows devices so I’m not sure if they officially support MFA on Android-based Teams devices as I cannot locate a documented statement from them in either direction. I would suggest opening a support ticket with them to report that issue.
Thanks, Jeff! For now, we have created a dynamic device group that includes all Poly phones. That group is then set to exclude in our conditional access policy. Not the ideal solution in my opinion, but worth a test.
[…] Fellow MVP, Jeff Schertz has a good overview of the remote device provisioning here. […]
Would this apply also to the Poly X30/X50 collaboration bar?
Yes, but not yet. This process is only available on Teams Phones at the moment, but it’ll also be coming to all Android-based Teams devices (Teams Rooms, Teams Displays, etc).
I’ve been playing/using a CCX500 for the last 6+ months without any issue with signing in. Today I got a CCX600 on loan, and I could not for the life of me sign it in. Rolled forward to 7.1, rolled back to 6.2, heard about issues with InTune blocking… All that to say, I finally was able to sign in after adding the MAC address to the Teams portal. Is this the way of things now going forward, or just something special about the ccx600 somehow. Tomorrow I’m probably going to nuke both my devices from Teams and from my Azure users device list as well and see… Or did I miss something obvious. Basically I was trying to sign in on the teams phone with various versions, and after entering the code on the /devicelogin the phone would flash and loop back. In 6.2 it at least showed it was “Provisioning” on the Company Portal and was stuck there for 15 minutes before I gave up, and then found this article, added the MAC, and rebooted the phone and was finally signing in.
The correct firmware version (at the moment) to be running on the CCX phones when using them in Teams mode is 7.0.3.0347. All versions newer than 6.2 include an updated Company Portal app from Microsoft which prevents a phone from signing in that does not successfully enroll in Microsoft Endpoint Manager when Android enrollment is enabled in the tenant. This requires an Intune license (except for phones in CAP mode) and also requires that MEM is configured correctly to allow Teams devices to bypass any incompatible policies.
Would provisioning the phones this way (adding the MAC address directly to the TAC) ensure that it bypasses InTune validation? I believe most of our strange sign in issues are due to InTune issues. We’ve already added exclusions, but doesn’t seem to make much difference, always tries to pass through the Company Portal stage. Often bounces back and gets stuck in a login loop/
No, the latest clients require a successful Intune device enrollment which cannot be skipped. I’m still working with Microsoft to better understand exactly what they changed as it has caused problems in several tenants due to their existing Endpoint Manager configuration.
Hi Jeff, we have the exact looping issues people are talking about started 6.2 and above. We use Android enterprise and everyone has EMS E3.
Phone provisions successfully in TAC but then when you come to sign-in with the code it sits at “Verifying a few things…” and fails back to the alpha numeric code.
Using CCX500 7.0.3.0347
Are the user accounts on these phones currently assigned an Intune license or not?
Hi, yes all have EMS E3 licenses.
Try testing with an account with the Intune license removed to see if that makes a difference.
We cannot remove the intune license otherwise BYOD device will break.
Below is the response we got from MSFT which i pretty much how we’ve already managed to get these device working however it keeps coming back to the fact Android device administration is going away and being replaced by Google android enterprise. how do these phones work with android enterprise?
1. Login to
2. Delete and recreate the last device restriction you created.
3. Give it a name
4. On “Platform Settings” change “Android Enterprise (work profile)” to BLOCK
5. Make sure “Android Device Administration” is set to ALLOW
6. Click Next
7. Click Next
8. Under Assignments click Add Group and select the group of users that are signing into devices.
9. Click through to finish the setup.
10. Please make sure that the default device type restriction and the highest priority one, do not overlap with your new created device type restriction
11. Wait a few minutes, and reboot the phone, login again.
The phones will still work with Android Enterprise but you cannot define device-level policy exceptions with that enrollment model, only Device Administrator can do that. So, if only Android Enterprise is enabled you’ll be limited in what you can do in terms of allow Teams devices to sign in when there are restrict Android policies in place. If policies are applied to user accounts then you cannot allow them to sign into a Teams Android device yet also block them from signing in on other Android phones. Only Device Administrator allows that level of granularity by setting the policy exception at the device-level instead of the user-level.
Microsoft’s current guidance is to block personal device enrollment and then define all Teams Android devices as corporate devices.
I agree, there are some logistical benefits in this approach but it’s far from ‘zero touch’. For me, the two big issues are the 24-hour lifetime of the verification codes (that’s really not long enough) and the need for the tech in mission control to have to log each one in, individually, and not before it’s actually been plugged in, before it will work.
The trouble is that I would really like the on-site tech to be able to check each phone (eg to make sure it’s got the correct account) before leaving site, so that means he needs to contact the tech in mission control to prompt him that there’s a batch of phones ready. A more complete solution would at the very least allow the tech in mission control to be able to log the phone in before it gets plugged in, but I can see why they’ve not done that (because it’s too big a change in the fundamental auth process for the phones).