Skip to main content

Deploying CloudTalk Phone across a fleet

A guide for IT administrators rolling out CloudTalk Phone to more than a handful of machines.

V
Written by Valeriia Volobrinskaia

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.

User level: Admin


For basic single-machine installation steps, see Installing CloudTalk Phone.

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

Requirement

Windows

Windows 10 or 11, 64-bit. Windows 7, 8, and 8.1 are no longer supported.

macOS

macOS 11 (Big Sur) or later

Linux

64-bit, via AppImage

Memory

4 GB minimum, 8 GB recommended

CPU

Intel i5 / AMD Ryzen 5 or equivalent

Network

About 100 kbps per concurrent call. Budget roughly 1 Mbps per person as a working baseline.

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

CloudTalk-Phone-<version>-win.exe /S

The /S switch is case-sensitive. Run it from the directory holding the installer, or pass the full path:

C:\Deploy\CloudTalk-Phone-<version>-win.exe /S

Installing to a specific directory

Use /D= to override the default install location:

CloudTalk-Phone-<version>-win.exe /S /D=C:\Custom Folder\CloudTalk

Two rules that trip people up: /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

$installerPath = "C:\Deploy\CloudTalk-Phone-<version>-win.exe"  Start-Process -FilePath $installerPath -ArgumentList "/S" -Wait -NoNewWindow  Write-Host "CloudTalk Phone deployment complete."

For Intune, package the installer as a Win32 app (.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.

If you would rather not maintain a package, the browser option below removes the problem entirely for Mac users.

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.

On both platforms, updates arrive when your admin pushes them, and first-launch permission prompts still apply.

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 /S silent 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.

Did this answer your question?