If you manage endpoints with Intune, Jamf, Kandji, Hexnode, PDQ Deploy, or any RMM tool, this covers what CloudTalk ships, what you can automate, and where you will need to do the packaging yourself.
CloudTalk does not publish an
.msi for Windows or a .pkg for macOS today. The Windows installer does support a silent switch, which is enough for most automated rollouts. On macOS you will wrap the app yourself using your MDM’s own packaging tooling. And if you would rather not install anything at all, the full phone runs in a browser at phone.cloudtalk.io.
Before you start: what each machine needs
For full network and system details, see System & Network Requirements.
Agents will need to grant microphone and notification permissions the first time they open the app. Neither Apple nor Microsoft lets an MDM pre-approve microphone access on the user’s behalf, so plan for that step in your rollout communications rather than trying to automate it away.
Windows: silent install
The Windows installer is built with NSIS, so it accepts NSIS command-line switches.The basic command
/S switch is case-sensitive. Run it from the directory holding the installer, or pass the full path:
Installing to a specific directory
Use/D= to override the default install location:
/D= must be the last parameter on the line, and the path takes no quotes, even when it contains spaces.
Wrapping it for an RMM or Intune
Wrap the installer so your deployment tool waits for it to finish instead of moving on and reporting success early: powershell.intunewin) and use that script, or the raw /S command, as your install command. Test your uninstall command and detection rule against a single machine before you scale the assignment out, since both depend on the install path and app version you end up with.
Things to watch:
- The installer runs in user scope, not machine-wide. If your deployment tool runs it in the SYSTEM account context, the install may land somewhere the user cannot reach, or fail outright. Deploy in user context where your tooling allows it.
- Windows Defender sometimes flags the installer during background installs. It behaves differently when the file is launched by a user versus pushed silently by an agent process. If your first pilot machines come back with a failed install and a Defender event, add an exclusion for the installer path and retry.
- This method is best-effort, not an officially supported deployment path. The switch works, and it is what we recommend to admins who ask. It is not currently covered by a supported-configuration guarantee, so run a pilot group before you commit to a fleet-wide rollout.
macOS
CloudTalk ships the Mac app as a standard macOS application download. There is no.pkg and no vendor-supplied deployment script.
To push it, use your MDM’s own packaging path: build a signed package from the app bundle with the tool your platform provides (Jamf Composer, Munki, a pkgbuild wrapper, or your MDM’s custom-app upload), then deploy it as you would any other in-house-packaged app.
Two things to plan around:
- Microphone and notification prompts still appear on first launch. Apple does not allow a PPPC profile to grant microphone access on the user’s behalf, so this stays a user action no matter how the app arrives.
- You own the update path. Whatever you package, you will need a process for pushing the next version.
The no-install option
CloudTalk Phone runs in the browser at phone.cloudtalk.io, with the same calling functionality as the desktop app. For locked-down environments, kiosk machines, contractors, or anyone whose device you do not manage, this is usually faster than packaging anything. Push a bookmark or a managed browser policy and you are done. It is also a reasonable fallback for the handful of machines that fail an automated install.Mobile devices
The mobile app, CloudTalk Go, is a public listing on the App Store and Google Play, so it deploys through the standard managed-app channels. No file from CloudTalk is needed.- iOS: Acquire CloudTalk Go licences in Apple Business Manager under Apps and Books (the app is free), assign them device-based, and push from your MDM. This works even when App Store browsing is blocked on the device, because MDM-managed installs and App Store browsing are two independent restrictions. The device does have to be MDM-enrolled: blocking the App Store on an unenrolled personal phone leaves no managed path in.
- Android: Assign the app through Managed Google Play from your EMM console.
Planning your updates
Decide up front how new versions reach your endpoints. Either allow the app’s own update mechanism to run where your policy permits it, or push each new installer through the same channel you used for the first deployment. Fleets that block self-updates and then never re-push tend to end up with a wide spread of versions, which makes troubleshooting call quality issues considerably harder later.FAQs
-
Is there an MSI?
Not today. The Windows installer is an NSIS executable with the
/Ssilent switch described above.
- Is there a PKG for Mac? Not today. Package the app bundle with your MDM’s tooling.
- Can I extract an MSI from the EXE? No. There is no MSI embedded in the installer. If your deployment tooling requires MSI specifically, repackage the EXE with a third-party wrapper, or use the browser option.
- Can I restrict which machines or IP addresses agents log in from? Not through CloudTalk. If you enforce SSO through your identity provider, conditional access rules on the IdP side can apply, but that is configured and owned in your environment rather than in CloudTalk.
- Who do I contact if a rollout stalls? Your CloudTalk account contact, or our support team. Bring the installer version, the deployment tool, whether it ran in user or SYSTEM context, and the error your tool reported.
Need help or have a question? Just reach out through our Support portal — we are here for you.