Deploy mechanics · Windows, classic estate
GPO and SCCM deployment for call-audio software
Plenty of real organizations still run their Windows estate on Active Directory and Configuration Manager, and there is nothing wrong with that — these tools install software extremely well. But GPO in particular has one specific weakness that lands squarely on this project, and it is better to meet it on this page than three days into packaging.
The weakness, stated plainly
Group Policy Software Installation does not give you a command line. You point a policy at an MSI on a share and Active Directory installs it. There is no field where you type /qn KP_sso_slug="…", because the installation isn't run from a command you composed — it's run by the Windows Installer service on the policy's behalf.
That matters here because the parameter is the entire point. An audio client installed without its SSO routing is a client that will ask nine hundred people to figure out sign-in for themselves, which is the outcome you started this project to avoid. Parameter semantics are on our MSI page; this page is about getting them delivered.
There are exactly three honest ways around it, and one of them is not really a way around it.
Three ways to get the parameter delivered
Group Policy Software Installation gives you no command line for KP_sso_slug
Option 1
A transform (.mst)
Sets the property in the MSI’s table; attached under Modifications when the package is created as Advanced.
Option 2
A startup script
Runs as SYSTEM before logon, with a guard clause and a verbose log.
Option 3 · a different tool
Configuration Manager
The install command is typed directly; detection, supersedence and a real uninstall come with it.
Option 1: a transform (.mst)
The proper GPO answer. A transform is a small file that modifies an MSI's property table at install time — you author it once against the vendor's MSI, drop it on the same share, and attach it to the software installation policy under Modifications when you create the package.
- Open the vendor MSI in a transform editor (Orca from the Windows SDK is the free, unglamorous, entirely adequate choice).
- Create a new transform, set your property — the SSO slug — in the
Propertytable, and save the.mstalongside the MSI. - Create the GPO package as Advanced, not Assigned-and-next-next-finish. The Modifications tab only appears on the advanced path, and it is not revisitable afterwards: get the transform attached at creation or delete the package and start again.
- Put the MSI and MST on a share every target computer account can read. Not your account. The classic GPO software-installation failure is a share ACL that grants Domain Users and forgets Domain Computers.
Orca ships with Microsoft's SDK at no cost and there is no affiliate relationship behind mentioning it. It is simply the tool.
Option 2: a startup script
The pragmatic answer, and the one most admins actually reach for. A computer startup script runs as SYSTEM before the user logs on, and inside it you have a full command line:
if (-not (Get-Package -Name "Krisp" -ErrorAction SilentlyContinue)) {
Start-Process msiexec.exe -Wait -ArgumentList `
'/i', '\\fileserver\pkg\Krisp.msi', '/qn',
'KP_sso_slug="your-workspace-slug"',
'/l*v', 'C:\Windows\Temp\krisp-install.log'
}Note the two things that make this survivable rather than merely functional: a guard clause so it isn't reinstalling on every boot, and a verbose log written somewhere you can collect from. A startup script without both is a deployment you cannot troubleshoot, and it will be the thing you are troubleshooting.
Option 3: Configuration Manager
If you have SCCM, use SCCM. The application model was built for precisely this shape of problem and gives you everything GPO withholds: an arbitrary install command line, a detection method, requirement rules, a supersedence chain when the vendor ships a new build, a real uninstall program, and deployment collections that map cleanly onto rings.
| What you need | GPO software installation | Configuration Manager |
|---|---|---|
| Install-time parameters | Only via an MST transform | Typed directly into the install command |
| Detection of success | Implicit; awkward to audit | Explicit detection method (product code) |
| Staged rings | By OU or security-group filtering | Collections, with phased deployment |
| Reporting | Event logs, if you go collect them | Built-in compliance and status reporting |
| Version upgrades | Redeploy and hope | Supersedence |
| Clean uninstall | Policy removal, with caveats | A defined uninstall program |
The honest summary: GPO is a fine way to get software onto machines and a poor way to manage software on machines. For a one-off audio client on a stable estate, that distinction may not cost you anything. For anything you expect to version, report on, and eventually remove, it will.
The registry-path trap worth an extra five minutes
Since you are in Group Policy anyway, it is the natural place to ship the client-side platform values from our Zoom admin audio page — the suppression-level key and its neighbours. One distinction decides whether that works:
| Path | What it is | When to use it |
|---|---|---|
HKLM\SOFTWARE\ZoomUMX(and the WOW6432NODE variant) | Where Zoom's mass-deployment installer records the configuration it was installed with | Install-time configuration, written by the MSI in your packaging pipeline |
HKLM\SOFTWARE\Policies\Zoom\Zoom Meetings\General | The policy path, which is what Zoom's Group Policy template writes to | Enforcing a value on machines where the client is already installed |
Write a value to the install-time path on a fleet that is already deployed and you will get a setting that reads as configured in your documentation and behaves as default on the endpoint — the most annoying class of bug there is, because nothing appears to be wrong. Ingest Zoom's administrative template and let the policy path do the work, or use Group Policy Preferences to write the value explicitly with Apply once turned off so drift gets corrected.
Same value, two different keys
Written by the MSI, at install time
HKLM\SOFTWARE\ZoomUMX
A record of the configuration it was installed with.
Written by Zoom’s Group Policy template
HKLM\SOFTWARE\Policies\Zoom\Zoom Meetings\General
Enforces a value on machines where the client is already installed.
A value written to the install-time path on a fleet that is already deployed reads as configured and behaves as default.
Zoom's key catalog is versioned alongside its client, so re-verify names against the current mass-deployment documentation during change planning rather than trusting any page — including this one — that carries a date.
What this tooling still cannot reach
- Teams policy. Voice isolation, enrollment and dial-in suppression are tenant-side objects, not machine policy. No GPO touches them; see the Teams policy page.
- Vendor seat assignment. The install is half the job. The seat ledger reconciles through identity — SSO & SCIM.
- Anything with an Apple logo on it. macOS MDM covers that half of the fleet.
Build the transform before you buy the seats
The MSI, its parameters and the Admin Portal you pull them from are all available during Krisp's 7-day trial, no card required (verified against krisp.ai, 20 September 2026). Author the transform, run it against one OU, and you will know whether this deploys cleanly in your estate before a single line item exists.
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 GPO and Configuration Manager mechanics above are Microsoft's, documented by Microsoft, and free regardless of what you deploy with them.
Related: Intune if you're modernising, the pilot plan that tells you which OUs go first, and the company-wide playbook.