Tag Archives: Microsoft Teams

How to Remove Classic Microsoft Teams with PowerShell and Intune Proactive Remediations

Posted on by
Reply

Microsoft officially retired Classic Teams on July 1, 2025, and the client is no longer functional. Despite this, many organizations still have remnants of Classic Teams scattered across their Windows device estate. This is not just a cosmetic issue. Classic Teams no longer receives security updates, the per-user installation model wastes disk space, leftover shortcuts confuse users, and end-of-life software can put you out of compliance. If you have been putting off the cleanup, now is the time to remove Classic Teams from your environment.

In this post I am sharing three PowerShell scripts that handle different scenarios, from a one-off standalone removal to a fully automated Intune Proactive Remediations approach.

Why You Need to Remove Classic Teams

Even though Classic Teams stopped working months ago, there are real reasons to actively remove it rather than just leaving it behind:

  • Security – Classic Teams no longer receives security updates, leaving a potential attack surface on your endpoints
  • Disk space – The per-user installation model means Classic Teams can consume hundreds of megabytes per user profile on a device
  • User confusion – Leftover shortcuts and autorun entries can confuse users, especially when New Teams is already deployed
  • Compliance – Many organizations have policies requiring the removal of end-of-life software from managed devices
  • Clean device state – Leftover registry entries and autorun configurations can interfere with New Teams or cause unexpected behavior

What Gets Removed

All three scripts target the same Classic Teams components:

  • Teams Machine-Wide Installer – The MSI-based installer typically deployed via SCCM, GPO, or during OS deployment
  • Per-user Teams installations – Classic Teams installed itself per-user under %LocalAppData%\Microsoft\Teams for each profile on the device
  • Autorun registry entries – Both HKLM and per-user Run keys that launch Classic Teams at logon
  • Desktop and Start Menu shortcuts – Leftover .lnk files pointing to the old Teams client
  • Teams Installer folder – The C:\Program Files (x86)\Teams Installer directory

Option 1: Remove Classic Teams with a Standalone Script

If you need to remove Classic Teams from a smaller number of devices, or want to run the cleanup through SCCM, ConfigMgr, GPO, or manually, use the standalone removal script. It handles the complete removal process in a single run: stops Teams processes, uninstalls the Machine-Wide Installer via msiexec, iterates through all user profiles to remove per-user installations, cleans up registry entries and shortcuts, and validates the result.

Script: Remove-ClassicTeams.ps1

Usage

Run the script as SYSTEM or with local administrator privileges:

powershell.exe -ExecutionPolicy Bypass -File Remove-ClassicTeams.ps1

The script creates a log file at C:\Windows\Logs\Remove-ClassicTeams.log for troubleshooting.

Option 2: Remove Classic Teams with Intune Proactive Remediations

For organizations managing devices through Microsoft Intune, the preferred approach is to use Proactive Remediations (now called Remediations in the Intune admin center). This gives you a detection script that identifies non-compliant devices and a remediation script that automatically cleans them up.

Detection Script

The detection script checks whether you still need to remove Classic Teams by scanning all common locations. If any remnant is found, it exits with code 1 (non-compliant), which triggers the remediation script. If the device is clean, it exits with code 0 (compliant).

Script: Detect-ClassicTeams.ps1

The detection checks include:

  • Teams Machine-Wide Installer in both 32-bit and 64-bit uninstall registry keys
  • Classic Teams folder, Teams.exe, and Update.exe in each user profile
  • Teams desktop shortcuts across all profiles
  • HKLM Run entry for Teams

Remediation Script

When the detection script flags a device as non-compliant, the remediation script will remove Classic Teams and perform the full cleanup. It goes further than the standalone script by also cleaning Start Menu and Startup folder shortcuts, loading offline user registry hives to remove per-user Run entries, and removing the Teams Installer folder from Program Files.

Script: Remediate-ClassicTeams.ps1

After remediation, the script runs its own validation. If all remnants are successfully removed, it exits with code 0. If anything remains, it exits with code 1, which Intune will flag for review.

Setting Up the Proactive Remediation in Intune

  1. In the Intune admin center, navigate to Devices > Remediations
  2. Click Create script package
  3. Give it a name, for example: Remove Classic Microsoft Teams
  4. Upload Detect-ClassicTeams.ps1 as the detection script
  5. Upload Remediate-ClassicTeams.ps1 as the remediation script
  6. Set Run this script using the logged-on credentials to No (runs as SYSTEM)
  7. Set Run script in 64-bit PowerShell to Yes
  8. Assign the remediation to a device group – start with a pilot group before targeting all devices
  9. Set the schedule – daily is recommended until the bulk of devices are cleaned up, then reduce to weekly

Logging

All three scripts write detailed logs to C:\Windows\Logs:

  • Remove-ClassicTeams.log
  • Detect-ClassicTeams.log
  • Remediate-ClassicTeams.log

Each log entry includes a timestamp, severity level (INFO, WARN, ERROR), and a descriptive message, making it easy to verify that the scripts successfully remove Classic Teams. This makes it straightforward to troubleshoot any issues through Intune device diagnostics or by reviewing the log files directly.

Summary: Remove Classic Teams the Right Way

Cleaning up Classic Microsoft Teams is a necessary task for any organization that has migrated to New Teams. Whether you run the standalone script through your existing deployment tools or leverage Intune Proactive Remediations for automated, ongoing compliance, these scripts give you a reliable way to get it done.

All scripts are available on my GitHub:

If you have questions or run into issues, feel free to reach out.

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

Posted on by
Reply

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

Posted on by
Reply

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.