Conference Rooms That Fix Their Own Audio Defaults

#The Old Way: A Technician’s Monday Morning Ritual

Every helpdesk has this ticket queued before the coffee finishes brewing. Room 4B. “No audio in the Teams call.” A user walks in, joins a meeting, and the speakerphone sits there silently while sound blasts out of the HDMI-connected display instead. The old way of fixing this is depressingly manual: a technician walks to the room, opens Windows Sound settings, manually sets the USB speakerphone as the default playback and recording device, runs a test call, and closes the ticket. Then it happens again on Wednesday after a firmware update forces a device re-enumeration, and again after the cleaner unplugs something to vacuum behind the credenza. It is the same five-minute fix, repeated hundreds of times a year across a room estate, purely because Windows re-evaluates its default audio device every time the hardware topology changes.

The new way accepts that this fault is entirely predictable and therefore entirely automatable. We are not going to wait for a user to notice silence and raise a ticket. We are going to detect the wrong default device and correct it before the meeting organiser even clicks “Join”.

#Root Cause: Why Windows Keeps Picking the Wrong Device

Windows assigns audio device priority based on enumeration order and “last used” state, not on a fixed room policy. USB speakerphones (Poly Sync, Jabra Speak, Yealink) and the HDMI or DisplayPort audio endpoint on the room’s compute stick or NUC are both valid playback devices. When the USB device disconnects briefly – during a firmware push, a power cycle, or a driver update – Windows often reverts default playback and recording to the HDMI endpoint, because it is the device that never went away. The result is a room PC that thinks audio is fine, because it is playing audio, just out of the wrong endpoint, into a display with no visible speaker and no microphone at all.

This is not a hardware fault. It is a state management problem. State management problems are exactly what scripts are for.

#Step One: Build a Detection Script

We use the open-source AudioDeviceCmdlets PowerShell module to query and set default audio endpoints without needing to touch the GUI. Install it once as part of your room PC baseline image or push it via Intune Win32 app.

1# Install-AudioDeviceCmdlets.ps1
2Install-PackageProvider -Name NuGet -Force -Scope AllUsers
3Install-Module -Name AudioDeviceCmdlets -Force -Scope AllUsers -AllowClobber

Detection logic checks whether the current default playback and recording devices match an approved device name pattern for that room type. This is the script that Intune Proactive Remediations will run on a schedule (every user logon and every four hours).

1# Detect-WrongAudioDefault.ps1
2Import-Module AudioDeviceCmdlets
3
4$approvedPattern = "Poly Sync|Jabra Speak|Yealink"
5
6$playback = Get-AudioDevice -Playback
7$recording = Get-AudioDevice -Recording
8
9$playbackOK = $playback.Name -match $approvedPattern
10$recordingOK = $recording.Name -match $approvedPattern
11
12if (-not $playbackOK -or -not $recordingOK) {
13    Write-Output "NON-COMPLIANT: Playback=$($playback.Name) Recording=$($recording.Name)"
14    exit 1
15}
16else {
17    Write-Output "COMPLIANT: $($playback.Name)"
18    exit 0
19}

Exit code 1 tells the Intune remediation engine “this device needs fixing”. Exit code 0 means leave it alone. No ticket has been raised. No technician has walked anywhere. The device is simply flagged internally as non-compliant.

#Step Two: Build the Remediation Script

The companion remediation script runs only on devices that failed detection. It finds the approved device by name, sets it as both default and default communications device, and logs the correction for audit purposes.

1# Remediate-AudioDefault.ps1
2Import-Module AudioDeviceCmdlets
3
4$approvedPattern = "Poly Sync|Jabra Speak|Yealink"
5$logPath = "C:\\ProgramData\\RoomHealth\\audio-remediation.log"
6
7$target = Get-AudioDevice -List | Where-Object {
8    $_.Name -match $approvedPattern -and $_.Type -eq "Playback"
9} | Select-Object -First 1
10
11$targetRec = Get-AudioDevice -List | Where-Object {
12    $_.Name -match $approvedPattern -and $_.Type -eq "Recording"
13} | Select-Object -First 1
14
15if ($target) {
16    Set-AudioDevice -ID $target.ID
17    "$(Get-Date -Format o) - Set playback default to $($target.Name)" | Out-File -Append $logPath
18}
19
20if ($targetRec) {
21    Set-AudioDevice -ID $targetRec.ID
22    "$(Get-Date -Format o) - Set recording default to $($targetRec.Name)" | Out-File -Append $logPath
23}
24
25if (-not $target -or -not $targetRec) {
26    # Approved device not found at all - genuine hardware issue, exit non-zero
27    "$(Get-Date -Format o) - REMEDIATION FAILED: device not present" | Out-File -Append $logPath
28    exit 1
29}
30
31exit 0

Notice the fallback branch. If the approved USB device cannot be found at all, that is no longer a “wrong default” problem – it is a genuinely disconnected or dead device. The script exits non-zero deliberately, because this is the one case where we still want a human involved, and we want the failure logged clearly so the eventual ticket arrives pre-diagnosed.

#Step Three: Deploy via Intune Proactive Remediations

Package both scripts into a Proactive Remediation in Microsoft Endpoint Manager, scoped to your Azure AD dynamic device group for meeting room PCs (something like devicePhysicalIds -any (_ -contains "[OrderID]:RoomPC") or a naming convention filter).

1# Dynamic group rule for room PCs
2(device.displayName -startsWith "MTG-") or (device.displayName -startsWith "AVR-")

Configure the remediation schedule to run every four hours and on every user check-in. This means the worst-case exposure window for a wrong-default fault is four hours of unattended downtime, versus the old model of “however long it takes for someone to notice and log a ticket, plus queue time, plus travel time to the room.”

#Step Four: Only Escalate When It Genuinely Fails

Automation without visibility is dangerous – you do not want silent failures piling up in rooms nobody is monitoring. So we add a second layer: Intune’s remediation results are queried via Graph API on a schedule, and any device that has failed remediation (exit code 1 from the remediation script itself, not just detection) three times in 24 hours triggers a webhook into a Power Automate flow that raises a ticket automatically, with full diagnostic context already attached.

1// Webhook payload sent from Power Automate to ServiceNow Table API
2{
3  "short_description": "Room AVR-4B: audio device remediation failed 3x in 24h",
4  "category": "Modern Workspace & AV",
5  "urgency": "3",
6  "assignment_group": "AV Support L2",
7  "cmdb_ci": "AVR-4B-ROOMPC",
8  "work_notes": "Automated remediation attempted 3 times. Approved audio device not detected on last 3 runs. Likely USB disconnection or hardware failure. Do not dispatch for default-device reset - check physical USB connection first.",
9  "u_automation_source": "Intune-ProactiveRemediation",
10  "u_correlation_id": "{{workflow().run.name}}"
11}

This is the critical design principle: the ticket that finally reaches a technician is the ticket that could not be engineered away. It arrives with the root-cause hypothesis already written in the work notes, telling L2 exactly what not to waste time checking. No walking to the room to re-tick a dropdown that self-heals every four hours anyway.

#Step Five: Extend to the Whole Teams Rooms Fleet with Graph

If your estate runs Microsoft Teams Rooms Pro-managed devices, you get an even richer telemetry surface without deploying your own agent. The Teams Rooms Pro Management portal exposes device health via Graph API, including peripheral connectivity state. A scheduled Azure Function can poll this and cross-reference it against the same escalation logic.

1# Poll Teams Rooms Pro health via Graph (PowerShell, using Microsoft.Graph module)
2Connect-MgGraph -Scopes "TeamworkDevice.Read.All"
3
4$devices = Invoke-MgGraphRequest -Method GET `
5  -Uri "https://graph.microsoft.com/beta/teamwork/devices"
6
7foreach ($d in $devices.value) {
8    $peripherals = $d.healthStatus.peripherals
9    $micIssue = $peripherals | Where-Object {
10        $_.category -eq "Microphone" -and $_.connection.connectionStatus -ne "connected"
11    }
12    if ($micIssue) {
13        Write-Output "ALERT: $($d.currentUser.displayName) room mic disconnected: $($d.id)"
14    }
15}

Feed that output into the same webhook pattern used above, and you have a single pane of alerting that covers both bare-metal room PCs (via Intune Proactive Remediations) and Teams Rooms Pro appliances (via Graph telemetry), each self-healing where possible and only surfacing a ticket when self-healing has genuinely exhausted its options.

#Measuring the Deflection

Before shipping this, baseline your ticket category volume for “no audio” or “audio not working” tagged tickets in the AV queue over a rolling 90 days. After deployment, track three numbers monthly: the count of detection-script non-compliance events (how often the fault occurs), the count of successful automatic remediations (how often it self-heals), and the count of genuine escalations reaching the human queue. In most room estates running USB speakerphones alongside HDMI displays, you should see the detection event count stay roughly flat – the underlying Windows behaviour has not changed – while the human-facing ticket count drops by 80-90%, because the fault is now corrected inside the four-hour remediation window, almost always before the next meeting starts.

Log the remediation events centrally (a simple Log Analytics workspace ingesting the log file via the Intune remediation output, or a Data Collection Rule if you want it structured) so you can prove the deflection with real numbers when it comes to renewing the automation budget line, rather than relying on “it feels quieter now.”

#Why This Is the Right Level of Automation

The temptation with proactive remediation is to over-fix: force a reboot, reset the whole audio stack, reinstall drivers. Resist it. The scripts above do the smallest possible intervention – setting a default device pointer – because that is the actual fault. Reserve the noisier interventions (reboot commands via the Teams Rooms Pro remote actions API, or driver reinstalls) for the escalation tier, where a human has already confirmed the cheap fix did not work. Cheap, frequent, narrow remediation beats expensive, rare, broad remediation every time, both in risk and in mean time to resolution.

The ticket for “no audio in the conference room” does not need a technician. It needs a scheduled task, a name-matching regex, and a webhook that only fires when the regex genuinely cannot find what it is looking for. That is the whole playbook: detect the pattern, correct the pattern, and only wake a human when the pattern itself has broken.