[Show theme music]
STEPHEN ROSE: Hey, everybody. Welcome to another episode
of "Inside Microsoft Teams."
I'm your host, Stephen Rose.
We are once again continuing with our Double-Click series,
and we're here to talk this week about policies
for Android calling devices.
We've had a lot like, hey, we're getting ready
to set up some Teams rooms or we're using
some Android phones, etc. etc. etc.
And how do we best manage it?
What are some things and some gotchas that we have?
Should we treat it just like an IoT device?
How do we look at it?
And I thought, you know, that would be
great things for us to cover in this series.
So today, let's talk about policies for IoT with Android
but not Android mobile.
And with me is one of our experts.
Hi Kruthika, how are you today?
KRUTHIKA PONNUSAMY: Hey, Stephen. I'm good. How are you?
Thank you for having me.
STEPHEN ROSE: No, thanks for being here.
Take a moment and tell people who you are
and the role that you play here at Microsoft.
KRUTHIKA PONNUSAMY: I'm a PM lead for
Teams Android personal devices.
We are basically the team that builds kiosk mode devices
that runs Teams natively on the Android platform.
STEPHEN ROSE: So, what's an example in the real world
that someone might see that would be one of these devices?
Where might they see one, or where should an IT pro go,
"Oh, that's probably one, or we need one there."
KRUTHIKA PONNUSAMY: So, if you are a tenant
that's deploying Teams
and you have a use case for a device
in a kitchenette or in a common area,
you'd want that device to be running Teams on it.
The only use case may be to make a call,
to maybe receive calls, if someone wants it to use
for emergency scenarios, they want to be able
to access calling through those devices, as well.
So, that is one of our devices.
And as an evolution of those devices,
let's say you want an exec that wants a specific device
that is on their desk running Teams
but also have video capabilities
and not use your laptop for your, you know,
Teams calling and meeting streams.
So, those dedicated devices that run nothing but Teams.
STEPHEN ROSE: Would that be also like what we refer
to as a "hot-desking device"?
Would that be part of that, as well,
or is that something different?
KRUTHIKA PONNUSAMY: Hot-desking is a use case
and not necessarily a device.
So, the same device with the same functionality
can be used in hot-desking scenarios where people walk in
and out of the desks and the spaces
but have this device that's already deployed
and use it for their calling and meeting streams
as always.
STEPHEN ROSE: Now, the thing to remember is,
these are not devices
that just show up one day and are gone the next.
There's an actual lifespan to these,
often they're 2 to 3 years.
And they're getting getting features on a regular basis.
So I guess I have two questions:
Number 1, how do we best manage that?
Because I know there are some companies
who do not let the devices automatically update.
They want to manage it, push it out,
and there are opportunities to get behind.
And then, the second part is, how secure are these devices?
KRUTHIKA PONNUSAMY: Right. So, it's funny you bring that up.
These are not like your mobile devices.
They are purpose built to run Teams on it.
We work with the phone manufacturers
and the device manufacturers
to make sure that they meet our requirements
to run Teams on it, to keep them secure,
and to have them managed, as well, right?
So, it is not your Android mobile,
where your user can take it home, access company resources
at home, take it on their vacation,
access company resources on the vacation.
It's not that, right?
So, they're run in kiosk mode.
They are purpose built just for Teams.
So, there are certain device management techniques
that will have to be applied for these devices
that are separate from your mobile
and your other Android devices.
STEPHEN ROSE: So, what are some of those best practices
as we take a look at them?
What are things that folks should keep
in mind as they're doing this?
KRUTHIKA PONNUSAMY: So, one thing to keep in mind is,
this is a kiosk-mode device.
We don't have Google Play services on this device.
We don't have ADB, so that is disabled,
which means, you know, there's no rooted firmware,
they're all production signed.
There are certain conditional access policies
and certain device policies that are unique
to these devices.
So, if you are a tenant admin
and you are looking to deploy this device in your tenant,
you will have a separate set of policies for Android mobile.
You'll have a separate set of policies
for your iPhone users, your, you know,
Mac and Windows PCs,
and you'll have a separate set of policies just for this.
STEPHEN ROSE: Okay, now I know there are some gotchas,
and you've actually put together a video
for us to go through that.
So why don't we take a moment, let's run that,
and then we'll come back and kind of point out
some of the top tools that are out there
and some of the things that we've done here.
So let's roll that video.
KRUTHIKA PONNUSAMY: We at Microsoft have published a list
of supported conditional access policies
that are applicable for Microsoft Teams devices.
These devices could be Teams Rooms on Windows,
Teams Rooms on Android, Teams Panels,
Teams Phones, or Teams Displays.
There are subtle differences in terms of supportability,
and this article provides the details.
In addition to that, we also have published
a list of supported device compliance policies,
again, based on device categories--
for example, for Teams Phones and displays
and other Android devices, as well,
Google Play Services is not an applicable solution.
We do not run GPS on our our devices,
and hence the policies that pertain to Google Play
services are not supported by our device types.
Some of the best practices for authentication policies
and for conditional access policies that we recommend
for shared device deployments include an example
of not enabling multifactor auth
as long as you know that the device is going to be
within a badged area.
Another example is if your deployment is a shared device,
please do not enable sign-in and frequency as a requirement
because by policy, sign-in frequency will expect you
to enter credentials or reenter credentials
into the Teams device at a particular frequency,
and you do not want to deploy a technician
to go into these shared areas and sign in periodically.
Let me walk through some of these conditions.
As a tenant admin, go into your AD admin portal,
and within the portal there will be a quick access
to access your conditional access policies.
Right there.
One of the most common features that we use
when deploying devices in shared areas is "Named locations."
Create a specific set of IP addresses,
and mark them into a location name--
for example, any of your offices that are
within a badged area, as long as you know the IP address
range, you are able to create a named location.
This should be very easy to acquire as long as you know
the deployment of your buildings.
Once we have that, let's leave that aside
and create a policy for common-area phones.
In this case, this could be for meeting room devices
for any of your devices in shared areas, right?
Create a policy,
and apply that policy to a specific user group.
In this case, the user group is "CAP users"
and includes all our CAP accounts within this user group.
And once you've created the user group,
for that particular user group
you can apply your set of policies.
In this example, I've actually not required
multifactor authentication because I know
that this is going to be a common-area device.
These users do not have access to the password
for these user accounts, and therefore this does not
also require multifactor authentication.
So, this is one deployment tactic
we could use for common-area phones.
The second one is sign-in frequency.
Sign-in frequency makes a lot of senses for user accounts.
When it is a user who wants to access their data,
depending on the requirements of the security
of your tenant, you can modify the sign-in
frequency policy from a few hours to a few days.
In my specific scenario, I've actually included all users
in my tenant to have a sign-in frequency of 15 days.
Every 15 days they would have to authenticate
with their credentials.
This does not make sense for my tenant
to apply these rules to a common-area phone.
So therefore I've excluded
the common-area user group from sign-in frequency.
This way, I know that the common-area phones
are deployed in a secure location,
and they do not require a sign-in frequency requirement.
I've turned this on.
Another policy that we could use, oops,
is for user devices, right?
So for users, I have created a group,
which is Personal users.
These are individual users trying to access Teams devices.
In that case, I've actually tried
a couple of permutations here.
As long as you are in a location
that is outside of the office network,
we have a set of policy requirements.
But once you are within an office network
and within the known location,
the named location of certain IP addresses,
we actually relax those policies.
There is no single solution for all deployments.
Each of our tenants have their own requirements.
Please make sure that your deployed devices
meet the requirements of your security,
but we have a lot of knobs that you can use
to modify policies.
STEPHEN ROSE: That was great stuff, Kruthika. Thank you.
What are the two or three biggest gotchas,
because that's a lot we just covered, but where's the one
or two places that people most often make a mistake?
KRUTHIKA PONNUSAMY: Most of the time we see that, you know,
when people deploy in common areas,
the devices in common areas,
they use policies that are applicable for personal devices,
and that's the most number of tickets that we get.
Think about sign-in frequency.
Think about using named locations, as you saw in the video.
You know the IP address
where the common-area device is going to be.
That device is not moving.
You know, apply policies that are applicable
just for those devices.
STEPHEN ROSE: Got it. So, biggest thing is Android phone,
Android device--two completely different things.
Don't treat them the same.
KRUTHIKA PONNUSAMY: Android mobile, Android phone device.
That's right.
STEPHEN ROSE: Yes. Got it.
All right, so I know there's some great test tools
and debugging setups, and also
we have a good piece on bulk sign-in.
Take a moment and kind of tell us about that
and where we can find some of that content,
because I know that will help, too.
KRUTHIKA PONNUSAMY: There will be links
at the end of the session
where, you know, we are pointing it
to our awesome support team,
where they've deployed some tools.
What they do is, you know, if there is a deployment issue,
if you see that your phone is not compliant
or the phone is not signing in,
our support team has written tools that you can run
as a tenant admin with PowerShell in your tenant.
And it lists the failures,
what you need to go and correct,
and what you need to go and change.
Please check that out.
Yep, and in addition to it, we hear customers
talking about, you know, provisioning
large devices in one go.
We're looking at it, you know,
bulk sign-in would be an awesome feature to have.
We are definitely working on that.
STEPHEN ROSE: All right. And you were saying
we're listening,
we're hearing, and let's chat about an opportunity.
You and I are both going to be at Enterprise Connect
in Orlando in March.
You will be there, I will be there.
So it's a great chance if you have questions,
if you're going to be there, you want to talk more deeply.
We're going to have lots of demos.
We have a really cool booth set up.
We have a lot of execs, a lot of folks talk to,
and you are going to be there, so people
can take their questions and potential grievances
directly to you there.
But you really want to hear all this stuff.
You want to hear what's working right and what isn't
so we can continue to make the product better, right?
KRUTHIKA PONNUSAMY: Absolutely.
We are here to just build your features.
So if you have any feature requests,
device requests, anything, you know, we are here.
STEPHEN ROSE: Awesome. Love it.
Kruthika, thanks for taking time out of your day
and being here.
Hopefully, this is helping you to better understand
the how and the why around some of the areas
that are not directly part of the Teams client
but all of those things that touch it.
On my behalf, and again,
thank you, Kruthika, for joining us today.
My name is Stephen Rose.
This has been "Inside Microsoft Teams."
Thanks for joining us.
We'll talk to you soon.
[Show theme music]