We’ve touched before on a trend where we’re seeing customers doubling down or going all in on their Microsoft licensing by using using more of the products within it than ever before. This, whilst driving down technical debt, trying to reduce the sprawl of vendor solutions – and ultimately reducing moving parts through integrations is a bit of a no-brainer especially if you have E5 licensing you get much more than just Outlook.
This time though, it was a customer facing the challenge of replacing an aging on-prem dual site Mitel Director with ISDN lines provision with a flexible modern solution.
This customer had previously moved away through COVID from centralised computing powered by Citrix in a private datacentre to Intune managed laptops augmented with AVD Apps (for those line of business apps that just won’t work over a WAN) under a Mobile First initiative. It made sense to look at Teams, people were already using it for chatting convening meetings anyway, so augmenting it with the traditional telephony requirements made sense.
This post aims to focus on a use case we have where a physical handset is used by multiple people in a 24/7 rotation where signing in and out throughout the course of the day doesn’t make sense for productivity purposes.
Microsoft have a solution for this called ‘Common Area Phones‘ or ‘Microsoft Teams Shared Devices‘ where the focus is on giving the phone an identity.
What do we need to make this work?
- A compatible Microsoft Teams Phone (and a provisioning/management platform)
- A Teams Shared device license
- A resource account (for the phone) that is assigned the above license
- A calling plan or calling plan policy for making outbound calls
- A sprinkling of PowerShell to make the configuration work
Physical handset
So I set about first of all getting my hands on something shiny, I’ve not used a physical handset for 15+ years so it was quite novel unboxing one. We opted to test the Yealink MP52 E2 which is specifically built for this purpose, being robust and supporting the necessary functionality. Yealink offer a free cloud management control panel for up to 1000 devices Yealink Management Cloud Service that I hoped would make the initial setup of these devices easier.
Logging into the Yealink Management Cloud Service (YMCS) was nice and easy, I was able to click ‘Add Device’ and type in the serial number and mac address of the phone my desk and press save.
At this point I plugged the PoE enabled network cable into the Yealink MP52 E2 on my desk and within a few minutes I could see it in the YMCS portal.
From here I was able to upgrade the firmware, see remote screenshots (v useful), and make other configurations such as NTP, logging etc.
With my phone now sat at a Teams logon screen I decided to shift my focus to Teams knowing I needed to come back later to set up the global and site configurations to let the phones perform their initial setup automatically. Even neater is that any devices purchased can be loaded into the YMCS in bulk reducing the manual effort again.
Off to Microsoft Teams we go..
I bought my Teams Shared Device license through my normal Microsoft CSP portal, and opted for a UK/US/CA Zone domestic calling plan (revisiting this later) for ease to let me make and receive phone calls without worrying too much about the wider telephony configuration.
I created a resource account directly within the Microsoft 365 Admin Portal – aptly named ‘Phone – Kim Office‘ I’m still thinking about how to name them properly as they’ll exist within the global address list alongside individual people. When creating this account I was required to set a password and pop it into the password safe, we need this later (but we don’t give it to a user!).
Additionally, I had to consider Conditional Access here as by default every account provisioned must satisfy MFA – we didn’t want that here as it would reduce the effectiveness of the solution so I created a locked down Conditional Access policy to let these accounts access Teams from within the corporate network without MFA.
I assigned my licenses to this resource account and added a phone number then made a note that this would be much easier through using Group Based Licensing which would tie in nicely with the Conditional Access policy making the account sign up process straight forward. Reducing clicks and moving parts for the setup is key for when we have to roll out several hundred of these devices quickly.
With the ‘handset’ and ‘account’ now set up we need to pair them together which we do within the Microsoft Teams portal under Teams Devices, Phones, then Actions – Provision Devices – https://admin.teams.microsoft.com/devices/remoteProvisioning
We have to enter our physical handset mac address again here so this time MS Teams knows what to do with it:
Once the physical handset mac address is added here the MS Teams portal will show that a device is awaiting activation. From the Teams Portal we can obtain a verification code for the handset.
We then power up the handset, and within settings click ‘Provision’ and type in the Verification code we obtained from the Teams portal. The handset will then onboard to Teams and reboot.
Back within the Teams portal the handset will have moved from ‘waiting on activation‘ to ‘waiting for sign in‘ because we’ve now proven our ownership of the device through exchanging the verification code.
At this point we could sign into the phone in a variety of ways:
- Locally at the handset itself
- Remotely from another device
- Automatically from MS Teams Admin portal
We want this to be as automated as possible so asking someone to sign in locally, or from another device isn’t practical.
We can use the MS Teams Admin portal to allow us to ‘Sign in the device’ remotely by clicking on the handset and selecting sign in.
Crucially, we can do this without being physically near the phone, we use the code provided within the MS Teams Admin portal together with the resource account credentials we set up earlier to sign the device in. It will then reboot and be signed into the resource account.
The final piece of the puzzle is how to lock the handset down as in the current configuration it is still a ‘user phone’, it just so happens to have been logged in remotely by us – but its not yet defined as a Common Area Phone / Shared Device
In comes PowerShell because this is not yet in the UI unless you have E5 licenses…
New-CsTeamsIPPhonePolicy -Identity “Common Area Phones” -Description “Policy for all Common Area Phones” -SignInMode “CommonAreaPhoneSignIn” -AllowHomeScreen “Disabled” -AllowBetterTogether “Disabled” -AllowHotDesking $False -SearchOnCommonAreaPhoneMode “Enabled”
Grant-CsTeamsIpPhonePolicy -Identity [email protected] -PolicyName “Common Area Phones”
A very appropriate hat tip to Sean McAvinue for his blog post that covers this https://seanmcavinue.net/2021/05/31/configure-microsoft-teams-common-area-phones/ and goes into further detail. Thanks Sean!
A reboot of the handset and it is then locked down, and behaves like a common shared purpose handset.
The next steps for me here are to:
- Factory reset the phone using the Yealink YMCS portal and make sure the automatic date/time format, & firmware upgrade happens on the first boot up
- Tweak the policy within Teams to apply a maintenance window regularly to ensure Teams updates are applied in good time, the default is once a week.
- Look at automating the creation of the resource accounts once I’ve decided on a naming convention, and marry up the mac addresses/serials to resource accounts on the asset register.
- Stringing together the automation to take mac addresses into YMCS, and into Teams, attached to a resource account (in a group for licensing) and get as far down the line as possible to just need to remotely sign the device in once from the Teams Admin console. (I wonder if there’s a way I could use YMCS to populate credentials for the phone to sign itself in!)
All in all, I am really quite impressed, the sequence is logical and will make a fine runbook.