Deploy mechanics · Windows

Intune deployment for an audio rollout

By the RolloutDesk team · Updated 20 September 2026 · Vendor-specific installer parameters re-verified against Krisp's deployment documentation on that date.

Intune is where an audio project stops being a recommendation and becomes state on a machine. The work is unglamorous and mostly decided in the first ten minutes: pick the wrong app type and you will spend a week discovering that your install-time parameters silently went nowhere. This page is the packaging decision, the assignment model, and the handful of things that break.

Decide the app type before you package anything

Intune will take an MSI two ways, and the choice is not a preference — it is determined by whether your install needs parameters.

Line-of-business app

Upload the .msi, Intune handles the rest. Genuinely fine when the install is plain — no properties, no configuration, sign-in handled by the user afterwards. It is the fastest path to a working pilot and there is no shame in using it for ring 0.

Its limitation is the whole reason this section exists: the LOB path gives you very little room to hand the installer custom public properties, and no room at all to run a command line you composed yourself.

Win32 app pick this

Wrap the MSI in an .intunewin package and you supply the literal install command, the literal uninstall command, the detection rule, requirements and install context. That is exactly what you need the moment an SSO slug, a device-login flag or any other property has to reach the installer.

For any fleet you would describe as “the company,” package Win32. The extra twenty minutes buys you a package that is reproducible and legible to whoever inherits it.

The rule of thumb: if your install command has a space in it that isn't /qn, you want a Win32 app. Teams that learn this the hard way usually learn it from a fleet of installed clients that are all pointed at the wrong sign-in flow — technically a successful deployment, practically a re-deploy.

Pick the app type in one question

Does the install command carry anything besides /qn?

No — a plain install

Line-of-business app

Upload the .msi. Fine for a ring-0 pilot; little room for custom properties.

Yes — a slug, a flag, a property

Win32 app

Wrap it as .intunewin; you write the install, the uninstall and the detection rule.

Building the package

Microsoft's content-prep tool converts a folder containing your installer into the single .intunewin file Intune ingests:

Command line · content prep tool

IntuneWinAppUtil.exe -c C:\pkg\krisp -s Krisp.msi -o C:\pkg\out

Keep the source folder clean — one installer, plus any wrapper script you genuinely need. Everything in that folder ships inside the package, which is how a stray 400 MB ISO ends up on nine hundred laptops.

The four fields that decide whether it works

Field	What we use	Why
Install command	`msiexec /i "Krisp.msi" /qn KP_sso_slug="your-workspace-slug"`	Silent, and carries the SSO routing so the client comes up pointed at your identity provider. Parameter semantics are on the MSI page.
Uninstall command	`msiexec /x "{your-product-code}" /qn`	Write it the same day as the install command. A package without a tested uninstall is not a deployment, it's a one-way door.
Detection rule	MSI product code (optionally with a minimum version)	The product code is the sturdiest signal that this specific build landed. File-path detection drifts; registry detection is a fallback, not a first choice.
Install behavior	System	An audio client that installs per-user on a shared machine produces exactly the support ticket you'd expect. System context, then let the sign-in be the per-user part.

Two more worth setting deliberately: requirements (64-bit, and a minimum OS build you actually support, so unsupported machines report as not-applicable rather than as failures), and device restart behavior (no forced restart — this is an audio utility, not a driver package you need to reboot the floor for).

Assignment: rings, not “All Users”

The assignment groups are the rollout plan. Build them before you build the package, because naming them forces you to decide who is actually in ring 1.

SG-Audio-Ring0-IT — your own team and a few volunteers who live on calls. Required assignment. A week.
SG-Audio-Ring1-CallHeavy — support, inside sales, recruiting. Required. Two weeks. This is the ring that produces your evidence.
SG-Audio-Ring2-All — everyone else, by department, on whatever cadence your change process expects.
SG-Audio-Exclude — the exclusion group. Build it on day one even if it is empty. The one machine that cannot take the package will appear, and you want somewhere to put it that isn't a spreadsheet comment.

The assignment groups are the rollout plan

SG-Audio-Ring0-ITRequired · a week
SG-Audio-Ring1-CallHeavyRequired · two weeks
SG-Audio-Ring2-AllBy department

SG-Audio-ExcludeBuilt on day one, even if it is empty

Exit criteria for each ring, plus the comms that go with them, are on the pilot rollout page. Assign to device groups where the machine is the unit of management and to user groups where the person is; for an audio client that follows someone between a laptop and a docking station, user groups usually match reality better.

Shipping platform policy with the same tool

While you have Intune open, it is also the delivery vehicle for the client-side policy values covered on our Zoom admin audio page. Zoom's suppression level is a registry value, and Intune has three reasonable ways to write one:

Settings Catalog / imported ADMX — the cleanest, because the value stays visible as policy in the console rather than as a script someone ran in 2026. Prefer this when the vendor ships an ADMX you can ingest.
A configuration profile with custom OMA-URI — the workhorse when there's no catalog entry for the value you need.
A platform script — fastest to write, weakest to audit, and it does not remediate drift. Acceptable for a pilot; replace it before ring 2.

Know which registry path you're writing to. Zoom's mass-deployment configuration and its Group Policy path are not the same key, and writing the right value to the wrong one produces a setting that looks configured and behaves default. The two paths and the distinction between them are spelled out on our GPO & SCCM page — read that section even if you never touch a GPO.

What Intune cannot do here

A short list, because rollout plans built on imagined capabilities fail in week two:

It does not configure Teams policy. Voice isolation, voice enrollment and dial-in suppression are tenant policy objects in the Teams admin center and PowerShell — a different console, a different change ticket, covered on our Teams policy page. We have watched more than one project stall looking for a Teams audio setting in a device-configuration profile. It is not there.
It does not assign vendor seats. Intune puts the client on the machine; the seat ledger lives in the vendor console, and the only way to keep the two in sync automatically is identity — see SSO & SCIM.
It does not grant microphone consent on macOS. Different platform, and a genuinely immovable constraint — the detail is on the macOS MDM page.

Failure modes we'd flag in a runbook review

Detection rule written against the wrong thing. Symptom: Intune reinstalls the app on every check-in, users see nothing, your success numbers look fine, and the fleet quietly burns bandwidth. Detect on product code.
Testing the package as yourself. Your session is an admin session; the deployment runs in system context. Test where it runs, on a clean VM, or your first real signal will come from ring 1.
Assigning to All Devices on day one. It works right up until it doesn't, and an audio layer's blast radius is every call in the company for the next hour.
Never reading the install-status blade again. Ninety days on, the gap between assigned and installed is the most useful number in the project — it is also the number your renewal conversation will turn on.

Package it against the trial first

Everything above — portal MSI, Win32 wrap, slug parameter, detection rule, a real ring-0 assignment — works during Krisp's 7-day trial with no card and no procurement conversation (verified against krisp.ai, 20 September 2026). Rehearsing the package before the invoice exists is the cheapest risk reduction available in this project.

Rehearse the package on the trial

Referral link, declared: when an organization licenses Krisp after clicking this button, Krisp pays RolloutDesk a fee, and the quote you receive is the one you would get going direct. No affiliate relationship exists between this site and Microsoft; the Intune mechanics above are documented by Microsoft and free either way.

Next along the chain: GPO & SCCM for classic estates, macOS MDM for the other half of your fleet, and the company-wide playbook these packages belong to.