Sprecho wird als gewöhnliche signierte Installationspakete ausgeliefert und lässt sich damit über alles verteilen, was ihr ohnehin einsetzt — Microsoft Intune, Jamf, Gruppenrichtlinien, Munki, Ansible oder einen Link per E-Mail. Es gibt keinen MDM-Konnektor auf Sprecho-Seite zu konfigurieren, und es braucht auch keinen.
Einplanen musst du nur eines: Die Geräteregistrierung passiert bei der Anmeldung, nicht bei der Installation. Das prägt den Rollout.
Woher die Installationspakete kommen
Öffne die Enterprise-Konsole unter enterprise.sprecho.ai und gehe zu Downloads. Die Seite ist für Team-Inhaber und Admins sichtbar und bietet:
| Plattform | Paket | Hinweis |
|---|---|---|
| Windows | .msi |
Beschriftet mit „MSI (für IT-Verteilung)". Dieses Paket verteilst du |
| Windows | .exe |
Das Installationsprogramm für Endanwender von der öffentlichen Download-Seite |
| macOS | .dmg |
Getrennte Builds für Apple Silicon und Intel, mit Developer-ID-Zertifikat signiert |
| Linux | .deb |
Für Debian- und Ubuntu-Flotten |
Die MSI ist ein normales Windows-Installer-Paket und verhält sich in eurem Werkzeug wie jede andere MSI — als Win32- oder Branchen-App in Intune paketieren oder als Richtlinie per Gruppenrichtlinie verteilen, mit den üblichen Optionen für die unbeaufsichtigte Installation.
macOS kommt als DMG, nicht als PKG. Jamf kann eine per DMG ausgelieferte App verteilen; setzt euer Ablauf ein PKG voraus, müsst ihr neu paketieren. Wenn das euren Rollout blockiert, schreib an support@sprecho.ai.
Für Terminalserver und Windows-Mehrbenutzerumgebungen liegt auf derselben Seite ein eigener Agent als MSI. Siehe Sprecho über Remotedesktop und Terminalserver nutzen.
Wie ein Gerät ins Team kommt
- Euer Verwaltungstool installiert Sprecho. Konfiguriert wird dabei nichts, und die App nimmt keinen Kontakt zum Team auf.
- Die Person startet Sprecho und meldet sich an — am besten per SSO, dann ist auch kein Passwort zu verteilen.
- Die App registriert sich selbst im Team des Kontos. Ab diesem Moment erhält sie eure Geräterichtlinie und erscheint in der Geräteliste der Konsole.
Das ist der gesamte Ablauf. Es gibt kein Konfigurationsprofil, keine
.mobileconfig und kein gerätebezogenes Registrierungstoken, das vorab auf die
Maschine gehört — die Zugehörigkeit zum Team trägt das Konto.
Praktische Folge: Ein Gerät, das ihr zwar aufgesetzt habt, auf dem sich aber noch niemand angemeldet hat, taucht in der Konsole nicht auf. Richtet SSO deshalb vor der Massenverteilung ein, damit der erste Start bereits ein Ziel zum Anmelden hat.
Updates zentral steuern
Verwaltete Flotten wollen meist die Kontrolle über Updates, und die Geräterichtlinie liefert sie:
- Automatische Updates aus — der eingebaute Updater wird komplett übersprungen. Die Geräte wechseln die Version dann nur, wenn ihr ein neues Paket verteilt. Genau das braucht eine änderungskontrollierte Umgebung.
- Update-Kanal — stabil, Beta oder eine festgelegte Version.
- Frist bei erzwungenem Update — wie lange nach einer angeforderten Aktualisierung weitergearbeitet werden darf, voreingestellt 24 Stunden.
Diese Punkte stehen zusammen mit dem Rest der Richtlinie — erlaubte Sprachen, erlaubte Zeiten, sperrbare Einstellungen — in registrierte Geräte verwalten.
Ein Rollout, der glattgeht
- Kauf zuerst genug Plätze. Ohne freie Lizenz kann sich ein Mitglied per SSO gar nicht anmelden.
- Richte SSO ein und teste es samt Domain-Bestätigung, bevor die Installation ausrollt.
- Setz die gewünschte Geräterichtlinie vorab, damit sie schon beim ersten Heartbeat greift und nicht eine Woche später das Verhalten ändert.
- Verteile das Paket an eine Pilotgruppe von fünf bis zehn Personen und beobachte, wie sie in der Konsole auftauchen.
- Roll den Rest aus und nutze die Geräteliste, um Maschinen zu finden, auf denen sich nie jemand angemeldet hat.
Weise unter macOS darauf hin, dass die App beim ersten Start die Freigaben für Mikrofon und Bedienungshilfen braucht. Das sind benutzerbezogene macOS-Abfragen, die kein Installationsprogramm beantworten kann. Siehe Mikrofon und Bedienungshilfen freigeben.