How to Deploy Applications to Microsoft Teams Rooms (MTR) with Intune Using Remediation Scripts

Introduction: The Challenge of Managing Microsoft Teams Rooms

Microsoft Teams Rooms (MTR) are purpose-built devices that bring seamless Teams meetings into physical conference rooms. However, if you’re an IT admin or consultant trying to manage these devices with Microsoft Intune, you may have already hit a major wall: you can’t deploy standard applications like Win32 or MSI packages.

In this post, I’ll walk you through:

  • Why app deployment fails on MTRs
  • How to use Intune Proactive Remediation Scripts to install apps anyway
  • A real-world script-based workaround you can implement today

This article is especially useful for IT administrators, Microsoft 365 consultants, and organizations managing MTR on Windows devices using Microsoft Intune.

What Are Microsoft Teams Rooms (MTR) Devices?

Microsoft Teams Rooms are specialized endpoints running Windows or Android, designed to facilitate video conferencing in meeting spaces.

This article focuses on MTR on Windows, which:

  • Boots into a kiosk-like shell
  • Uses a locked-down local user account (usually “Skype”)
  • Automatically launches the Teams Rooms app
  • Is managed differently from typical Windows endpoints

Why Are MTRs So Locked Down?

Because they’re designed to do one thing very well: run meetings reliably and securely. That means:

  • Minimal background processes
  • No user distractions
  • Reduced vulnerability footprint

Unfortunately, this also means limited support for app deployment using traditional Microsoft Intune methods.

Why Standard App Deployment Doesn’t Work on MTR

Let’s quickly review how app deployment in Intune normally works:

  • You upload a Win32 or MSI app
  • Intune pushes it to the device
  • The app installs silently in the background

But MTRs are a special case:

IssueDescription
Kiosk ShellMTR devices run a locked-down shell that prevents user interaction.
Limited Admin AccessThe logged-in “Skype” user doesn’t have full local admin rights.
Silent Installs Often FailEven SYSTEM-context installs can hang or fail silently.
Win32 App Deployment Not SupportedMTRs are excluded from full app deployment via Intune.

TL;DR: Intune treats MTRs like they’re manageable—but for apps, they’re basically off-limits.

What Can You Manage on MTR with Intune?

FeatureMTR Support?
Enroll in Intune✅ Yes
Configuration Profiles (Wi-Fi, Certificates)✅ Yes
Compliance Policies✅ Yes
PowerShell Scripts⚠️ Limited
Win32/MSI App Deployment❌ Not Supported
Store App Deployment❌ Not Supported
Remediation Scripts✅ Yes — this is our workaround!

The Workaround: Use Proactive Remediation Scripts

What Are Proactive Remediations in Intune?

Proactive Remediations are part of Endpoint Analytics in Microsoft Intune. They allow you to:

  • Detect issues on endpoints (e.g., missing apps or settings)
  • Run scripts in the SYSTEM context to remediate them

And because these scripts run as SYSTEM, they can bypass the user restrictions imposed by the MTR shell. That’s the secret sauce here.

Step-by-Step: Deploy Apps to MTR Devices Using Remediation Scripts

Step 1: Choose an Application

Pick an application with a silent installer. Examples include:

  • Zoom Rooms Plugin
  • Custom certificate tools
  • Remote support agents

Pro tip: Avoid apps that require UI interaction or restart the system.

Step 2: Host the Installer

Since you can’t upload Win32 apps, host the installer externally:

  • Azure Blob Storage with SAS token
  • SharePoint Online
  • A secure HTTPS server

Step 3: Write the Detection Script

This script checks whether the app is already installed.

powershellCopyEdit# Detect-Zoom.ps1
$app = Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*Zoom*" }
if ($app) {
    exit 0  # App is installed
} else {
    exit 1  # App is missing
}

Exit code 1 tells Intune that remediation is needed.

Step 4: Write the Remediation Script

This script installs the application silently.

powershellCopyEdit# Remediate-Zoom.ps1
$installerUrl = "https://yourstorage.blob.core.windows.net/apps/ZoomRoomsInstaller.msi"
$tempPath = "$env:TEMP\ZoomInstall.msi"
$logPath = "C:\ProgramData\ZoomInstall.log"

Invoke-WebRequest -Uri $installerUrl -OutFile $tempPath -UseBasicParsing

Start-Process "msiexec.exe" -ArgumentList "/i `"$tempPath`" /quiet /norestart /log `"$logPath`"" -Wait

Remove-Item $tempPath -Force

Store logs in C:\ProgramData\ for later troubleshooting.

Step 5: Deploy via Intune

  1. Go to Endpoint Security > Endpoint Analytics > Proactive Remediations
  2. Click + Create Script Package
  3. Upload both scripts (Detect and Remediate)
  4. Assign the policy to a dynamic group of MTR devices
  5. Set the schedule (e.g., once a day)

Tip: Filter devices by naming convention like MTR-*.

Real-World Example: Install Chocolatey on MTR

Let’s say you want to deploy Chocolatey to MTR devices to enable future package management.

Detection Script

powershellCopyEditif (Get-Command "choco" -ErrorAction SilentlyContinue) {
    exit 0
} else {
    exit 1
}

Remediation Script

powershellCopyEditSet-ExecutionPolicy Bypass -Scope Process -Force
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

This installs Chocolatey silently using PowerShell.

Security Tips for Remediation Scripts on MTR

Best practices to stay secure:

  • Use SAS tokens for Azure Blob Storage to avoid public links.
  • Avoid complex UIs or restarts in your install logic.
  • Sign your scripts with a trusted certificate if possible.
  • Log everything: install logs, errors, success flags.

How to Maintain This Workaround

Treat remediation scripts like code:

  • Version control with GitHub or Azure Repos
  • Store application versions and update logic
  • Schedule re-checks weekly or monthly
  • Rotate download URLs periodically if they expire

When Should You Use This Workaround?

Use CaseGood Candidate?
Small hotfix✅ Yes
Lightweight plugin✅ Yes
Large apps with UI❌ No
Mission-critical installs⚠️ Use caution

For complex applications, consider a manual install window, or coordinate with the OEM.

Alternatives to Intune Remediation Scripts

MethodNotes
Manual DeploymentGood for one-off fixes
OEM Management ToolsLogitech Sync, Poly Lens, etc.
Group PolicyWorks for Hybrid AAD Join MTRs
Teams Pro ManagementUseful for Teams config, not apps

Conclusion: MTR App Deployment is Possible—With the Right Tools

Deploying applications to Microsoft Teams Rooms using Intune isn’t supported natively—but that doesn’t mean it’s impossible. With a bit of scripting and smart use of Proactive Remediation, you can achieve automated, scalable, and relatively safe application installs.

This method:

  • Uses supported Intune features (Endpoint Analytics)
  • Works in the locked-down MTR environment
  • Scales across multiple devices and locations

Understanding Device Enrollment and Visibility in Microsoft Intune and Entra ID

Troubleshooting Errors Like 0x80180014 and Navigating Device Records in the Admin Portals

Introduction

Managing devices in a modern enterprise requires a clear understanding of how devices enroll into your organization’s management ecosystem, particularly in Microsoft Intune and Microsoft Entra ID (formerly Azure Active Directory). With the increasing adoption of mobile device management (MDM) and the demand for secure cloud identity integration, IT administrators frequently encounter various behaviors—and sometimes, errors—that can be confusing.

One of the more common challenges occurs when a device fails to enroll correctly, presenting cryptic error codes such as 0x80180014. This blog post provides a deep dive into how device registration and visibility work across Microsoft Intune and Entra ID. We’ll also unpack typical issues, explain where devices appear in each admin center, and how to cleanly troubleshoot enrollment errors.

This issue was thoroughly explored during a troubleshooting session with Carsten Lund Meilbak, the go-to expert for everything Microsoft Teams and Teams Meeting Room environments, where we investigated problems with a Microsoft Teams Room (MTR) device. During the session, we discovered how certain Autopilot scenarios could result in orphaned device records in Entra ID, preventing re-enrollment.

What Is Microsoft Intune?

Microsoft Intune is a cloud-based endpoint management solution that helps organizations manage user access, enforce compliance, and deploy apps and configurations to devices. Whether the devices are Windows, Android, iOS, or macOS, Intune serves as the command center for policy enforcement and inventory tracking.

What Is Microsoft Entra ID?

Microsoft Entra ID (previously known as Azure Active Directory) is Microsoft’s cloud-based identity and access management service. Devices can be registered, joined, or hybrid joined to Entra ID, and the identity status of these devices is critical for secure access, Conditional Access policies, and MDM enrollment flows.

Section 1: Device Lifecycle – From Registration to Management

Step 1: Device Registration in Entra ID

When a device first connects with a corporate identity, it can take one of several paths:

  1. Azure AD Registered (Workplace Join):
    • Typical for BYOD (Bring Your Own Device).
    • Appears under the user’s profile in Entra ID.
    • Usually paired with manual or conditional enrollment in Intune.
  2. Azure AD Joined:
    • Common for corporate-owned devices.
    • Full control over the device by the organization.
    • Required for Autopilot provisioning and device-based Conditional Access.
  3. Hybrid Azure AD Joined:
    • Devices are joined to on-prem Active Directory and then synced to Entra ID via Azure AD Connect.
    • Offers compatibility for legacy environments still using GPOs or SCCM.

Step 2: Device Enrollment in Intune

After a device is registered in Entra ID, it may also become enrolled in Intune:

  • Automatic Enrollment via group policies or Autopilot.
  • Manual Enrollment by end-users through “Access Work or School” in Windows settings.
  • Co-management Scenarios where both Intune and ConfigMgr (SCCM) share responsibilities.

This enrollment is what allows policies, apps, and configurations to be deployed to the device.

Section 2: How Devices Appear in Admin Portals

2.1 Microsoft Entra Admin Center

Link: https://entra.microsoft.com

Navigate to:

Microsoft Entra Admin Center → Devices → All Devices

Here, you’ll see all devices that are registered or joined to your Entra tenant.

Each record provides the following key information:

  • Device Name
  • Join Type (Azure AD Registered, Azure AD Joined, or Hybrid)
  • OS Type and Version
  • MDM Enrolled (Yes/No)
  • Compliant (Yes/No)
  • Owner (User Principal Name)

If a device shows up here but not in Intune, it might not be enrolled in MDM. You can confirm this via the MDM Enrolled column or by selecting the device and checking details.

2.2 Microsoft Intune Admin Center

Link: https://intune.microsoft.com

Navigate to:

Devices → All Devices

This view shows all devices that are successfully enrolled in Intune, either through automatic enrollment or manual addition.

Important fields include:

  • Compliance Status
  • Enrollment Type (Corporate, BYOD, Autopilot)
  • Primary User
  • Managed By
  • Last Check-In
  • Device Category

If a device is listed here but shows a warning or non-compliance, the issue often relates to Conditional Access, configuration profiles, or missing required apps.

Cross-Referencing Between Portals

It’s not uncommon for admins to find a device in one portal and not the other. Here’s what it typically means:

Found in Entra OnlyFound in Intune OnlyFound in Both
Device is only registered, not MDM-enrolled.Rare; usually due to stale objects or migration.Device is properly joined and managed.

A properly managed device should show up in both portals, and any inconsistency is a sign of an enrollment issue.

Section 3: Common Error – 0x80180014

What Does 0x80180014 Mean?

This error appears most often during the enrollment phase of a Windows 10/11 device. It typically means:

“The device is already enrolled.”

In other words, Windows believes the device is already managed, either because of a previous enrollment or residual data from a prior configuration.

Resolution Steps

  1. Check Admin Portals: Remove the device from both Intune and Entra if it still exists.
  2. Remove MDM Profile: Disconnect the work or school account in Settings.
  3. Use PowerShell: Run dsregcmd /leave to unjoin from Entra ID.
  4. Retry Enrollment: After cleanup, re-enroll the device manually or through Autopilot.

Section 4: Unable to Delete Device from Entra ID

If the device does not appear in Intune but is still stuck in Entra ID and can’t be deleted, follow these steps:

Step 1: Confirm Your Permissions

Ensure your account has one of the following roles:

  • Global Administrator
  • Cloud Device Administrator

You can verify your roles here: https://entra.microsoft.com → My Roles

Step 2: Check the Join Type

In the Entra Admin Center → Devices → All Devices, look at the device’s join type:

Join TypeDescriptionDeletion Method
Azure AD JoinedCloud-joined deviceCan be deleted directly if permissions allow
Azure AD RegisteredBYOD registrationCan be deleted directly
Hybrid Azure AD JoinedSynced from ADMust be deleted from on-prem AD first

If the device is Hybrid Azure AD Joined, delete it from Active Directory Users and Computers on-prem, then let Azure AD Connect sync the deletion.

Step 3: Graph PowerShell Method (Cloud-only Devices)

A. Install Microsoft Graph PowerShell SDK

Install-Module Microsoft.Graph -Scope CurrentUser -AllowClobber -Force

B. Connect to Microsoft Graph

Connect-MgGraph -Scopes "Device.ReadWrite.All"

C. Find and Remove Device

# Replace 'DEVICE-NAME' with the actual name
$device = Get-MgDevice -Filter "displayName eq 'DEVICE-NAME'"
Remove-MgDevice -DeviceId $device.Id

If you already have the Object ID, skip the lookup and run:

Remove-MgDevice -DeviceId "<device-object-id>"

Note on Autopilot Devices

In some scenarios, Autopilot devices can lose their connection to the Entra device object, especially if the device has been reset outside of Autopilot flows (e.g., manually or using third-party imaging). This causes:

  • The Autopilot object to remain in the Autopilot portal
  • The Entra ID device to become orphaned
  • Intune showing no matching device

This was exactly the case during a troubleshooting session with Carsten Lund Meilbak, where we were diagnosing an enrollment failure on a Microsoft Teams Room (MTR) device. The Entra ID device had become orphaned, preventing the MTR from successfully enrolling. Manual deletion of the Entra device object was required to resolve the issue.

In these cases, the orphaned Entra ID device must be deleted manually as described above.

Conclusion

Understanding how devices register and appear in Microsoft Intune and Entra ID is crucial for device management. Cross-portal visibility, proper cleanup, and the ability to handle errors like 0x80180014 efficiently ensure a secure and manageable environment for both users and administrators.

If device records are left stale or orphaned, they can interfere with future enrollment attempts, Autopilot deployments, and compliance policies. Always keep your portals clean and verify device join and MDM status regularly.