Managing Microsoft Teams Rooms with Intune
Published Dec 16 2019 03:54 PM 129K Views

We’ve heard a few questions recently from customers looking for guidance how to manage your Microsoft Teams Rooms devices with Intune. This post answers a few of the frequently asked questions and provides general guidance. If you’ve discovered additional tips or tricks on your deployment journey, or have other feedback or suggestions, let us know by commenting on this post!

 

Picture1.png

 

Teams Room devices can be enrolled and managed by Intune to provide many of the device management and security capabilities available to other endpoints managed by Intune. Because these devices run Windows 10 under the hood, several of the Windows 10 features will be available to use, but many are not applicable or recommended.

 

In break this post, we'll discuss recommendations for these Intune feature areas:

  • Enrollment
  • Windows 10 configuration profiles
  • Compliance policies
  • Conditional Access
  • Grouping and targeting

 

Enrollment

Recommendation: Use an Intune DEM account to Azure Active Directory (Azure AD)-join the device from Windows Settings.

 

Windows 10 based Teams devices arrive from suppliers prepared with an OS image, user accounts, and pre-configured profiles. For a smooth, automatic MDM enrollment, sign in to the device with the admin profile and perform the Azure AD join from the Settings menu. We recommend you use an Intune device enrollment manager (DEM) account specifically because Teams Room devices are shared and DEM accounts are more practical for managing shared-device scenarios. Learn more about DEM accounts here.

 

The Teams Rooms resource account can be used for Intune enrollment, but it should not be used for Windows 10 sign-in on the device because it can cause issues during automatic sign-in of the Microsoft Teams Room application account. Please use a tenant or device admin account to administer local device settings.

 

An additional tip is to name Teams Room devices with a prefix that allows devices to be grouped dynamically. For example, use “MTR” for meeting room. You can rename devices with either a Windows 10 configuration policy or manually per device in Intune. We’ll talk about this approach a bit more below, under Grouping and Targeting.

 

Depending on your current scenario, there are several other enrollment options available:

  • Use Windows Configuration Designer to create a Windows 10 provisioning package that performs a bulk Azure AD Join. Details are here.
  • Customers who have some devices domain joined and/or managed by Configuration Manager may choose to enable co-management or initiate an Intune enrollment via the Enable automatic MDM enrollment using default Azure AD credentials Group Policy setting.

 

For more details about available enrollment methods, see Intune enrollment methods for Windows devices.

 

Windows 10 Configuration Profiles

Recommendation: Use Windows configuration profiles to configure device settings that you need to change beyond the shipped defaults.

 

The following Windows 10 Configuration Policy types may be used with Windows 10 based meeting room devices:

 

Profile type

Can you use the profile?

Administrative Templates

Yes

Certificates

Yes

Delivery Optimization

Yes

Device Firmware Configuration Interface

Check for supported hardware here

Device restrictions

Yes

Edition Upgrade

Not supported

Email

Not recommended

Endpoint Protection

Yes

eSim

Not supported

Identity Protection

Not supported

Kiosk

Not supported

PowerShell Scripts

Yes (Devices must be Azure AD joined or hybrid Azure AD joined)

Security baselines

Not supported

Shared multi-user device

Not supported

VPN

Not recommended

Wi-Fi

Not recommended

Windows Information Protection

Not recommended

 

NOTE: “Not recommended” in the table means that the Windows 10 policy type is not a good fit for Teams Room scenarios. For example, Team Room devices are not enabled for Wi-Fi, therefore it’s not recommended (or necessary) to configure a Wi-Fi profile. Learn more about available configuration policies here: Create a device profile in Microsoft Intune.

 

Compliance policies
Recommendation: Use compliance policies to achieve the desired security level for your Teams devices.


You can use compliance policies on your Teams Room devices. Make sure to create the appropriate exclusions for any existing Windows 10 compliance policies that are currently deployed in your organization to All devices.  For example, you may have configured the setting Maximum minutes of inactivity before password is required in a policy for all Windows 10 desktop devices but this would result in a poor meeting room experience if applied to Teams Room devices. If you currently have Windows 10 compliance policies deployed to large groups of devices, make sure you use the Exclude group feature so that you can target a more specific compliance policy for the Teams Room devices.


For detailed guidance, see Use compliance policies to set rules for devices you manage with Intune.

 

Conditional Access

Conditional Access policies with only location-based conditions can be applied to Microsoft Teams Rooms accounts at this time.  Microsoft is currently working on updates that will allow additional conditions to be set, such as device compliance.

 

Grouping and Targeting

It’s helpful to use Azure AD dynamic groups to effectively group all Teams Room devices. To help implement this more easily, use a naming standard during deployment/enrollment. For example, as mentioned earlier in this article, if you want to prefix all device names with “MTR," you can use “MTR-%SER%” to name your devices, which will append the device serial number to the prefix. Then you can use the dynamic group feature to group together all devices that start with MTR. Keep in mind, Azure AD dynamic groups is an Azure AD P1 feature.

 

Picture2.png

NOTE: Device renaming via Intune device management is supported on Azure AD-joined devices but not hybrid Azure AD-joined devices.

 

When targeting configuration profiles, compliance policies, and apps it’s a good idea to target a group that contains devices rather than users. The reason for device-group assignment is that Teams Room devices sign in to Windows with a local user account (instead of an Azure AD user account) and during sync with Intune, would not request any user-assigned policy.

 

More info and feedback

As always, we want to hear from you! If you have any suggestions, questions, or comments, please comment below. You can also tag @IntuneSuppTeam on Twitter.

 

Blog post updates:

  • 1/21/2022: Updated Windows 10 configuration profile table to show that security baselines are not supported, removed requirement for Azure AD Premium (now included), additional minor edits.
  • 1/27/2021: Updated the More info and feedback section.
  • 4/20/2020: Updated the post to include an enrollment best practice: " The Teams Rooms resource account can be used for Intune enrollment, but it should not be used for Windows 10 sign-in on the device because it can cause issues during automatic sign-in of the Microsoft Teams Room application account. Please use a tenant or device admin account to administer local device settings.
  • 3/6/2020: Updated the post to clarify what works with Conditional Access and Microsoft Teams Rooms. Removed mention of device compliance checks for CA; that feature is coming.
77 Comments
Brass Contributor

Is there an easy way to control the Microsoft Teams Room app updates via Intune -  to allow us to hit a testing ring and actually confirm we have no unintended side-effects before we push out across our entire meeting room fleet?

We were stung by a previous room app update which clearly changed something in how certs were used for Skype On-prem - and took out the one entire office that had Teams rooms for couple of days a our knowledgeable team members were also on leave.

We are now all O365, but also all on a Teams Room device -so don't want to repeat that scenario if there is anyway to avoid it.

Also would give us time to update our documentation for the room every time the GUI changes.


Brass Contributor

->How to keep Autologon working with an MTR that is Azure AD joined and managed by Intune? Currently the local "Skype" account autologon fails.

->What is the added value to use DEM vs MTR Room Account (which also has an Intune license) to register the device?

 

-Can we have a default best practices for MTR's?

 -Autopilot

 -Specific Conditional Access Rules/Exclusions.

Iron Contributor

Do MTR support Modern Authentication

Iron Contributor

When we will be able to Upgrade, manage MTR's from Teams Admin center, what is the pre-requisites for MTR management: SCCM, Intune or Hybrid

Microsoft

@yankeedoodlegandy , The "Microsoft Teams Room" app is a store signed app which means it would automatically be updated via the store. One possible solution to pin the app version would be to disable store updates. When ready to move to the next version of the app you could use Intune to deploy the it as an LOB app.

 

Microsoft

@Frank Rijt-van 

- I have not heard about the autologon not working after AADJ. I wonder if you have a policy configured in your environment that breaks it?

- DEM accounts are used for shared devices in Intune. When shared devices are enrolled with DEM accounts, Intune knows they are shared instead of a single-user device. DEM accounts can also enroll more than 15 devices (A limit that exists for normal accounts). You could possibly make the MTR room account a DEM account.

- We are working with customers on establishing further best practices in the areas you asked for. Stay tuned. 

Microsoft

@MTayal Let me get back to you on responses to that after discussing with the Teams Admin Center team.

Copper Contributor

Are there any other parameters available which could be used from a dynamic group query perspective? I.e. something which could indicate that it IS a valid MTR installation?

 

Excluding devices from compliance- and CA policies doesn't really go well with allowing BYOD registrations and having zero trust/Internet based networks without known IP ranges in the offices where the MTR will be placed and having manual groups is too much of a hassle to even think of in larger organizations with huge but smaller branch offices with "JIT infrastructure" :D

Copper Contributor

@Scott Duffey 

 

We are also seeing the device failing to auto login after AADJ.  We currently have no MDM profiles targeted to the device.  It seems like the AADJ + Intune Manage process is breaking the AppLocker / Kiosk Policy.  Any ideas?

Brass Contributor
Are there any plans to support Autopilot capability for MTR and also deploy SkypeSettings.xml via Intune or better provide a configuration profile to configure Skype/Teams settings?
Microsoft

@Jeremyb - This is just a hunch, but I wonder if its the Windows Hello for Business configuration breaks the AutoAdminLogon? I say that because it defaults to "on" for AADJ'd devices. You can create an Intune policy to disable WHFB and target to MTR device groups. If it is that, we should definitely update this guidance.

Microsoft

@Kapila Munaweera We are looking into how we can improve the setup experience for MTRs all up. This post is just a first step in that direction.

Microsoft

@MartinGustafsson I dont think we do have that today based on the properties exposed for AAD Device Dynamic groups today. https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-dynamic-membership.... Its a good piece of feedback though that we'll consider as we improve the management experience for MTR's.

My point about "excluding" from CA/Compliance policy was more about taking into consideration how and where these devices are used and applying policies based on that rather than subjecting to them the same standard as Information Workers, Mobile Devices and Desktop PC's. It wasn't supposed to be prescriptive.

Copper Contributor

@Scott Duffey  Agreed, I fully understand this is only recommendations and not prescriptions. Just pointing out the risks with the OTC recommendations :face_with_tears_of_joy:

Brass Contributor
@Jeremyb - Try disabling ESP (enrolment status page) if it resolve the issue.
Copper Contributor

Hi @Scott Duffey Hello is disabled, and ESP is not configured.  This worked in 1809, in upgrading the device to 1903 autologin seems to be broken.  Seems to be a regression.

Microsoft

@Jeremyb I tested this today (Upgrade from 1809->1903) and did not get the same repro. Can you please raise a support call with the @Intune Support  Team.

Brass Contributor

We have been managing our MTR devices through Intune for last 2 years including .  Our AADJ devices are set to automatic enrollment to Intune. Also we been doing nightly reboots and wallpaper management by pushing powershell scripts through Intune. Monitoring agents and windows update is also pushed through Intune app. With addition of advanced capabilities it has become easy to manage MTR devices with Intune.

One big piece that has been missing is support of Modern auth by MTR devices. Is there any timeline when we can expect this?

Support for EWS for basic Auth is planned to end Oct 2020 I hope this is available way before that.

 

Brass Contributor

Second the question about Modern Auth. Any updates?

Microsoft

@Sukhdev Rehal @chrisbuesold . Thanks for the comments.  We are targeting a 2020 Q1 release for Modern Auth on MTR devices.

Iron Contributor

@Scott Duffey 

Hi, Is there any response on My earlier query, Management of MTR from Teams Admin Center, what is the prerequisite for same and will it be supporting all scenarios whether configuration is done using Intune, SCCM or Hybrid

Thanks!

Copper Contributor

@Jeremyb @Scott Duffey @Intune_Support_Team 

After doing AADJ on Win10 1903 Teams Room the default logon to local Skype account is not working to due change of default login domain to e.g. corp.com. To fix Skype autologon issue, the update of registry key is needed to add "local\"prefix.

 

Here the registry key to be modified: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Change DefaultUserName entry value from "Skype" to "local\Skype". 

https://support.microsoft.com/en-us/help/324737/how-to-turn-on-automatic-logon-in-windows

 

After registry change and reboot, all is back to normal (I hope).

Microsoft

@Maheshwar Tayal - Sorry I don't have any information to share on Teams Admin Center roadmap at this time. Note that Intune Hybrid mode is deprecated -  https://docs.microsoft.com/en-us/configmgr/mdm/understand/hybrid-mobile-device-management#deprecatio...

Brass Contributor

@yankeedoodlegandy @Scott Duffey you can also control App Store updates from Intune or on the local App Store app itself (via … settings).

 

I'm not too sure how you would deploy the app as an LOB app as I've never seen any visibility of the app on the store to see how you can do anything like that ?

 

Is there an easy way to control the Microsoft Teams Room app updates via Intune -  to allow us to hit a testing ring and actually confirm we have no unintended side-effects before we push out across our entire meeting room fleet?

 
 

image.png

Microsoft

Thanks @Jed Ellerby for the useful comments! You can get the APPX packages and dependencies from the deployment kit . We're working with Teams to make this package easier for you to find.

Brass Contributor

@Jed Ellerby  - Thanks for the note about Intune - trialing out the control of App Store updates via profile now.

Copper Contributor

Hi @Scott Duffey,

Can you confirme me that we can use the Software Update feature on Intune to manage OS Quality and Feature Updates of MTR?

Because I configured it like below, but I received this error message Servicing channel = ERROR: -2016281111 (Not applicable for this device) :

clipboard_image_0.png

thanks for your help

Microsoft

@mohamed ait salah Can you please open a support ticket for Intune to get to the bottom of the error message?

Brass Contributor

@Scott Duffeywhat is the Microsoft recommendation when the "Require MFA to join AAD" is set in AAD but to avoid MFA prompt when MTR enrolling to Intune?

 
 
 

mtrintune.PNG

Copper Contributor

@Kapila Munaweera Why would you want someone to be able to join devices to your AAD without MFA? (Honest question) 

Microsoft

@Kapila Munaweera One option would be to use a use Windows Configuration Designer to create a Windows 10 Provisioning Package that performs a bulk Azure AD Join. As long as the package was created by an IT admin who authenticated with MFA during the creation process, then the enrollment would proceed.

Copper Contributor

@Scott Duffey thanks for your answer, but my first question is :

Can you confirme me that we can use the Software Update feature on Intune to manage OS Quality and Feature Updates of MTR?

If yes , do you have an official link to define the properties for MTR.

 

thanks very much for your help.

Brass Contributor

@Scott Duffey Thanks for the reply. I thought about both bulk enrolment and using a DEP account but the challenge then is they enrolled as a shared device and there is no conditional access support for them, which we require to protect these accounts.

 

Capture1.PNG 

Microsoft

@mohamed ait salah - The teams application itself configures Features updates based on this https://docs.microsoft.com/en-us/MicrosoftTeams/rooms/rooms-lifecycle-support#windows-10-release-sup...

. So we wouldn't recommend trying to configure them with Intune.

Iron Contributor

@Scott Duffey 

The teams application itself configures Features updates based on this https://docs.microsoft.com/en-us/MicrosoftTeams/rooms/rooms-lifecycle-support#windows-10-release-sup...

. So we wouldn't recommend trying to configure them with Intune.

what is the recommendations for certificates, should we use Public vs Private

 

Copper Contributor

@Scott Duffey thanks for your answer.

If i correctly understand, nothing to configure in Intune or any others third-party device management services to manage windows update or teams room software updates. Teams room system will automatically get update and install it and reboot during maintenance hours.

 

Brass Contributor

Hi experts,

 

Any idea how to manage the default local admin account via Intune?

Do you disabled it or changed the password from Intune?

 

Thanks!

Brass Contributor

Conditional Access

Conditional Access policies with only location-based conditions can be applied to Microsoft Teams Rooms accounts at this time.  Microsoft is currently working on updates that will allow additional conditions to be set, such as device compliance.

 

Is there any ETA in supporting device compliance as MTR now support modern auth?

 

https://docs.microsoft.com/en-us/microsoftteams/rooms/rooms-authentication

Brass Contributor

we have recently put a test device onto intune and get the failed log in to skype - i tried the following makes no difference to ours 

After doing AADJ on Win10 1903 Teams Room the default logon to local Skype account is not working to due change of default login domain to e.g. corp.com. To fix Skype autologon issue, the update of registry key is needed to add "local\"prefix.

 

Here the registry key to be modified: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Change DefaultUserName entry value from "Skype" to "local\Skype". 

https://support.microsoft.com/en-us/help/324737/how-to-turn-on-automatic-logon-in-windows

 

After registry change and reboot, all is back to normal (I hope).

Brass Contributor

We're currently trying to deploy Bitlocker via Intune using Endpoint Protection configuration profile to the MTR.  However, the Deployment status shows Not Applicable. Does Bitlocker supported for IoT Enterprise via Intune, any idea?

 

Thanks.

1. The Bulk Token enrollment method. Just adding a comment here. My experience is that the bulk token stops working after 14 days, and CA complains about MFA on the Package Account. My thinking is that after 2 weeks the "MFA IN THE CLAIM" is expired, and it is not renewing. So excluding the package account from MFA requirements and removing "Require MFA to Join AAD" in CA fixed that for me. The other option that works is to exclude package accounts on location (IP Address) - Trusted location. @Scott Duffey 

Copper Contributor

Hey Everyone,

Doing a bulk enrollment method, and I am unable to deploy a Win32app or configurations.  I assume I have to log on once with an AzureAD user account after enrolling?  I am basically getting errors in the IME log that state it’s trying to impersonate and failing to get an AAD token.  I have also tried just using the DEM account to join.  But again I assume I have to switch users from the Skype account and log in with an AzureAD account to get the ball rolling.  Please confirm or if I am misunderstanding.

 

Failed to get AAD token. len = 34 using client id xxxxxxx and resource id xxxxxxxx, errorCode = 3399548929

Need user interaction to continue.
AAD user check is failed, exception is Intune Management Extension Error.

 

Let me know if more information is needed.

Copper Contributor

Dear All

 

How do you join your MTR's to AAD and then enroll them to Intune. 

I did every configuration on the Intune side (Enrollment restrictions, license, enrollment target, ....).

Then i go on the MTR in the Access work or school settings, Connect, Add to Azure AD, Sign in with my informations and then i get the error in the logs describes the follow: MDM Enroll: Failed (Unknown Win32 Error code: 0x80192ee7) or on the work settings, see attached.

 

Proxy is set to any any for the tests. It seems that we don't have any network. We use this Crestron device: https://www.crestron.com/Products/Workspace-Solutions/Unified-Communications/Crestron-Flex-Integrato...

 

Thanks in advance for every small hint
Worksetting failureWorksetting failureEventviewerEventviewer

Brass Contributor

@Scott Duffey 

 

We are doing an Azure AD Join by Settings > Accounts > Access Work or School > +Connect > Join this device to Azure Active Directory  and signing in with DEM account.  The device successfully joins AAD but we are no longer able to use the local MTR Admin account.  

 

When logging in to Windows, the Admin account is no longer listed.  You have to choose 'Other user' and am prompted to sign in to Work or School account.  Trying to use the Admin account fails.  In your post it states an option to use 'device admin account to administer local device settings."

 

brcallicott_0-1601650001586.png

 

Copper Contributor

@brcallicott  I believe this was the same issue we ran into, where we had to use .\admin to login to the local admin account.

This may be solved with the suggestion Krzwen came with September 1st. 

have not tested this yet myself.

 
Copper Contributor

Hello Everyone, 

 

I am facing the same issue as one the user mentioned. We have enrolled MTR devices using a DEM account, it got auto enrolled in MDM and is now visible in Intune. Now, I'm unable to deploy MSI or Win32 apps on the Machine. There are not error to found in the logs other than AAD token failure.

 

There are no logs generated on under the Devices > Managed App. Not able to find anything that can help. We had a call with MS and one of the guys was from MTR team and he specifically mentioned that use DEM Account > Auto Enrollment and App installation should follow however it is not happening. 

Copper Contributor

Hello everybody,

 

@Scott Duffey - Thanks alot for the article!

 

I'm looking for some recommendations or best practices regarding conditional access, configuration profiles, conditional access, update rings and endpoint security for MTR clients enrolled in Intune. 

 

Any help would be highly appreciated!

Brass Contributor

Link to DEM accounts is broken "The additional recommendation to use an Intune Device Enrollment Manager (DEM) account is due to these meeting room devices being a shared device rather than one that has User-Device association in Intune. DEM accounts are used for shared device scenarios. Learn more about DEM accounts here."

Copper Contributor

Hi everybody,

 

We've deployed a lot of Team Room Systems where I work and encountered the dreaded "autologon" issue. I opened a ticket with MS Support but didn't get any help. I am posting my experience here and the solution in case it helps someone out there.

 

 

First, some background about our Team Room Systems (you can then decide if you are in a similar environment)...

 

- All our Team Room Systems are domain joined to our Active Directory. This also creates an object for them in Azure AD and it enrolls the computer account of the room in InTune.

- All of them have a GPO applied to them that pushes the "AdminAutoLogon" and all the other appropriate settings to make sure the rooms start correctly and autologin with the "Skype" user account after their daily reboots.

- Keep in mind that we also use InTune to manage mobile devices and some Windows 10 devices (this becomes important later).

 

 

The issue...

 

As many others have experienced with their Team Room Systems, the "autologon" feature did not work or stopped working for unknown reasons.

 

For us, if we looked on the affected Team Room Systems, we could see the warning "The autologon setting has been removed because the EAS policy is set" message in Event Viewer -> Applications and Services Logs\Microsoft\Windows\Authentication\Operations.

 

And if we looked in the Registry, under "HKLM\SYSTEM\CurrentControlSet\Control\EAS", there was a "Policies" folder with a value of "5" in it.

 

If we deleted the "HKLM\SYSTEM\CurrentControlSet\Control\EAS\Policies" registry folder (and MDM sub-folder) and rebooted the room, the problem was temporarily resolved... but something was adding back the "Policies" folder and settings in the registry during the course of the day and the problem would just come back the next day.

 

 

The root cause...

 

1 word: InTune.

 

But to be more specific... 3 words: something in InTune.

 

I did a lot of research and I discovered that something in InTune was pushing a very specific registry key down to the Team Room Systems (more on that in the "solutions" below).

 

Unfortunately, I looked like a mad man at all our InTune compliance policies and settings that we push down and I could not find the exact InTune Compliance Policy or InTune Configuration Profile that was pushing down the "DeviceLock" features that you will read about in the next section... so let's jump to the solution...

 

 

The solution to my problem (and hopefully yours)...

 

Part 1 - Check if this solution applies to you...

 

  1. Log into your Team Room System and open up the Registry Editor.
  2. Go to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\"
  3. There will be a folder with a GUID under the "Accounts" key: make a note of the GUID that is shown there. That is your "EnrollmentID". It's some sort of magical GUID that links that specific machine to your InTune subscription. Note that the EnrollmentID is unique per machine.
  4. Go to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers" and locate the folder under that key that has the same GUID as your EnrollmentID.
  5. Under the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers\[ENROLLMENTID]\default\Device\" check to see if you have a "DeviceLock" folder.
  6. If you have a "DeviceLock" folder, check to see if you have keys like "DevicePasswordEnabled", "AllowSimpleDevicePassword", etc...
  7. IF you have those keys then this solution should apply to you...

 

So, if you see the keys mentioned in Step 6, try the following...

 

Part 2 - Exclude the Team Room System(s) from InTune...

 

  1. Create a security group in AD or in Azure AD (do as appropriate in your environment) and call it "Team Room Systems - InTune Exclusion" (or whatever you want).
  2. In that new security group, put all the computer accounts of your Team Room Systems.
  3. Now, log into InTune.
  4. Go to "Devices -> Compliance Policies".
  5. In each Windows 10 Compliance Policy listed there, add the group you created with the room as an Exclusion to the policy (it's in the "Assignment" section of the policy).
  6. Once you have modified all your Windows 10 Compliance Policies, go to "Devices -> Configuration Profiles".
  7. In each Windows 10 Configuration Profile listed there, add the group you created with the rooms as an Exclusion to the profile.

 

Part 3 - Clean up the Team Room System(s) registry...

 

The "catch-22" with InTune is that not all settings that are pushed down to the registry are deleted or "reverted" when a machine is excluded from InTune... so you need to do some manual cleanup in this case.

 

  1. Log into your Team Room System.
  2. First, let's "sync" the changes from InTune by going to "Start -> Settings -> Accounts -> Access work or School".
  3. Click on the "Connect to [CompanyName Azure AD] and then click on "Info".
  4. In the "Managed by CompanyName screen", scroll down and click on "Sync".
  5. Wait for the sync to finish.
  6. Now for the fun part: open up the Registry Editor.
  7. Go to the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EAS" key.
  8. Under the "EAS" key, delete the "Policies" folder (and MDM sub-folder if it exists).
  9. Go to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\"
  10. There will be a folder with a GUID under that "Accounts" key: make a note of the GUID that is shown there. That's your "EnrollmentID".
  11. Go to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers" and locate the folder under that key that has the same GUID as your EnrollmentID.
  12. Under the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers\[ENROLLMENTID]\default\Device\" go to the "DeviceLock" folder.
  13. Delete all the keys in the "DeviceLock" folder: keys like "DevicePasswordEnabled", "AllowSimpleDevicePassword", "AlphanumericDevicePasswordRequired" should be deleted. Seriously, feel free to delete all the keys in there.
  14. Now, this is important, go to the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock" registry folder.
  15. This is where the settings from each Policy Provider are copied into and this indicates which settings are currently active! So, you need to delete all the keys you find in there... for example "DevicePasswordEnabled", "DevicePasswordEnabled_ProviderSet", "DevicePasswordEnabled_WinningProvider",  "AllowSimpleDevicePassword", "AllowSimpleDevicePassword_ProviderSet", etc, etc... there might a bunch of keys in there to delete so have fun deleting them all.
  16. Once your "spring cleanup" of the registry is done, open a command prompt in admin mode.
  17. Issue a good ol' GPUPDATE /FORCE to ensure that the "AdminAutoLogon" and other settings that are supposed to be pushed by your GPO are applied to your domain joined Team Room System and are set correctly.
  18. If you want to be paranoid, go back to the Registry Editor and then go to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"... and verify that "AdminAutoLogon" is set to "1" and that the "DefaultUserName" user name is set to "Skype" as it should be (as per your GPO).
  19. When you are ready, close everything and reboot the Team Room System.
  20. Finally, over the next few days, monitor the room to make sure the "Auto Logon" thing works correctly.

 

As I said, this is what "fixed" it for me... hopefully, this will help someone, somewhere or at least give you a clue that will point you in the right direction... and good luck!

 

Marc

 

 

Copper Contributor

@cgolebiowski Did you ever solve that error? I have an autopilot deployment with the same error:

Failed to get AAD token. 

Need user interaction to continue.

AAD User check is failed, exception is Intune Management Extension Error

 

Cheers

Version history
Last update:
‎Nov 30 2023 04:15 PM
Updated by: