Hi Tim. At the time of this recording, Azure AD P1 was not an entitlement included with the Teams Rooms Standard license. Fortunately, this got added at the end of 2021 so you don't have to worry any more about having the right licensing any Conditional Access when using a Teams Rooms license.
Great video! But I am not really sure why you use the filter. The filter only makes sure that the compliance policy is being deployed to the correct device model. But you have created a dynamic user group - if a user signs in on the device the deployment will be correct anyway.
Great content to secure MTRoA deployment!all works with Poly but had trouble with Logitech Rally Bar Mini. It runs on Android 10 which does not support corporate identifiers. Any suggestions how to make it as corporate device and retrieve “compliance”?
It's not the device itself that is directly responsible for a corporate identifier. Rather you add the serial number of the device to the "Corporate device identifiers" table in Intune. When Intune sees a device sign-in with that serial number, it knows that it is a corporate-managed device and then routes it that way. I'm finally getting a Logitech Rally soon so I'll run it through the steps and see if it exhibits some quirky behavior.
There is one fundamental thing I still dont get my head around: Why do we have to have two conditional access policies? Same question phrased differently: What did we actually gain with the GRANT policy? Wouldn't the block policy be enough to block out unwanted signins? The devices were allowed to sign in BEFORE setting up conditional access, so why do we need a grant policy "all of the sudden"? And btw: What happens when neither of the two policies (grant vs block) apply? If it defaults to grant, what's the point? OR will it default to block? If so, why and where did you change this from before setting up conditional access? Thanks for any help!
Without any Conditional Access policies, the devices can sign in. What we did was set up a filter that basically says "if a device signing in matches these parameters, perform additional checks to validate the sign in.". If the sign in is valid (correct username/password, known IP/location, etc.) then Grant the sign in. If none of the CA policies apply, then we are not applying Conditional Access to the sign in. All Conditional Access does is require more information before approving the sign in. In a real-world environment, there would be many other CA policies to cover Windows or Mac desktop sing-ins and iOS or Android mobile sign ins, This CA policy would slot in with those policies. Does that help?
I took the HDMI out of the MTRoA and put it into an HDBI-USB capture device, then used the vendor-supplied software to show the HDMI. In this case, I used an Elgato device along with their 4K Capture utility.
i think the licencing part is wrong, Meeting room licences already includes a premium P1 licence and an intune licence ans same with common area phones
It's definitely wrong nowadays. But it was accurate last year when recorded! :) Intune and AAD P1 were both added to the Teams Rooms and the Common Area license in the past year, after we recorded this.
For Intune, yes as none of this is "secret sauce". Leveraging the proper Intune policies and procedures to optimally manage Teams devices? Keep an eye on the Teams devices section of Docs as we will be publishing some detailed guidance soon(TM).
Thanks alot for this video! This entire video helped me with teams rooms, conditional access and intune in my company.
Glad it helped!
Amazing video Michael, I have pointed so many customers and resellers in this direction. I even made my own tenant work now ;-)
In the Conditional Access Policy, I recommend adding "Intune Enrollment" as an exception to your CA policy.
2 minutes in they tell you that you need AAD P1 to use conditional access. However AAD P1 is a component license of the Teams Rooms Standard license.
Hi Tim. At the time of this recording, Azure AD P1 was not an entitlement included with the Teams Rooms Standard license. Fortunately, this got added at the end of 2021 so you don't have to worry any more about having the right licensing any Conditional Access when using a Teams Rooms license.
Great video!
But I am not really sure why you use the filter.
The filter only makes sure that the compliance policy is being deployed to the correct device model. But you have created a dynamic user group - if a user signs in on the device the deployment will be correct anyway.
And what if they login to a different device. The filter ensures the right policy applies to the right device.
@9:01 As far as I know an account can enroll upto 15 devices (The default is set to 5 but it can be changed to 15).
Great content to secure MTRoA deployment!all works with Poly but had trouble with Logitech Rally Bar Mini. It runs on Android 10 which does not support corporate identifiers. Any suggestions how to make it as corporate device and retrieve “compliance”?
It's not the device itself that is directly responsible for a corporate identifier. Rather you add the serial number of the device to the "Corporate device identifiers" table in Intune. When Intune sees a device sign-in with that serial number, it knows that it is a corporate-managed device and then routes it that way. I'm finally getting a Logitech Rally soon so I'll run it through the steps and see if it exhibits some quirky behavior.
Very informative - will you be doing for teams rooms on windows and teams phones soon as well?
+1 That would be very cool.
I think we'll record an MTRW companion piece in the next week or 6. :) My schedule is really busy right now but I think I can sneak it in next week.
There is one fundamental thing I still dont get my head around:
Why do we have to have two conditional access policies?
Same question phrased differently:
What did we actually gain with the GRANT policy? Wouldn't the block policy be enough to block out unwanted signins?
The devices were allowed to sign in BEFORE setting up conditional access, so why do we need a grant policy "all of the sudden"?
And btw:
What happens when neither of the two policies (grant vs block) apply? If it defaults to grant, what's the point?
OR will it default to block? If so, why and where did you change this from before setting up conditional access?
Thanks for any help!
Without any Conditional Access policies, the devices can sign in. What we did was set up a filter that basically says "if a device signing in matches these parameters, perform additional checks to validate the sign in.". If the sign in is valid (correct username/password, known IP/location, etc.) then Grant the sign in.
If none of the CA policies apply, then we are not applying Conditional Access to the sign in. All Conditional Access does is require more information before approving the sign in.
In a real-world environment, there would be many other CA policies to cover Windows or Mac desktop sing-ins and iOS or Android mobile sign ins, This CA policy would slot in with those policies.
Does that help?
01:30 How do you capture the MTRoA device screens?
I took the HDMI out of the MTRoA and put it into an HDBI-USB capture device, then used the vendor-supplied software to show the HDMI. In this case, I used an Elgato device along with their 4K Capture utility.
i think the licencing part is wrong, Meeting room licences already includes a premium P1 licence and an intune licence ans same with common area phones
It's definitely wrong nowadays. But it was accurate last year when recorded! :) Intune and AAD P1 were both added to the Teams Rooms and the Common Area license in the past year, after we recorded this.
Is there actual MS documentation for this process??
For Intune, yes as none of this is "secret sauce". Leveraging the proper Intune policies and procedures to optimally manage Teams devices? Keep an eye on the Teams devices section of Docs as we will be publishing some detailed guidance soon(TM).