Deploy mechanics · Windows
Krisp MSI and silent install, for IT admins
The difference between “software we bought” and “software the fleet runs” is usually one file: the MSI. Krisp ships one, it installs silently, and it accepts the install-time parameters that make zero-touch onboarding possible. Here's the whole Windows flow, admin console to verified install.
Where the installer actually lives
You don't deploy the consumer download. The deployment-grade MSI comes from Krisp's Admin Portal — the same console where you manage seats, users and updates. That distinction matters for two reasons: the portal build is the one Krisp's deployment docs are written against, and pulling it from the portal ties your package to the team workspace you'll be managing, rather than to a personal account someone created with their work email in 2024.
If nobody in your org has portal access yet, that's step zero — the trial includes it, so you can rehearse the full packaging flow before any money moves. Krisp's own deployment documentation lives in its help center under “Deploy Krisp for your team”; keep it open next to this page, since installer options occasionally move between releases.
The three deployment shapes
1. Plain silent MSI
No SSO, no special configuration — the MSI installed quietly with default settings. Right for small teams that sign in with email, or for a ring-0 rehearsal. You still get central seat and update management from the portal afterwards; the install method doesn't change what the console sees.
2. MSI with SSO parameters
The enterprise shape. You pass your workspace's SSO slug at install time and machines come up already routed to your identity provider — no first-run account puzzle for users to solve incorrectly. This is the shape every guide on this site assumes for 50+ seats.
3. Device-login team
For shared machines — hot desks, interview rooms, training benches — Krisp documents a device-login configuration set through an MSI parameter, so the seat belongs to the device rather than to whoever sat down first. Niche, but exactly right when you need it.
The parameter that matters: KP_sso_slug
Krisp's SSO routing is controlled by a slug — your workspace's identifier with your identity provider — passed as a command-line property when the MSI is installed, updated or repaired:
msiexec /i Krisp.msi /qn KP_sso_slug="your-workspace-slug"Semantics worth knowing before you package (all per Krisp's “Configure SSO slug during deployment” doc, checked 20 September 2026):
- The slug is saved into the app's
key.configfile at install time — it persists across sessions, so you set it once per machine, not per login. - On an update, supplying a new value replaces the old one; supplying no slug leaves the existing configuration untouched. Your update packages therefore don't need to re-state it.
- Passing an empty value (
KP_sso_slug="") deliberately clears the SSO configuration — useful in a decommission or workspace-migration package, and a good thing to know so you never do it by accident.
What the slug does, case by case
- Install
KP_sso_slug="your-workspace-slug"Saved into key.config — once per machine - Update, new value
KP_sso_slug="new-slug"Replaces the old one - Update, no slug
(nothing)Existing configuration untouched - Empty value
KP_sso_slug=""Clears the SSO configuration on purpose
A packaging checklist that survives contact with reality
- Pull the current MSI from the Admin Portal into your package source tree. Record the version — you'll want it for the detection rule.
- Decide per-machine questions once: SSO slug (yes for any real fleet), device-login (shared machines only), and whether the app should be present for all users of the machine. Krisp's docs mark which parameters apply; deployment tools' catalogs also publish known-good silent switches for their packaging formats.
- Build the silent command —
/qn, no UI, plus your parameters — and test it on a VM while logged in as a standard user via your deployment tool's context, not as your own admin session. Install context bugs only show up in the real context. - Write the detection rule against the MSI product code or version so your deployment tool knows an install succeeded (specifics per tool: Intune, GPO & SCCM).
- Verify like a skeptic: after the test install, confirm the Krisp virtual devices appear in Windows sound settings, sign-in lands on your IdP, and the seat shows up against the right team in the Admin Portal. Those three checks catch essentially every packaging mistake we've made.
Updates: decide who owns them
The Admin Portal gives you update management for exactly this reason: a fleet where every client self-updates on its own schedule is a fleet where this week's incident is version skew. Pick one owner — portal-managed updates, or your own package pipeline re-shipping new MSIs on your cadence — and disable the other path. Either answer works; having both is how you end up debugging an install that “nobody touched.”
What about the Macs?
The MSI is Windows-only, but the pattern translates: Krisp documents terminal/scripted installation for bulk macOS deployment, which slots straight into MDM tooling — plus one Apple-imposed consent gate (the microphone prompt) that no vendor can script away. The full flow, including the PPPC reality check, is on the macOS MDM page.
Failure modes we'd flag in a runbook review
- Packaging the consumer installer. It installs; it just leaves you managing a fleet through the wrong door. Portal MSI, always.
- Testing only as admin. The classic. Your deployment context differs from your login context; test in the former.
- Shipping before SSO is connected. See the warning above — sequence is identity, then package.
- No decommission package. You deployed by policy; plan the retreat by policy too. An uninstall command plus
KP_sso_slug=""handling belongs in the repo the day the install package does. - Forgetting the seat side. An installed client without an assigned seat is a support ticket with extra steps. Assignment lives in the portal; wire it into onboarding, or better, let SCIM do it.
Rehearse the whole flow on the trial
Everything above — portal, MSI, slug, verification — works during Krisp's 7-day trial, no card required (verified 20 September 2026). Package it, push it to five machines, and you'll know more about the vendor's enterprise story than any datasheet will tell you.
Get the trial and the Admin Portal
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. The packaging advice is the same advice we'd give for free — and mostly just was.
Wider context: this page is step four of the company-wide playbook. For what the Admin Portal itself gives you day-to-day, see Krisp for IT admins; for the money conversation, the seat math.