From Helpdesk Tickets to Proactive IT: Automating Microsoft Teams Update Checks with Intune

Stop Repeating Teams Support Tickets: A Proactive Update-Health Check with Microsoft Intune

Microsoft Intune · PowerShell · Microsoft Teams · Endpoint Management

A user reports that Microsoft Teams is behaving unexpectedly. The service desk checks the installed version, investigates the issue, and guides the user through an update or restart.

A few days later, another user reports the same problem.

This is a common endpoint-management challenge: small, recurring application issues can consume valuable service desk time when every case requires manual investigation.

Instead of treating every ticket as an isolated incident, we can build a proactive monitoring workflow with PowerShell and Microsoft Intune Remediations.

1. Understand the Problem Before Automating the Fix

Microsoft Teams normally updates automatically, but updates do not always become active immediately. A restart may be required, and update failures can occur because of network connectivity, Delivery Optimization, configuration issues, or other environmental factors.

Consider this scenario:

• A user keeps Teams open throughout the working day.
• The user experiences unexpected behavior or reports a meeting-related issue.
• The service desk investigates the client version and update status.
• The issue requires a manual update attempt or further troubleshooting.

An outdated Teams client can contribute to application problems, but it does not automatically explain every audio, meeting, or stability issue.

The opportunity is to detect relevant conditions centrally, avoid interrupting users, and provide IT with actionable reporting.

2. Why Force an Update When Teams Is Running?

Microsoft documents a PowerShell command for troubleshooting Teams update failures:

Add-AppxPackage `
    -Path "https://go.microsoft.com/fwlink/?linkid=2196060" `
    -ForceUpdateFromAnyVersion `
    -ForceTargetApplicationShutdown

However, -ForceTargetApplicationShutdown can close Teams. Running this command automatically while users are working could interrupt calls or meetings.

A safer approach is to check whether Teams is running and defer disruptive actions until a suitable opportunity.

The objective is not to force an update on every device. It is to identify an actual problem and address it safely.

3. The Proposed Solution: Intune Remediations

Intune Remediations provides scheduled PowerShell execution, central assignment, and reporting for supported managed Windows devices.

A remediation package can contain two scripts:

• Detection: Determines whether a defined, actionable issue exists.
• Remediation: Attempts to correct that issue when Detection returns exit 1.

The workflow should be:

1. Check the Teams installation and process state.
2. Determine whether a real update or repair is required.
3. If Teams is running, defer any disruptive action.
4. If Teams is closed and an update is confirmed as necessary, use a tested update method.
5. Report the result so IT can identify devices that still need attention.

A crucial distinction: finding an installed Teams version does not prove that an update is available. A production solution needs a reliable way to establish the update requirement before attempting a correction.

4. Start by Checking the Teams State with PowerShell

Before deploying an automatic updater, validate the installation and process checks on a pilot computer. The following script is a diagnostic example, based on the initial testing performed for this scenario:

$ErrorActionPreference = 'Stop'

$teams = Get-AppxPackage -Name MSTeams
$processes = Get-Process -Name 'ms-teams' `
    -ErrorAction SilentlyContinue

if (-not $teams) {
    Write-Output "STATUS=NOT_INSTALLED"
    exit 1
}

Write-Output "VERSION=$($teams.Version)"

if ($processes) {
    Write-Output "STATUS=DEFERRED"
    Write-Output "Teams is running. No update attempted."
    exit 0
}

Write-Output "STATUS=NOT_RUNNING"
Write-Output "Update status requires further investigation."
exit 0

How Should We Interpret the Results?

Output	Meaning
STATUS=NOT_INSTALLED	The package was not found in the current user's package context.
STATUS=DEFERRED	Teams is running; avoid a disruptive update attempt.
STATUS=NOT_RUNNING	Teams is closed, but an update requirement has not yet been established.
VERSION=...	The installed package version reported by PowerShell.

Important: This is a diagnostic script, not a finished production Detection script. In Intune Remediations, exit 1 triggers the remediation script. The example therefore must not be uploaded unchanged as the final update workflow: a missing package is not automatically an update failure, and a closed Teams process does not prove an update is required. The production Detection and Remediation scripts must be designed together.

5. Choose the Execution Context: User vs. System

Teams (the new client, package MSTeams) is an MSIX/Appx package, and where a script runs determines what it can see. This is the most common reason a Teams remediation reports the wrong result.

In the script package settings, the option Run this script using the logged-on credentials controls the context:

	Logged-on user context	System context (default)
Setting	Run this script using the logged-on credentials: Yes	Run this script using the logged-on credentials: No
Runs when	A user is signed in	Regardless of whether a user is signed in
Get-AppxPackage -Name MSTeams	Returns the signed-in user's package. Works as expected.	Returns packages for the SYSTEM account only, so Teams can appear as not installed. Needs -AllUsers.
Add-AppxPackage update	Updates the package for that user. No admin rights needed.	Does not update a user's Teams the same way. Requires a different approach, such as the Teams bootstrapper.
Seeing the user's Teams process	Yes	Yes (Get-Process sees all sessions)
Best for	Checking and repairing the Teams client of the person using the device	Inventory-style reporting or machine-wide provisioning

For the scripts in this article, logged-on user context is the simplest and most reliable choice, because both the check and the documented Add-AppxPackage command operate on the same user's package. Also review these related settings on the package:

• Run script in 64-bit PowerShell: set to Yes for consistent behavior with Appx cmdlets on 64-bit Windows.
• Enforce script signature check: leave at No unless your organization signs its scripts.

If you need System context: use Get-AppxPackage -AllUsers -Name MSTeams for detection and a machine-wide method for the correction. Microsoft documents the Teams bootstrapper (teamsbootstrapper.exe -p) for provisioning. This path has different behavior and should be validated separately on a pilot device before use.

6. Production-Ready Scripts (User Context)

The scripts below are designed as a pair and meant to run in logged-on user context. They follow the rules from this article: report instead of guessing, never interrupt a running Teams client, and only attempt a fix when an update is confirmed as necessary.

You must define the update requirement. A script cannot reliably know the "latest" Teams version on its own. Set $MinimumVersion to the minimum package version your organization accepts, based on a healthy pilot device or Microsoft's current release information. Until you set it, Detection reports CONFIG_REQUIRED and does nothing.

Detect-TeamsUpdateHealth.ps1

#requires -Version 5.1

# ------------------------------------------------------------
# Configuration
# Set to the minimum acceptable MSTeams package version
# (four-part version, e.g. taken from a healthy pilot device).
# ------------------------------------------------------------
$MinimumVersionText = ''

$ErrorActionPreference = 'Stop'

try {

    if ([string]::IsNullOrWhiteSpace($MinimumVersionText)) {
        Write-Output 'STATUS=CONFIG_REQUIRED MinimumVersion is not set.'
        exit 0
    }

    $MinimumVersion = [version]$MinimumVersionText

    $Teams = Get-AppxPackage -Name MSTeams -ErrorAction SilentlyContinue

    if (-not $Teams) {
        # Not an update problem. Report it, but do not trigger remediation.
        Write-Output 'STATUS=NOT_INSTALLED'
        exit 0
    }

    $InstalledVersion = [version]$Teams.Version

    if ($InstalledVersion -ge $MinimumVersion) {
        Write-Output "STATUS=COMPLIANT Version=$InstalledVersion"
        exit 0
    }

    # Update is required. Do not trigger remediation while Teams is in use.
    $Running = Get-Process -Name 'ms-teams' -ErrorAction SilentlyContinue

    if ($Running) {
        Write-Output "STATUS=DEFERRED Version=$InstalledVersion Required=$MinimumVersion TeamsRunning=True"
        exit 0
    }

    Write-Output "STATUS=OUTDATED Version=$InstalledVersion Required=$MinimumVersion"
    exit 1

}
catch {

    Write-Output "STATUS=ERROR $($_.Exception.Message)"
    exit 0

}

Remediate-TeamsUpdate.ps1

#requires -Version 5.1

# Must match the value used in the Detection script.
$MinimumVersionText = ''

$ErrorActionPreference = 'Stop'

$LogFolder = Join-Path $env:LOCALAPPDATA 'TeamsUpdateHealth'
$LogFile   = Join-Path $LogFolder 'Remediation.log'

function Write-Log {
    param([string]$Message)

    if (-not (Test-Path -LiteralPath $LogFolder)) {
        New-Item -Path $LogFolder -ItemType Directory -Force | Out-Null
    }

    $Line = '{0:yyyy-MM-dd HH:mm:ss}  {1}' -f (Get-Date), $Message
    Add-Content -LiteralPath $LogFile -Value $Line
    Write-Output $Message
}

try {

    if ([string]::IsNullOrWhiteSpace($MinimumVersionText)) {
        Write-Log 'RESULT=CONFIG_REQUIRED MinimumVersion is not set.'
        exit 1
    }

    $MinimumVersion = [version]$MinimumVersionText

    # Re-check immediately before acting: the situation may have changed
    # since Detection ran.
    if (Get-Process -Name 'ms-teams' -ErrorAction SilentlyContinue) {
        Write-Log 'RESULT=DEFERRED Teams is running. No update attempted.'
        exit 0
    }

    Write-Log 'Starting Teams update.'

    Add-AppxPackage `
        -Path 'https://go.microsoft.com/fwlink/?linkid=2196060' `
        -ForceUpdateFromAnyVersion `
        -ForceTargetApplicationShutdown

    # Verify the outcome instead of assuming success.
    $Teams = Get-AppxPackage -Name MSTeams -ErrorAction Stop
    $NewVersion = [version]$Teams.Version

    if ($NewVersion -ge $MinimumVersion) {
        Write-Log "RESULT=SUCCESS Version=$NewVersion"
        exit 0
    }

    Write-Log "RESULT=FAILED Version=$NewVersion Required=$MinimumVersion"
    exit 1

}
catch {

    Write-Log "RESULT=ERROR $($_.Exception.Message)"
    exit 1

}

How the Pair Behaves

Situation	Detection	Remediation runs?
Teams version meets the minimum	COMPLIANT, exit 0	No
Teams not installed	NOT_INSTALLED, exit 0	No (not an update problem)
Outdated, Teams is running	DEFERRED, exit 0	No (checked again next cycle)
Outdated, Teams is closed	OUTDATED, exit 1	Yes
Minimum version not configured	CONFIG_REQUIRED, exit 0	No
Unexpected error	ERROR, exit 0	No (visible in the report)

The DEFERRED and ERROR states return exit 0 on purpose so that they never trigger a disruptive action, while the status text still appears in the Intune device report for follow-up.

Note on the shutdown flag: the Remediation script checks that Teams is closed immediately before updating, which keeps the -ForceTargetApplicationShutdown risk small. A short window remains in which a user could open Teams between the check and the update, so test the behavior on a pilot group first.

7. Configure the Schedule in Intune

Once the detection logic and corrective action have been validated, deploy the package to a small pilot group.

1. Open the Microsoft Intune admin center.
2. Navigate to Devices → Manage devices → Scripts and remediations → Remediations.
3. Select Create script package.
4. Give it a descriptive name, such as Teams - Update Health Check.
5. Upload the Detection and Remediation scripts under Settings.
6. Set the execution context as described in section 5: Run this script using the logged-on credentials: Yes and Run script in 64-bit PowerShell: Yes.
7. Assign the package to a pilot group.
8. Under Assignments, edit the schedule using the three-dot menu.
9. Choose Hourly and configure an interval appropriate for the pilot. An interval of eight hours is one possible starting point for approximately three checks per day.

10. Save the assignment and monitor the results before expanding the deployment.

Intune supports Once, Hourly, and Daily schedules. The schedule controls when the detection/remediation cycle runs; it does not guarantee that exactly three executions will occur at precise times every day. Device availability and policy processing can affect execution.

No separate Windows Task Scheduler task is required for this Intune-managed workflow.

Official reference: Microsoft Learn — Use Remediations to detect and fix support issues.

8. What Happens When Teams Is Still Open?

Imagine the first check runs while a user is in a meeting.

The script detects that Teams is running and reports that a disruptive action should be deferred. Detection returns exit 0, so the remediation script does not run during that cycle.

At the next scheduled check, the scripts evaluate the state again. If Teams is closed, the workflow can proceed only if the production Detection script also confirms that a corrective action is required.

This avoids deliberately shutting down Teams during a meeting. It also means the process may remain deferred if users keep Teams open continuously, so monitoring and follow-up remain important.

9. Measure the Impact on the Service Desk

After the pilot, review the Intune results and compare the support workload with the period before deployment. Track:

• Devices with confirmed update-related issues.
• Successful and failed remediation attempts.
• Devices where action was deferred because Teams was running.
• Recurring Teams-related support tickets before and after deployment.

These metrics help determine whether the automation is actually reducing manual troubleshooting.

---

Final Thoughts

The best endpoint automation is not simply a script that runs more often. It is a controlled process that detects a meaningful problem, respects the user's active session, applies a tested fix, and reports the outcome.

By combining PowerShell with Intune Remediations, IT teams can move toward proactive endpoint management and reduce repetitive service desk work.

Detect first. Remediate safely. Measure the result.