Workspace ONE Modern SaaS (ModStack): Was die neue Architektur bedeutet – und warum On-Prem 2410 die Endstation ist

27. Juli 2026 / / Keine Kommentare

Wer On-Prem betreibt, sollte die Migration jetzt planen: Shared SaaS, Preferred SaaS (dedizierter Tenant, ohne Re-Enrollment der Geräte) oder – für regulierte Umgebungen – die partner-gehostete Sovereign Solution.

Wenn ihr in den letzten Monaten Omnissa-Blogs, KB-Artikel oder Community-Posts verfolgt habt, seid ihr an einem Begriff nicht vorbeigekommen: Modern SaaS Architecture, intern und in der Community meist ModStack (Modern Stack) genannt. Klingt erstmal nach Marketing – ist aber die größte technische Umbaumaßnahme in der Geschichte der Plattform seit den AirWatch-Tagen. Und sie hat handfeste Konsequenzen: für die tägliche Administration, für die Feature-Roadmap und vor allem für alle, die noch On-Premises unterwegs sind.

In diesem Beitrag erkläre ich, was ModStack technisch ist, warum Omnissa diesen Schritt geht, welche Features die neue Architektur bereits gebracht hat und noch bringen wird – und wo für On-Prem-Kunden die harte Deadline liegt.

Was ist ModStack? Der Umbau plausibel erklärt

Workspace ONE UEM stammt architektonisch aus der AirWatch-Ära: ein monolithischer Stack aus Windows-Servern (Console, Device Services, AWCM, API) und einer zentralen MS-SQL-Datenbank. Dieselbe Codebasis lief On-Prem beim Kunden und in Omnissas SaaS-Rechenzentren – die SaaS war im Kern eine gehostete On-Prem-Installation.

Das Modell hat zwei strukturelle Probleme. Erstens die Skalierung: Ein Monolith skaliert nur als Ganzes – wer mehr Enrollment-Durchsatz braucht, muss den kompletten Stack größer ziehen, auch wenn nur eine Teilfunktion am Limit ist. Zweitens die Release-Geschwindigkeit: Jede Änderung muss durch den gesamten Monolithen getestet und als großes Release ausgerollt werden. Quartalsweise Major-Releases plus Patch-Zyklen waren die Folge – in einer Welt, in der Apple und Google im Wochentakt neue MDM-Anforderungen liefern, ein echtes Handicap.

ModStack löst beides, indem das Backend in Microservices zerlegt wird: einzelne, unabhängig deploybare Dienste (Enrollment, Profil-Engine, App-Delivery, Event-Verarbeitung usw.) in Containern, orchestriert in einer Cloud-nativen Umgebung. Jeder Dienst skaliert für sich, jeder Dienst kann einzeln aktualisiert werden – ohne Big-Bang-Release, ohne Wartungsfenster für die ganze Plattform. Die Kommunikation zwischen UEM und Geräten wurde laut Omnissa dabei um mehr als das Zehnfache beschleunigt: Neue Apps und Settings kommen praktisch sofort auf dem Gerät an („Desired State“ statt Polling-Warterei).

Warum macht Omnissa das?

  • Innovationsgeschwindigkeit: Features können pro Microservice entwickelt und ausgerollt werden. Bestes Beispiel: Die Apple-DDM-Integration importiert Declarative-Management-Konfigurationen inzwischen automatisch aus Apples GitHub-Repository – Day-0-Support für neue iOS-Releases (z. B. iOS 26), ohne dass die Plattform ein Versions-Upgrade braucht.
  • Skalierung und Resilienz: Lastspitzen (Massen-Enrollments, große Rollouts) treffen nur die betroffenen Dienste, die horizontal skalieren. Ausfälle bleiben lokal begrenzt statt die Konsole komplett zu reißen.
  • Infrastruktur-Neutralität: Die containerisierte Architektur läuft auf Public Clouds ebenso wie in privaten Rechenzentren. Genau das ermöglicht die neue Omnissa Sovereign Solution – ein von qualifizierten Partnern komplett lokal gehostetes, modernes UEM für regulierte Branchen (Stichwort GDPR, BDSG, CLOUD-Act-Risiken).
  • Eine Codebasis statt zwei Welten: Die Pflege des On-Prem-Monolithen parallel zur SaaS band Entwicklungsressourcen. Die Konsequenz ist bekannt – und Thema des letzten Abschnitts.

Was ModStack an Features bringt – heute und morgen

Bereits verfügbar (auf Modern-SaaS-Umgebungen)

  • Massiv beschleunigte Geräte-Kommunikation und häufigere Desired-State-Abgleiche – Profile und Apps erreichen Geräte deutlich schneller.
  • Fast Lane Deployment für sofortige Auslieferung kritischer Updates.
  • App-Exclusions auf Versions-Ebene statt pauschal pro Bundle-ID – granulareres App-Management (Achtung, Verhaltensänderung – siehe Warn-Box unten).
  • Verbesserte Troubleshooting-Event-Logs mit mehr Detailtiefe in der Konsole.
  • Apple DDM mit automatischem Konfigurations-Import aus dem Apple-GitHub-Repository (Day-0-Support ohne Plattform-Upgrade).
  • Intelligence-UEM Modern Integration: komplett überarbeitete Datenpipeline mit End-to-End-Monitoring, erweitertem Schema und Daten-Joins in Dashboard-Widgets (erfordert Modern Architecture 2506 Patch 16 oder neuer).

Auf ModStack gebaut: die Feature-Welle 2602/2604

Die jüngsten Releases zeigen, wofür der Umbau gemacht wurde – dieses Tempo und diese Feature-Dichte wären auf dem Monolithen kaum denkbar gewesen:

  • Next-Gen Windows Management: Intelligent Hub Managed Mode ohne OMA-DM-Abhängigkeit, koexistenzfähig mit SCCM/anderen MDMs, Server-side Step-up von Registered zu Managed – und Windows Server Management (GA in 2604).
  • Vulnerability Defense (Limited Availability, 2604): CVE-zu-Endpoint-Mapping mit CrowdStrike-Integration und Remediation direkt aus der Konsole.
  • Enterprise App Repository für Windows (10.000+ Apps) und macOS (kuratierter Katalog mit Auto-Updates).
  • Phased App Deployments, eSIM-Management für Android, erweiterte AMAPI-Policies, modernisierte Konsolen-UI – die Liste wächst mit jedem Release.

Die Richtung ist klar: Neue Features erscheinen zuerst – und zunehmend ausschließlich – auf der Modern-SaaS-Schiene.

On-Premises: Endstation 2410 – die Fakten zur Deadline

Die Kehrseite der ModStack-Strategie: Der On-Prem-Monolith wird nicht auf die neue Architektur portiert. Das bedeutet im Klartext:

Frage Antwort
Bis zu welcher Version kann On-Prem upgegradet werden? Workspace ONE UEM 2410 (24.10) ist die letzte installierbare On-Prem-Version. Einen Upgrade-Pfad auf 2412, 25xx oder 26xx gibt es nicht.
Gibt es noch Patches? Ja – bis zum End of Support werden für 2410 weiterhin Patches bereitgestellt, aber keine neuen Funktionen.
Wann ist Schluss? End of Support: 30. April 2027. Danach gibt es weder Patches noch Support.
Bis wann sollte migriert werden? Deutlich vor dem 30.04.2027 – die Migration selbst (inkl. ACC/UAG/SEG-Neuaufbau, Tests, ggf. Re-Enrollment) braucht je nach Umgebung mehrere Monate Vorlauf. Alle Komponenten müssen für eine unterstützte Migration auf supporteten Versionen laufen.

Wichtig zur Einordnung der Frage „bis wann kann ich noch zu SaaS migrieren“: Es gibt keinen technischen Stichtag, an dem die Migration abgeschaltet wird. Aber nach dem 30.04.2027 betreibt ihr eine unsupportete, ungepatcht alternde Plattform – jede Migration von dort ist ein Risiko-Projekt ohne Herstellerrückendeckung. Praktisch ist der 30.04.2027 daher die Deadline, bis zu der die Migration abgeschlossen sein sollte, nicht gestartet.

Die drei Migrationspfade

Pfad Modell Besonderheit
Shared SaaS Public Cloud, geteilte Ressourcen Kostengünstigster Einstieg; Re-Enrollment der Geräte erforderlich
Preferred SaaS Public Cloud, dedizierter UEM-Tenant Migration ohne Re-Enrollment der Geräte möglich (Device Migration); höhere Kosten
Sovereign Solution Partner-gehostet im lokalen Rechenzentrum Für regulierte Branchen (Energie, Finanzen, Healthcare, Public); volle Datensouveränität auf ModStack-Basis

Fazit

ModStack ist kein Buzzword, sondern die Grundlage für alles, was bei Workspace ONE in den nächsten Jahren passiert – von Day-0-OS-Support über Next-Gen Windows Management bis zur Sovereign Solution. Für SaaS-Kunden heißt das: schnellere Features, aber auch ein paar Verhaltensänderungen, die man vor der Umstellung sauber vorbereitet. Für On-Prem-Kunden heißt es: 2410 ist das Ende des Weges, am 30. April 2027 fällt der Vorhang. Wer jetzt mit der Migrationsplanung beginnt, wandelt die Pflicht in eine Chance – und landet auf einer Plattform, die technologisch endlich wieder vorne mitspielt.

Intelligent Hub Registrierungsfehler nach Backup-Restore: Warum die iOS Keychain dein Enrollment killt

24. Juli 2026 / / Keine Kommentare

Intelligent Hub Registrierungsfehler nach Backup-Restore: Warum die iOS Keychain dein Enrollment killt

Das Fehlerbild

Folgendes Szenario landete diese Woche auf meinem Tisch: Ein iPhone (nicht supervised, Hub-basiertes Enrollment) wird registriert. Schritt 1 und 2 im Hub laufen sauber durch, das MDM-Profil ist installiert – und dann knallt es:

Fehler

Die Registrierung konnte nicht abgeschlossen werden.

Bitte registrieren Sie das Gerät erneut oder wenden Sie sich an Ihren Administrator.

Das Kuriose daran: Aus Sicht der UEM-Konsole ist alles in Ordnung. Das Gerät ist enrolled, Profile werden gepusht und installiert, Compliance läuft, der Benutzer ist in allen Gruppen korrekt zugeordnet. Nur der Intelligent Hub selbst kommt nicht über seine Registrierung hinaus. Und um es noch besser zu machen: Das andere iPhone desselben Benutzers funktioniert ohne Probleme.

Wichtig für das Verständnis: MDM-Enrollment und Hub-Registrierung sind zwei getrennte Vorgänge. Apples mdmclient redet mit den Device Services und installiert das Profil – das lief hier fehlerfrei. Danach macht die Hub-App ihren eigenen Handshake (Token-Austausch plus Hub Services Check-in), um sich mit dem Device Record zu pairen. Und genau der scheiterte.

Was nicht geholfen hat

Die üblichen Verdächtigen wurden der Reihe nach abgearbeitet – ohne Erfolg:

Maßnahme Ergebnis
Device Record auf Duplikate geprüft (Suche per Seriennummer/UDID) Kein doppelter oder veralteter Eintrag vorhanden
Geräte → Lebenszyklus → Registrierungsstatus geprüft Kein verwaister Eintrag, alles sauber
Hub-App gelöscht, Gerät neu gestartet, Hub neu installiert Identischer Fehler beim nächsten Versuch
Enrollment komplett neu (Profil entfernt, Record gelöscht, Re-Enrollment) MDM läuft, Hub-Registrierung scheitert erneut
Benutzer, Gruppen, Enrollment Restrictions geprüft Alles korrekt – zweites Gerät des Users funktioniert

Wenn Konsole, Benutzer und Netzwerk sauber sind und selbst ein komplettes Re-Enrollment nichts ändert, bleibt nur noch eine Erkenntnis: Das Problem liegt auf dem Gerät selbst – und zwar an einer Stelle, die weder App-Neuinstallation noch Re-Enrollment anfasst.

Die Ursache: Die Keychain aus dem Backup

Der entscheidende Hinweis kam aus der Vorgeschichte des Geräts: Es wurde bei der Einrichtung aus einem verschlüsselten iTunes-Backup wiederhergestellt. Und damit war der Fall klar.

Verschlüsselte lokale Backups sichern die komplette Keychain

Verschlüsselte iTunes-/Finder-Backups sichern die iOS Keychain vollständig mit – inklusive der Keychain-Einträge von Third-Party-Apps. Der Intelligent Hub legt genau dort seine Enrollment-Identität ab: das Authentifizierungs-Token, mit dem er sich gegenüber den Device Services als „dieses eine, bereits registrierte Gerät“ ausweist.

Beim Restore kommt diese Identität eins zu eins zurück auf das Gerät. Das Problem: Sie gehört zu einem Enrollment, das serverseitig längst nicht mehr existiert – in unserem Fall war das alte Enrollment vor dem Restore per Enterprise Wipe aus dem MDM entfernt worden. Der Hub präsentiert dem Server also bei jeder Registrierung ein Token, zu dem es keinen Datensatz mehr gibt. Der Server lehnt ab, der Hub wirft die generische Fehlermeldung.

Warum Hub löschen und neu installieren nichts bringt

Hier kommt die zweite iOS-Eigenheit ins Spiel, über die man erst stolpern muss: iOS löscht die Keychain-Einträge einer App bei deren Deinstallation nicht. Der frisch aus dem App Store installierte Hub findet beim ersten Start die alte Identität in der Keychain, verwendet sie – und scheitert exakt gleich. Man kann die App so oft neu installieren, wie man will.

Warum das MDM trotzdem funktioniert

Konfigurationsprofile und der MDM-Verwaltungsstatus sind grundsätzlich nicht Teil von iOS-Backups. Das frische MDM-Enrollment, das nach dem Restore durchgeführt wurde, ist also vollkommen intakt – Apples mdmclient weiß nichts von der Keychain-Leiche und arbeitet brav seine Commands ab. Deshalb das paradoxe Bild: Gerät voll gemanagt, Hub tot.

Info

Diagnose-Tipp: Wenn der Hub nicht bis zum Login kommt, gibt es auch keinen Diagnosebericht aus der App heraus. Alternative: iPhone per USB an einen Mac, Console.app öffnen, Gerät auswählen und den Live-Stream beim Reproduzieren des Fehlers mitschneiden. Filter auf den Hub-Prozess bzw. Suchbegriffe wie „AirWatch“, „awmdm“ oder „deviceservices“. Ein 401/403 beim Registration-Call gegen die Device Services ist die Bestätigung für ein verwaistes Token.

iTunes-Backup vs. iCloud-Backup: Der feine Unterschied

An dieser Stelle lohnt ein Blick in die Apple Platform Security Dokumentation, denn die beiden Backup-Verfahren behandeln die Keychain fundamental unterschiedlich – und genau dieser Unterschied entscheidet darüber, ob euch das Problem beim nächsten Gerätetausch wieder einholt:

Eigenschaft Verschlüsseltes lokales Backup iCloud-Backup
Keychain wird gesichert Ja, vollständig Ja, vollständig
Schutz der Keychain Backup-Passwort (PBKDF2) Gerätespezifischer Hardware-Key (Secure Enclave UID)
Restore auf anderes Gerät Keychain wandert mit (außer ThisDeviceOnly-Items) Keychain wird verworfen – Rest kommt an
Restore auf dasselbe Gerät Keychain kommt zurück Keychain kommt zurück
Risiko im MDM-Kontext Hub-Identität wandert beim Gerätetausch mit Beim Gerätetausch sauber, beim Same-Device-Restore nicht

Kurz gesagt: Das iCloud-Backup verschlüsselt die Keychain mit einem Schlüssel, der aus der Secure Enclave des Geräts abgeleitet wird. Diese Keychain lässt sich damit ausschließlich auf exakt dieselbe Hardware zurückspielen. Beim Gerätetausch bleibt die Hub-Identität des Altgeräts also automatisch auf der Strecke – genau das, was wir im MDM-Umfeld wollen. Das verschlüsselte lokale Backup dagegen schützt die Keychain nur mit dem Backup-Passwort und transportiert sie damit fröhlich auf jede beliebige neue Hardware.

Achtung

Der iCloud-Vorteil greift nur beim Wechsel auf ein anderes Gerät! Wird ein Backup – egal ob lokal oder iCloud – auf dasselbe Gerät zurückgespielt, kommt die Keychain in beiden Fällen zurück. Für ein Re-Enrollment desselben Geräts ist daher grundsätzlich keine Backup-Wiederherstellung geeignet. Und: Auch die Quick-Start-Direktübertragung von Gerät zu Gerät migriert die Keychain – die ist im MDM-Kontext genauso tabu wie das verschlüsselte lokale Backup.

Die Lösung für das betroffene Gerät

Die restaurierte Keychain lässt sich auf dem Gerät nicht selektiv bereinigen – ohne Jailbreak kommt man an die Einträge einer fremden App schlicht nicht ran. Es hilft also nur der harte Schnitt:

  1. MDM-Profil auf dem Gerät entfernen und Device Record in der Konsole löschen (inklusive Check unter Geräte → Lebenszyklus → Registrierungsstatus).
  2. Gerät auf Werkseinstellungen zurücksetzen und als neues iPhone einrichten – ohne Backup-Wiederherstellung.
  3. Enrollment über den Intelligent Hub durchführen und die Registrierung vollständig abschließen, bevor irgendetwas anderes am Gerät passiert.
  4. Persönliche Daten anschließend über die iCloud-Synchronisierungsdienste zurückholen: Fotos, Kontakte, Kalender, Mail und Passwörter via iCloud-Schlüsselbund. Diese Dienste synchronisieren Inhalte, ohne die lokale Keychain des Geräts zu überschreiben.

Ja, ein Factory Reset ist genau das, was man bei einem fertig eingerichteten Endanwender-Gerät vermeiden will. Aber die Kombination aus restaurierter Keychain und gewiptem Device Record ist device-seitig anders schlicht nicht zu reparieren – da hilft auch keine noch so kreative Reihenfolge aus Löschen, Neustarten und Neu-Enrollen.

Der richtige Workflow für die Zukunft

Damit euch das Thema nicht beim nächsten Gerätetausch wieder auf die Füße fällt, hier die Empfehlung für die beiden relevanten Szenarien:

Szenario Empfohlen Vermeiden
Gerätetausch (neue Hardware) Neugerät als neues Gerät einrichten, MDM-Enrollment durchführen, persönliche Daten via iCloud-Dienste synchronisieren. Alternativ: Restore aus iCloud-Backup. Verschlüsseltes lokales Backup (iTunes/Finder/Apple Devices App), Quick-Start-Direktübertragung
Re-Enrollment desselben Geräts (z. B. Benutzerwechsel, Austritt) Factory Reset und Einrichtung als neues Gerät. Immer. Jede Form von Backup-Restore – auch iCloud, da auf identischer Hardware die alte Keychain zurückkehrt
Generell Enrollment immer auf frisch eingerichtetem Gerät, Hub-Registrierung komplett abschließen, bevor weitere Schritte folgen Backup-Restore nach oder während des Enrollments
Tipp

Firmen-Apps und -Konfigurationen müssen ohnehin nicht aus einem Backup kommen – die pusht euer MDM nach dem Enrollment automatisch aufs Gerät. Wer die persönlichen Daten der Anwender konsequent über iCloud-Dienste synchronisiert statt über Backups transportiert, hat beim Gerätetausch den saubersten und nebenbei auch den schnellsten Prozess.

Fazit

Ein Fehlerbild, das auf den ersten Blick nach Konsolen- oder Netzwerkproblem aussieht, entpuppt sich als Apple-Security-Feature mit Nebenwirkungen: Die Keychain überlebt App-Deinstallationen und reist in verschlüsselten lokalen Backups mit – inklusive der Enrollment-Identität des Intelligent Hub. Wer das Verhalten der beiden Backup-Verfahren kennt, erspart sich stundenlanges Troubleshooting an Stellen, an denen das Problem gar nicht liegt. Und wer seinen Gerätetausch-Workflow einmal sauber definiert, sieht diesen Fehler nie wieder.

 

Intune Release 2606: macOS Auto-Updates & Android Enterprise

13. Juli 2026 / / Keine Kommentare

Intune Release 2606: macOS-Updates im Autopilot, Android Enterprise wird erwachsen

Mal ehrlich – wer kennt das nicht? Sie spielen neue macOS-App-Versionen ein, und die Nutzer vergessen grundsätzlich, auf „Install“ oder „Reinstall“ in Company Portal zu klicken. Die Release 2606 setzt dem ein Ende. Aber das ist nur die Spitze des Eisbergs. Diese Week ist vollgepackt mit Updates, die vor allem macOS-Admins und Android Enterprise-Spezialisten freuen werden.

Lass mich durchgehen, was sich ändert und wo du handeln musst.

Quick-Überblick: Was ändert sich?

Feature Plattform Kategorie Priorität
macOS PKG Auto-Updates macOS App Management 🔴 Hoch
ChatGPT als Protected App Alle App Management 🟡 Mittel
EAM für GCC High/DoD Windows Enterprise Management 🔴 Hoch
EAM Auto-Update-Feature Windows App Management 🟡 Mittel
15+ neue Android Enterprise Settings Android Device Config 🟢 Standard

Die Highlights im Detail

🍎 macOS PKG Apps updaten sich jetzt selbst

Das ist echte Arbeitserleichterung: Wenn du eine verfügbare macOS PKG-App mit einer neueren Version hochlädst, deployt Intune das Update automatisch auf Geräte, auf denen die App bereits installiert ist.

Das funktioniert so:
– Du editierst eine bestehende App-Policy
– Lädst eine neuere Version der gleichen App hoch (gleiche Bundle ID)
– Intune erkennt das und rolled den Update automatisch aus
– Der Nutzer klickt nirgendwo auf „Install“ – es passiert einfach

Wichtig – Breaking Change:
Dafür brauchst du Microsoft Intune management agent for macOS Version 2606.013 oder neuer. Wenn Geräte noch älter sind, funktioniert der Auto-Update nicht. Das sollte in deiner Pre-Deployment-Checklist stehen.

Praktisches Beispiel:
Du hast Microsoft Edge 127.0 deployed. Jetzt kommt 127.0.1 raus. Du lädst die neue Version hoch → Intune pusht’s automatisch. Schluss mit Suppor-Tickets „Warum hab ich noch die alte Version?“

🤖 ChatGPT ist jetzt eine Protected App

Microsoft hat ChatGPT zur Liste der Protected Apps hinzugefügt. Das bedeutet, es unterliegt jetzt Intune App Protection Policies (APP) – Conditional Access, Offline-Sperren, Clipboard-Restrictions et cetera.

Das ist ein Signal: KI-Tools werden zunehmend ernst genommen in der Enterprise-Sicherheit. Wenn du sensible Daten schützen musst, kannst du ChatGPT jetzt granular steuern, ohne es zu blocken.

🏛️ Enterprise App Management jetzt auch für GCC High & DoD

Das ist Government-spezifisch wichtig: Microsoft bringt Enterprise App Management (EAM) in die GCC High (GCCH) und DoD Cloud-Umgebungen.

Was heißt das?
Gouvernementale Organisationen können jetzt im EAM-Katalog Microsoft- und Third-Party-Apps entdecken, deployen und updaten – ohne manuelle Repackaging. Ein sichere Cross-Cloud-Integration wahrt Compliance-Grenzen und Auth-Requirements für Government Tenants.

Impact für Government IT-Admins:
– Weniger manuelle App-Packaging-Arbeit
– Native Compliance mit FedRAMP/DoD-Anforderungen
– Schnellere App-Rollouts in sensitiven Umgebungen

⚡ EAM Auto-Update – Supersedence auf Autopilot

Neben GCC-Support kommt auch Auto-Update für EAM-Apps. Wenn du ein EAM-App mit required Assignment deployst und Auto-Update aktivierst:

  1. Intune erkennt eine neue Version im EAM-Katalog
  2. Update wird automatisch auf Zielgeräten installiert
  3. Keine manuellen Packaging-/Supersedence-Workflows mehr

Das spart:
– Zeitaufwand für Update-Management
– Fehleranfälligkeit durch manuelle Versionsersetzung
– Sicherheitslücken durch veraltete Apps

Wichtig: Das gilt nur für required Assignments. „Available“ Apps musst du noch manuell managen (das ist absichtlich, damit Nutzer die Kontrolle behalten).

🤖 Android Enterprise: 15+ neue Settings im Settings Catalog

Das ist die große Erweiterung: Intune 2606 bringt etwa 15 neue Android Enterprise Settings in den Settings Catalog. Hier die wichtigsten Kategorien:

Applications

  • Block apps from exposing app functions – Verhindert, dass verwaltete Apps Funktionen für andere Apps/KI-Agenten freigeben (COBO, COSU, COPE)
  • Block widgets from work profile apps – Widgets aus Work-Profile-Apps vom Home Screen blockieren (COPE)

Connectivity (neu in 2606)

  • Allow selection of a preferential network service – Priorisiert bestimmte Netze (z.B. 5G Enterprise Slice)
  • Block airplane mode – Flugzeugmodus deaktivieren
  • Block cellular 2G – Nur auf Android 14+; verhindert 2G-Fallback
  • Block configuring cell broadcasts – Notfall-Alerts blockieren (⚠️ – das kann problematisch sein!)
  • Block configuring mobile networks – Nutzer darf Netz-Settings nicht ändern
  • Block configuring VPN – VPN-Konfiguration durch Nutzer verhindern
  • Block network reset – Netzwerk-Reset unterbinden
  • Block outgoing calls – Telefonie komplett deaktivieren
  • Block SMS – SMS-Versand/-Empfang blockieren
  • Block ultra wideband – UWB (Android 14+) deaktivieren
  • Select minimum Wi-Fi security level – Erzwingt WPA3-Pers/Enterprise (Android 13+)

General

  • Block printing – Drucken verhindern
  • Block setting user icon – Profilbild ändern verhindern
  • Block setting wallpaper – Wallpaper-Änderung sperren
  • Block users from adding eSIM profiles – eSIM-Management blockieren

Device Type Support:

  • COBO – Corporate-Owned, Fully Managed
  • COSU – Corporate-Owned, Shared/Dedicated
  • COPE – Corporate-Owned, Personal-Enabled (Work Profile)

Meine Einschätzung: Das sind Sicherheits-Heavy-Hitter, besonders für:
– Kiosk-Devices (COSU) – Printing, Calls, SMS sperren
– Rugged Devices – 2G-Block, UWB-Control
– BYOD-ähnliche Szenarien (COPE) – Granulare Widget-Kontrolle

That’s it. Microsoft macht aktuell echt viel in Intune und versucht sich einer Omnissa mit großen Schritten zu nähern. Aber alles in allen. Omnissa rennt weiter und ist bis dato für mich immer noch das Top of the Top UEM/MDM.

Quellen

Intune 2605: Multiple Accounts, Apple Intelligence & MHS

5. Juli 2026 / / Keine Kommentare

Intune Release 2605: Multiple Accounts, Apple Intelligence Umbruch & MHS-Power-Up

Die Juni-Release 2605 fällt mir sofort durch zwei Dinge auf: Da kommt endlich Multi-Account-Support für Teams (nur iOS/iPadOS – Android schaut in die Röhre), und Apple dreht bei Intelligence-Einstellungen ordentlich am Rad. Wer noch alte MDM-Restrictions für Apple Intelligence setzt, muss sich umorientieren. Dazu neue MHS-Features, die Kiosk-Szenarien smarter machen. Lass uns durchgehen, was sich ändert.

Quick-Überblick: Was ändert sich?

Feature Plattform Kategorie Priorität
Multiple Managed Accounts iOS/iPadOS (Teams) App Management 🟡 Mittel
Custom Top Bar (MHS) Android Enterprise Device Config 🟡 Mittel
MHS Lock Task Password Migration Android Enterprise Breaking Change 🔴 Hoch
Block Bluetooth Sharing Android Enterprise Device Config 🟢 Niedrig
Apple Intelligence Settings Deprecation iOS/iPadOS, macOS Breaking Change 🔴 Hoch
App Silencing (MHS) Android Enterprise Device Config 🟡 Mittel
Microsoft Edge NTP Feed Settings Windows Device Config 🟢 Niedrig

Die Highlights im Detail

Multiple Managed Accounts für Microsoft Teams (iOS/iPadOS)

Das ist endlich praktisch: Nutzer können jetzt mehr als ein verwaltetes Konto in derselben App (konkret: Teams) hinzufügen und managen. Jedes Konto bekommt eigene App Protection Policies – perfekt für:

  • Berater & Consultants mit Kundenzugängen
  • M&A-Teams mit mehreren Tenant-Zugehörigkeiten
  • Multi-Mailbox-Szenarien (Compliance, HR, etc.)

Aktuell nur Teams v8.10.0+ auf iOS/iPadOS. Android und weitere Apps folgen später – das ist ein klassisches „Coming Soon“. Rollout erfolgt graduell, also nicht bei allen Tenants sofort verfügbar.

 

Custom Top Bar Text in Managed Home Screen

Die MHS bekommt mehr Flexibilität: Statt nur Serial Number, Device Name und Tenant Name kannst du jetzt Custom Text (bis 63 Zeichen) setzen. Bonus: Dynamic Variables werden unterstützt:

  • {{SerialNumber}}
  • {{DeviceName}}
  • {{TenantName}}

Praktische Anwendungen:
– Checkout-Kioske: "Register 03 - {{DeviceName}}"
– Departmental Tagging: "Warehouse - {{SerialNumber}}"
– Konferenzraum-Kioske: "Meeting Room 4B"

Applies to: Android Enterprise COSU (Dedicated) & COBO (Fully Managed)

🔴 BREAKING CHANGE: MHS Lock Task Mode Password migriert

Achtung – das ist eine echte Breaking Change:

Früher konntest du das **Lock Task Mode Password** für MHS über **App Configuration Policy** setzen. Das funktioniert jetzt **nicht mehr**. Du musst auf **Device Configuration Profile** wechseln

Docs: Configure the Microsoft Managed Home Screen app for Android Enterprise (Microsoft Learn)

Block Bluetooth Sharing – Neue Android Settings Catalog Policy

Settings Catalog bekam ein neues Boolean-Setting: Block Bluetooth Sharing

  • True: Device blockiert Bluetooth-Sharing
  • False: Keine Änderung (OS-Default bleibt)

OS-Defaults aktuell:
– COBO & COSU: Bluetooth Sharing erlaubt
– COPE: Bluetooth Sharing blockiert

Nutzen: Falls du eine konsistente Sharing-Policy across all AOSP-Devices brauchst.

Applies to: COPE, COBO, COSU

🔴 BREAKING CHANGE: Apple Intelligence Settings werden deprecated

Das ist der große Umbruch: Apple hat in iOS/iPadOS 26.4 viele Intelligence-Settings aus dem MDM Restrictions Payload entfernt. Microsoft folgt jetzt nach und depreciert diese Settings in Intune:

Betroffene Settings in Settings Catalog (Restrictions):
– Allow Apple Intelligence Report
– Allow Assistant (und alle Varianten)
– Allow Auto Correction
– Allow Continuous Path Keyboard
– Allow Definition Lookup
– Allow Dictation
– Allow External Intelligence Workspace IDs / Integrations
– Allow Genmoji
– Allow Image Playground / Image Wand
– Allow Mail Smart Replies / Mail Summary
– Allow Notes Transcription / Summary
– Allow Predictive Keyboard
– Allow Safari Summary
– Allow Spell Check
– Allow Visual Intelligence Summary
– Allow Writing Tools
– Alle Force Varianten

Betroffene Settings in Device Restrictions Template:
– Built-in apps: Siri (alle Varianten), User-Generated Content
– Keyboard & Dictionary: Word Definition, Predictive Keyboards, Auto-Correction, Spell Check, Keyboard Shortcuts, Dictation

Die neue Lösung: DDM Configurations (ab März 2026 released)

Applies to: iOS/iPadOS, macOS

App Silencing in Managed Home Screen (MHS)

Neue Security-Feature für Kiosk-Umgebungen: Wenn MHS den User zur Authentication auffordert (Sign-in, Session PIN), können Apps jetzt silenced werden. Das heißt:

  • Keine Activity Starts
  • Keine Notifications
  • Nicht in Recent Apps sichtbar
  • Keine Toasts, Dialogs oder Device Ringing

Mit Allowlist: Kritische Apps (z.B. Phone/Calls) können du in der Allowlist behalten, damit Telefonate nicht unterbrochen werden.

Szenario: Checkout-Geräte in Supermärkten – während der PIN-Authentifizierung kann Werbung/Notifications nicht ablenken. Nach Unlock: Normal.

Applies to: Android Enterprise (alle Varianten)

Microsoft Edge 148 Settings im Windows Settings Catalog

Zwei neue NTP (New Tab Page) Policies für Edge 148:

1. ConfigureNTPFeedTabVisibility
– EnableBothWorkDiscover (Default): Beide Tabs sichtbar
– EnableOnlyWork: Nur Work Feed
– EnableOnlyDiscover: Nur Discover Feed

2. Default NTP Feed Tab
– Work (Default)
– Discover

Nutzen: Für Enterprises, die ihren Mitarbeitern nur unternehmensrelevante Inhalte auf der Edge New Tab Page zeigen wollen.

Applies to: Windows 10 and later

Handlungsbedarfe

🔴 KRITISCH – Apple Intelligence Migration (iOS/iPadOS, macOS)

  • Timeline: Beginn jetzt, Abschluss bis Ende Q3 2026
  • Action: Migrate alte Intelligence-Restrictions zu DDM Configs
  • Fallback: Alte Policies funktionieren noch, aber sind deprecated
  • Docs: Apple DDM Framework (Microsoft Learn)

🔴 WICHTIG – MHS Lock Task Password (Android Enterprise)

  • Timeline: Nächste Wartungsfenster
  • Action: App Config Policies → Device Configuration Profiles
  • Überwachung: Legacy Policies weiterhin testen, parallele Migration empfohlen
  • Docs: Configure Microsoft Managed Home Screen

🟡 MITTELHOCH – Multiple Managed Accounts (iOS/iPadOS)

  • Timeline: Jetzt QA-testen, später rollout
  • Action: Teams v8.10.0+ in Pilot-Group testen
  • Testing: Wie funktionieren Custom App Protection Policies mit Multi-Account?
  • Scope: Android-Support kommt später – nicht sofort erwarten

🟡 OPTIONAL – Custom MHS Top Bar & App Silencing

  • Timeline: Nächster Kiosk-Deployment
  • Action: ROI-Check für deine Kiosk-Szenarien
  • Use Cases: Checkout, Konferenzraum-Displays, Public Kioske

Fazit

Release 2605 ist ein Mixed Bag:

✅ Das Gute:
– Multiple Managed Accounts endlich für Teams = echte Productivity-Gewinne
– MHS-Features (Custom Top Bar, App Silencing) machen Kiosk-Deployment smarter
– Edge & Bluetooth Settings geben mehr Granularität

⚠️ Das Kritische:
– Apple Intelligence Deprecation ist ein echtes Project – du musst zu DDM migrieren
– MHS Lock Task Password erfordert Policy-Rewrite – das ist Arbeit
– Gradueller Rollout bedeutet: Nicht alle Features sind sofort da

Quellen

iOS 27 und Workspace ONE: DDM-Migration – Der Schrittplan für deutsche Admins

10. Juni 2026 / / Keine Kommentare

iOS 27 und Workspace ONE: DDM-Migration – Der Schrittplan für deutsche Admins

Apple hat auf der WWDC 2026 den Startschuss gegeben – iOS 27 kommt im September. Für dich als Admin bedeutet das: Legacy MDM ist offiziell Geschichte. Hier bekommst du alles, was du wirklich wissen musst.

💡 Das Wichtigste in 30 Sekunden
iOS 27 erscheint September 2026 – Legacy MDM Update-Commands funktionieren danach NICHT mehr.
DDM (Declarative Device Management) ist ab iOS 27 Pflicht für Software-Update-Enforcement.
Workspace ONE UEM 2406+ unterstützt DDM für iOS – du brauchst mindestens diese Version.
Bestehende Profile und Policies bleiben unberührt – nur Update-Management muss migriert werden.
Die Siri AI kommt in der EU NICHT auf iOS 27 (Digital Markets Act) – vorerst nur auf macOS 27.

Was Apple auf der WWDC 2026 angekündigt hat

A m 8. Juni 2026, hat Apple auf der Worldwide Developers Conference in Apple Park iOS 27 offiziell vorgestellt. Der Fokus lag klar auf KI – konkret auf einem von Googles Gemini-Modell betriebenen Siri. Aber für uns Admins ist etwas anderes der eigentliche Knackpunkt:

  • iOS 27 unterstützt alle Geräte, die aktuell iOS 26 laufen – auch das iPhone 11 und neuere.
  • Apple Intelligence läuft nur auf iPhone 15 Pro, iPhone 16 und iPads/Macs mit M1 oder neuer.
  • Legacy MDM Update-Commands (ScheduleOSUpdate, OSUpdateStatus) werden mit iOS 27 komplett ignoriert.
  • DDM ist ab sofort Standard – nicht optional, nicht „demnächst“, sondern jetzt.
⚠️ Wichtig für die EU / Deutschland
Siri AI wird auf iOS 27 und iPadOS 27 in der EU NICHT verfügbar sein.
Apple begründet das mit dem Digital Markets Act (DMA).
Auf macOS 27, watchOS 27 und visionOS 27 ist Siri AI hingegen auch in der EU verfügbar.
Für Unternehmensumgebungen in Deutschland bleibt der operative Betrieb unverändert.

DDM vs. Legacy MDM – Was hat sich eigentlich geändert?

Der Unterschied zwischen Legacy MDM und DDM ist kein Buzzword – er ist architektonisch. Kurz gesagt:

Merkmal Legacy MDM (alt) DDM – Declarative Device Management (neu)
Steuerung Server schickt Befehle, Gerät führt aus Server definiert Zielzustand, Gerät kommt selbst dahin
Software Updates ScheduleOSUpdate-Command Software Update Enforcement Declaration
Check-in Abhängigkeit Ja – Command-Delivery muss klappen Nein – Gerät arbeitet eigenständig
Fehlertoleranz Gering (kein Check-in = kein Update) Hoch (Gerät retried eigenständig)
Statusreporting Nur nach Command-Ausführung Kontinuierlich via Status-Channel
iOS 27 kompatibel? NEIN – Commands werden ignoriert JA – vollständig unterstützt
Nutzer-Benachrichtigung Einmalig Mehrfach, Wochen im Voraus
ℹ️ Wie DDM intern funktioniert
Beim alten MDM: Workspace ONE schickt „Update jetzt!“ – und wartet.
Bei DDM: Workspace ONE erklärt den gewünschten Zustand (z.B. „iOS 27.0 bis 15.09.2026“).
Das Gerät übernimmt die Verantwortung, diesen Zustand zu erreichen.
Kein Check-in? Kein Problem – beim nächsten Kontakt macht das Gerät weiter.
Schlechte Verbindung? Das Gerät retried ohne serverseitigen Eingriff.

Workspace ONE UEM und DDM – Was du jetzt brauchst

Die gute Nachricht: Omnissa hat seine Hausaufgaben gemacht. DDM ist kein Zukunftsprojekt mehr – es ist fertig. Hier der aktuelle Stand:

WS1 UEM Version DDM Support Details
2406 (August 2024) iOS / iPadOS GA-Release: Software Update Enforcement, DDM Declarations, Status-Channel
2410 (Oktober 2024) macOS DDM für macOS hinzugekommen
2406+ (SaaS) Vollständig Beide Typen: Imperative und Declarative Profiles parallel möglich

Für On-Premises Kunden: Wenn ihr noch auf WS1 UEM 2306 oder älter seid, müsst ihr bis September 2026 auf mindestens 2406 upgraden – sonst habt ihr nach dem iOS 27 Rollout keine Kontrolle mehr über Software Updates auf iOS-Geräten.

⚠️ On-Premises Admins: Handlungsbedarf jetzt
WS1 UEM 2306 und älter: Kein DDM-Support.
Legacy Update-Commands funktionieren nach iOS 27 Release nicht mehr.
Upgrade auf mindestens WS1 UEM 2406 ist Pflicht vor September 2026.
SaaS-Kunden sind automatisch auf dem aktuellen Stand – kein Handlungsbedarf.

Schrittplan: Migration auf DDM in Workspace ONE

Hier ist der praxiserprobte Schrittplan – inklusive Timeline für September 2026:

Schritt 1: WS1 UEM Version prüfen (Sofort)

Prüfe deine aktuelle WS1 UEM Version unter System > General > Product Information.

  • SaaS: Ihr seid automatisch aktuell.
  • On-Premises: Ihr braucht mindestens Version 2406.
  • Ist deine Version älter als 2406, startet den Upgrade-Prozess asap. Bei Fragen, wende dich an deinen Dienstleister des Vertrauens.

Schritt 2: Bestehende iOS Update Policies inventarisieren (Woche 1–2)

Dokumentiert alle vorhandenen Legacy-Update-Policies unter Devices > Apple Updates > iOS/iPadOS Update Policies.

  • Welche Smart Groups sind zugewiesen?
  • Welche Versionen werden enforced?
  • Welche Deferred-Zeiten sind konfiguriert?
ℹ️ Koexistenz möglich
DDM und Legacy MDM können parallel auf denselben Geräten laufen.
Du musst nicht alles auf einmal migrieren.
Sobald eine DDM Software Update Enforcement Declaration aktiv ist, wird sie priorisiert.
Legacy Update Commands werden dann ignoriert – auch wenn sie noch konfiguriert sind.

Schritt 3: Erstes DDM Profil erstellen – Testumgebung (Woche 2–3)

In der Workspace ONE Console navigierst du zu Resources > Profiles > Add Profile > iOS. Jetzt siehst du eine neue Option:

2. Platform: iOS
3. Management Type: Declarative <– neu seit WS1 2406
4. Declaration Type: Configuration

Schritt 4: Testen und Validieren (Woche 3–4)

Beobachte den Status-Channel in WS1 – das ist das neue Herzstück von DDM:

  • Devices > Device Details > [Gerät] > DDM Status
  • Prüfe, ob die Declaration korrekt zugewiesen wurde.
  • Nutzer bekommen jetzt automatisch Benachrichtigungen auf dem Gerät.
  • Validiere das Update nach Enforcement-Datum.

Schritt 5: Rollout auf Produktion (August 2026 – vor iOS 27)

Sobald der Test stabil läuft, rollt ihr die DDM Declarations auf alle iOS-Geräte aus. Folgende Empfehlung für Timing:

Phase Zeitraum Aktion
Vorbereitung Juni 2026 WS1 Version prüfen, Inventarisierung, Test-Declarations erstellen
Pilot Juli 2026 DDM auf 10–20% der Geräte (IT-Team, Power User)
Rollout Welle 1 August 2026 DDM auf 50% der Geräte, Legacy Policies parallel aktiv lassen
Vollständig Vor September 2026 DDM auf 100% der Geräte aktiv
iOS 27 Release September 2026 iOS 27 erscheint – nur DDM Devices bekommen kontrollierten Update-Rollout
Legacy Cleanup Oktober 2026 Alte Legacy Update Policies aus WS1 entfernen

Achtung: TLS-Verschärfung in iOS 27

iOS 27 und macOS 27 erzwingen strengere TLS-Anforderungen für Systemprozesse. Das ist ein separates Thema, aber ein kritisches – insbesondere für On-Premises WS1-Umgebungen mit eigenen PKI-Infrastrukturen:

⚠️ TLS-Kompatibilität prüfen
iOS 27 erzwingt via neuen ProfileAssetReference-Key strengere TLS-Anforderungen.
Betroffen sind Systemprozesse, die HTTPS-Verbindungen zu internen Servern aufbauen.
Prüft eure internen CA-Zertifikate auf SHA-256 Signatur und ausreichende Key-Länge.
Besonders kritisch: On-Premises WS1 mit eigener PKI (z.B. D-Trust, Microsoft CA).
Test-Enrollment mit iOS 27 Developer Beta empfohlen, sobald verfügbar.

Best Practices für deutsche Admins

  1. Migrationszeitpunkt: Nicht bis September warten. Jetzt anfangen.
  2. Test-Gruppe aufbauen: 3–5 Geräte, mindestens iOS 16+, verschiedene Modelle.
  3. Legacy Policies nicht sofort löschen: Koexistenz nutzen, erst nach validiertem DDM-Rollout aufräumen.
  4. Status-Channel auswerten: Das ist euer neues Dashboard für Update-Compliance.
  5. Nutzer-Kommunikation planen: DDM schickt automatisch Benachrichtigungen – stimmt das Timing mit eurer IT-Policy ab.
  6. On-Prem: Seed-Script für neue iOS-Versionen von Omnissa Connect herunterladen (beta-Unterstützung).
  7. TLS-Audit jetzt: Interne CA-Zertifikate auf iOS 27 Kompatibilität prüfen.

Häufige Fehler – und wie ihr sie vermeidet

Fehler Auswirkung Lösung
WS1 Version < 2406 Kein DDM möglich Upgrade auf 2406 oder neuer vor September
Legacy + DDM ohne Priorität beachten Unerwartetes Verhalten DDM Override verstehen: DDM Declaration gewinnt immer
Enforcement Date zu früh gesetzt Nutzer werden überrascht Mindestens 2 Wochen Vorlauf einplanen
TLS-Zertifikate nicht geprüft Enrollment-Fehler nach iOS 27 Upgrade CA-Zertifikate vor Release prüfen
iOS 27 Beta ignoriert Keine Vorwarnung bei Problemen Jetzt Developer Beta testen

Und zur guter letzt nochmal der Hinweis. WS1 On-Prem ist zum 30.04.2027 abgekündigt und EOL! Hier wird Omnissa keine Grace-Periode geben. Somit ist hier Handlungsbedarf, da ich Migration in die SaaS mehrere Wochen benötigt.

BlackBerry UEM Release 12.23 … just a little Watch Back

11. Mai 2026 / / Keine Kommentare

BlackBerry UEM 12.23: Das November-Update im Reality-Check, just a little Watch Back

Heute mal ein kleiner Watch back und ich schaue mir das 12.23 release von BB und Ihrem UEM an. Ich hatte ja in meiner Zeit beim Land, mehr als genug mit BB zutun. Dann kam der wechsel und die letzten 7,5 Jahren, waren mehr WS1 und nachher Intune im UEM & MDM Feld im Fokus. Nun ist es aber auch mal wieder Zeit, sich dem alten Herren in Schwarz zu widmen und auch diesen zu beleuchten.

Es ist November 2026 und UEM 12.23 ist da – und ehrlich gesagt: Das ist kein Release, das große Headlines verdient. Das ist ein solides, pragmatisches Update, das zeigt, wohin BlackBerry UEM wirklich unterwegs ist. Kein Marketing-Blabla, keine zehn neuen Features, die niemand braucht. Stattdessen: Stabilität, Sicherheit, Zertifizierungen.

Wenn eine neue Version im November kommt und die Release Notes nicht vor Features überlaufen, ist das erfrischend ehrlich. BlackBerry hat verstanden: In einem etablierten UEM-System geht es nicht um Raketenfunktionen, sondern um Zuverlässigkeit.

Das Wichtigste in einer Tabelle

Feature / Bereich 12.23 Relevanz Status
Upgrade-Pfade von 12.21, 12.22 Standard ✓ Supported
iOS/iPadOS Tag-Null Support für aktuelle OS Enterprise-Muss ✓ Ready
Android Android Enterprise, Management API Standard ✓ Stabil
Windows 10/11 MDM-Management Enterprise-Standard ✓ Unterstützt
macOS Vollständige Unterstützung BYOD/Enterprise ✓ Stabil
Automatische Backups Setup-Tool integration Betrieb-Critical ✓ Automatisch
Gatekeeping Microsoft 365 Modern Auth Email-Management ✓ Optimiert
BlackBerry Connectivity Node Optional für große Umgebungen Skalierung ✓ Verfügbar

Was sich in 12.23 konkret ändert

Installation und Upgrade

Die Setup-Anwendung erlaubt Installation von UEM 12.23 oder Upgrade von UEM 12.21 oder 12.22. Das ist sauber: Sie sind nicht auf eine Version beschränkt, können aber überspringen sollten Sie noch auf 12.20 sein (das ist dann ein etwas aufwändigeres Upgrade, das ich separat planen würde).

⚠️ Breaking Change Watch: Wenn der Setup-Tool lädt, stoppt und startet er alle UEM-Services automatisch. Das ist normal – aber planen Sie Wartungsfenster. In Produktionsumgebungen machen Sie das am Wochenende oder nachts. Die Datenbank wird automatisch gebackt, aber trotzdem: Backups vor dem Upgrade, auch wenn die Software das macht.

Database-Anforderungen verschärfen sich

BlackBerry UEM Core Server müssen weniger als 5ms Latenz zur Datenbank haben. Das ist nicht neu, aber wird strikte überprüft. Wenn Sie eine Standard-SQL-Server-Installation mit Fernanbindung haben und die Latenz borderline ist – jetzt wird das zum echten Problem. Optimieren Sie vorher.

Sicherheit: JRE 17 ist Pflicht

JRE 17 muss auf dem Computer installiert sein, der UEM hostet. Das ist eine harte Anforderung. Wenn Sie noch auf JRE 11 rumfahren: Das endet jetzt. JRE 17 ist seit November 2023 LTS, also aktuell und stabil.

Plattform-spezifische Neuerungen

iOS & iPadOS

BlackBerry UEM ist eine Multi-Platform-EMM-Lösung, die umfassendes Device-, App- und Content-Management mit integrierter Sicherheit für iOS, macOS, Android und Windows 10 Geräte bereitstellt.

Für iOS-Admin bedeutet 12.23:
– Tag-Null-Kompatibilität mit den neuesten iOS-Versionen (der Standard in jedem BlackBerry-Release)
– Verwaltung von Zertifikaten für Devices und Apps mittels UEM-Profilen und Setup von Work Connections.
– VPN-Profile und PKI sind weiterhin der Standard

Praxis-Tipp: Wer noch auf ältere iOS-Versionen verteilt ist – plant jetzt das Upgrade auf 12.23, damit bei iOS 19 keine Überraschungen kommen.

Android

Keine großen Explosionen hier. OEMConfig-Apps erlauben Administratoren, Device-spezifische Funktionen über App-Konfigurationen zu verwalten, wie für Samsung Knox und andere Hersteller.

Die wichtigsten Unterstützungen:
– Android Enterprise – Standard und stabil
– Android Management API (AMAPI) – für modernere Gerätekontrolle
– Samsung Knox – weiterhin vollständig

Was sich nicht ändert: Das Android-Management in BlackBerry UEM ist pragmatisch, nicht flashy. Policies, Compliance, App-Verwaltung – all bewährte Features.

Windows 10/11

Windows 10 Devices werden als Teil des umfassenden Device-Management unterstützt. Windows 11 auch – obwohl die Docs noch „Windows 10“ sagen, ist das eine dokumentations-Verzögerung.

Für Enterprise-Umgebungen, die Intune für Windows nutzen: BlackBerry UEM can Co-Exist, ist aber eher für spezialisierte Szenarien (alte Geräte, Hybrid-Umgebungen, sehr restrictive Sicherheitsrichtlinien).

Sicherheit und Zertifizierungen – Das Eigentliche Update

Das große News für 12.23 ist nicht in den technischen Features, sondern in der Compliance-Welt: BlackBerry UEM ist das erste UEM-Produkt, das BSI-Zertifizierung erreicht hat und wurde gegen die Common Criteria Standards auf den höchsten Levels validiert.

Was bedeutet das praktisch?

  • Deutsche Regierungsbehörden müssen jetzt nicht mehr auf Ausnahmegenehmigungen kämpfen
  • NATO-Länder, Skandinavien, Frankreich sehen das als Vertrauenszeichen
  • Kritische Infrastruktur (Energie, Telekommunikation, Gesundheit) bekommt ein zusätzliches Zertifikat

Für normale Enterprise-Kunden ist das eher ein Verkaufs-Feature („Ja, sogar die deutsche Bundesregierung vertraut uns“). Aber für hochregulierten Umgebungen: Das ist jetzt ein Kaufargument.

Gatekeeper und Microsoft 365 Authentication

Für Modern Authentication mit Microsoft 365 muss man ein Entra-App hinzufügen und dessen Details bereitstellen – man muss nicht die Anmeldedaten eines M365-Admin-Kontos angeben, sondern nur das Entra Application ID und Organization Values.

Das ist ein echter Fortschritt für größere Orgs:
– Weniger Admin-Accounts mit Super-Privilegien
– OAuth-basiert, nicht mehr nur Legacy-Auth
– Microsoft-Integration wird moderner

Handlungsbedarf: Das musst du vor dem Upgrade wissen

1. Datenbank-Latenz überprüfen – JETZT

Nicht erst im Upgrade. Führe einen Test durch:

ping <deine-db-server>

Wenn die Latenz über 10ms ist, hast du ein Problem. Unter 5ms: Alles gut.

2. JRE 17 im Voraus installieren

Nicht während des Upgrades. Installiere JRE 17 auf dem UEM-Server, teste es, dann erst das Upgrade.

3. Backups – und zwar echte Backups

Die Software macht das automatisch, aber:
– Externe Backups VOR dem Upgrade
– Oder: Snapshot der ganzen VM vor dem Upgrade
– Test-Restore auf einer Testumgebung, falls möglich

4. Notification der Nutzer

Das Upgrade stoppt Services. Mach es nachts oder am Wochenende. User sollten das nicht während der Arbeit erleben.

5. Critical Issue Advisories lesen

Die dokumentierten Critical Issue Advisory Knowledge Base Articles für UEM und Enterprise Mobility Server sollten vor dem Upgrade gelesen werden. BlackBerry publiziert dort wichtige Gotchas.

Marktkontext: Wohin geht BlackBerry UEM?

Seien wir ehrlich: BlackBerry UEM ist eine Nischen-Lösung. Das ist nicht negativ gemeint – es ist realistisch.

  • Große Konzerne mit Sicherheits-Paranoia? → BlackBerry UEM
  • Regierungen, Militär, kritische Infrastruktur? → BlackBerry UEM
  • Mittelständler mit Standard-Anforderungen? → Intune, Jamf, MobileIron

Das Release 12.23 zeigt das deutlich: Keine Konsumenten-Features, keine Mobile-First-Optik. Sondern:
– Stabilität
– Compliance
– Enterprise-Hardening

Die BSI-Zertifizierung ist nicht zufällig: Sie zeigt, dass BlackBerry sich bewusst positioniert – nicht „für jeden“, sondern „für die, die Security ernst nehmen“.

Fazit: Solltest du upgraden?

Ja, aber:

  1. Wenn du aktuell auf 12.21 oder 12.22 bist → Im nächsten Wartungsfenster. Das ist ein normales Stabilitäts-Update.
  2. Wenn du auf 12.20 oder älter bist → Plane einen größeren Upgrade-Prozess. Das ist ein Multi-Version-Jump.
  3. Wenn du von anderer Lösung kommst → 12.23 ist aktuell und stabil. Guter Zeitpunkt für einen New Deployment.
  4. Wenn du in stark regulierter Branche bist → Die BSI-Zertifizierung könnte Compliance-Anforderungen erfüllen, die bisher ein Problem waren.

Was ich nicht empfehle: Hektik. Dieses Release ist nicht „müssen sofort upgraden“. Es ist ein „plane in den nächsten 2-3 Monaten und mach es dann“.

Die Technologie ist reif, die Anforderungen sind klar, die Migration ist standardisiert. Das ist das Gegenteil von hastig.

Die letzte Realität

Nach 16+ Jahren in MDM-Land sag ich dir eins: Die besten Enterprise-Updates sind die, die man kaum merkt. Man startet die Systeme neu, alles läuft wie vorher, die Devices synchronisieren sich, Policies pushen, Compliance wird überwacht.

Das ist 12.23. Genau das.

Ressourcen & Dokumentation

Omnissa Workspace ONE UEM Release 2604

10. Mai 2026 / / Keine Kommentare

Hey Leute,

ich hatte es ja versprochen und nun kommt mein Artikel zum neuen 2604. Geile release Nummer by the Way (kleiner Insider 🤩). Das 2604 Release ist einer der expansivsten der letzten Zeit und baut auf dem Momentum der 2602 auf . Und ehrlich? Das ist die Release, auf die viele von euch gewartet haben. Windows Server endlich im UEM-Universum, macOS-Admins können die Verpackungsorgie lassen, und mit Vulnerability Defense gibt’s jetzt auch nen CrowdStrike-Integration (mir stellen sich die Nackenhaare auf 🤯🤓, aber das ist eher ein persönliches Problem mit CrowdStrike wieder so ein Insider), die tatsächlich Sinn macht.

Ich bin mir aber auch bewusst: Das ist eine Broadcom/KKR-Omnissa, die hier liefert. Die Richtung stimmt, die Features sind solid – aber wir beobachten weiterhin kritisch, wie stabil das bleibt und ob OEMConfig, Rugged und DEX im Fokus bleiben.

Lass mich ein paar Stunden recherchiert haben und dann durch die Features nehmen.

Übersichtstabelle: Features nach Kategorie

Feature Plattform Kategorie Status
Windows Server Management (Enroll 2016+) Windows Server Infrastructure GA
Granular Patch Management Windows Server OS Management GA
Vulnerability Defense (CrowdStrike Integration) Windows Security Limited Availability
Enterprise App Repository (macOS) macOS App Management GA
Platform SSO in Setup Assistant (ADE) macOS, iOS Enrollment Limited Availability
App Preservation during MDM Migration iOS/iPadOS 26+ App Lifecycle GA
Redesigned UEM Console All UI/UX GA
Phased Deployments (Percentage-based) All Deployment GA
Ansible in Custom Config Profiles Linux Configuration GA
Device Update Profile (SUSE Linux) Linux (openSUSE, SLED, SLES) OS Updates GA
Platform-specific ADE Default Profiles iOS, macOS Enrollment GA
Application Removal Protection Improvements iOS App Security GA

Die Top Features im Detail

🖥️ Windows Server Management – Jetzt generell verfügbar (GA)

Das ist die Headline: Windows Server Management ist nun generell verfügbar in Workspace ONE UEM und bringt Server-Infrastruktur in die gleiche Management-Ebene wie der Rest der Endpoint-Flotte .

Konkret:

  • Enroll Windows Server 2016 oder später via Intelligent Hub, und sie tauchen neben deinen Desktops auf mit Server-spezifischen Details wie installierten Rollen und Features
  • Du kannst die Tools nutzen, die du schon kennst: ADMX-Profile mit vorgeladenen Templates, Baselines für automatische Config-Refresh, granulare OS-Patching mit Scheduling, vollständiges App-Lifecycle-Management via Enterprise Application Repository, und Freestyle Orchestrator für Automation
  • Remote Support funktioniert auch: Screen Share, File Access, Command Line – genauso wie bei Desktops

Das ist clever gedacht von Omnissa. Jahrelang haben Server-Teams separate Tools gebraucht. Jetzt ist die Frage: Wie tief geht das? Die ADMX-Integration und das Patching-Handling hören sich solide an. Aber ich warte auf Real-World-Reports zu Skalierungsfragen – einen 5.000er Server-Fleet mit WS1 zu patchen ist nochmal ne andere Hausnummer als Desktops.

Granular Patch Management: Du kannst spezifische Updates aus dem Windows Update Catalog suchen und selektieren, sie auf definierte Server-Gruppen zielen und die Deployment innerhalb deinem Timeframe planen. Du kannst sogar Updates vorab herunterladen, damit die Installation sofort startet, wenn die Zeit kommt .

🔒 Vulnerability Defense + CrowdStrike Falcon – Limited Availability

Workspace ONE Vulnerability Defense tritt in Limited Availability ein und bringt einen kompletten Assessment-to-Remediation-Workflow direkt in die Omnissa Platform für Windows Endpoints. Die Lösung integriert WS1 UEM mit CrowdStrike Falcon Exposure Management, um die Lücke zwischen Vulnerability Management, Exposure Discovery und Remediation zu schließen .

Der Workflow:

  • Wenn ne CVE oder High-Risk-Bedingung identifiziert wird, mapped WS1 UEM das automatisch zu betroffenen Endpoints für schnelle Risk-based Priorisierung
  • Empfohlene Remediation Paths werden direkt in der Admin-Console angezeigt, zusammen mit vorkonfigurierten Updates aus dem Enterprise App Repository. Patches und App-Updates werden über UEM ausgeliefert und IT-Teams können den Remediation-Progress monitoren

Die Integration mit CrowdStrike ist clever – Falcon hat etablierte Visibility, und jetzt hast du direkt im UEM-Portal die Remediation-Automation. Das reduziert Ticket-Ping-Pongs massiv. Aber: Limited Availability heißt, das ist noch nicht für alle da. Warte auf GA, bevor du architektural darauf planst. Und der CrowdStrike-Lizenz-Stack ist nicht zu unterschätzen.

🍎 Enterprise App Repository (macOS) – Jetzt GA

Das war lange überfällig. Workspace ONE UEM launcht die Enterprise App Repository (EAR) für macOS – ein kuratierter Katalog von beliebten Applikationen, der Deployment und laufende Verwaltung streamlined .

Praktisch:

  • Admins können Apps aus dem Repository direkt in der UEM-Console selektieren und sofort in Device-Gruppen deployen – kein manuelles Packaging nötig
  • Updates werden automatisch gehandhabt, und Notifications halten Admins informiert, wenn neue Appversionen verfügbar sind
  • Das App-Repository integriert nativ mit bestehenden UEM Assignment Workflows – Deployment passiert wie mit jeder anderen verwalteten App

Endlich. macOS-Admins hatten bisher ne Lücke: Android und iOS haben ihre App-Kataloge, aber macOS-Packaging war immer ne Sandbox, wo man sich selbst überlassen war. Mit der EAR kriegt ihr da Consistency. Die Frage ist: Wie groß ist der Katalog wirklich? Und können Custom Apps dazukommen? Aber für die Top-Use-Cases (Office, Teams, Browser, Dev-Tools) ist das jetzt ein echter Gewinn.

🔐 Platform SSO beim Setup Assistant (ADE) – Limited Availability

Platform SSO kann jetzt direkt im Setup Assistant während Automated Device Enrollment (ADE) konfiguriert werden. Wenn ein Device ADE durchläuft, authentifizieren sich User mit ihrem Org-Identity-Provider und erstellen ihren ersten Local Account – alles während Initial Setup, bevor das Device übergeben wird. Keine zusätzlichen Schritte, kein separater Profile Push .

Das Resultat ist eine cleanere Onboarding-Experience und eine stärkere Security-Baseline von Tag 1 .

Das ist die richtige Richtung. Zero-Touch Enrollment mit PSSO on Day 0 – das war der USP von großen Apple-Lösungen, und jetzt kann WS1 das auch. Noch im Limited Availability Status, aber sobald das GA ist, sollte das zum Standard gehören für neue Mac-Enrollments.

📱 App Preservation during MDM Migration (iOS 26+)

Workspace ONE UEM führt granulare App Preservation während MDM Migration für iOS/iPadOS 26+ Devices ein .

Das Szenario: Du migrierst eine Flotte von nem anderen MDM zu WS1? Früher wurden die Apps gelöscht und neuinstalliert – Friction für User, Komplexität für IT. Jetzt können Apps erhalten bleiben.

Praktisch für größere Migrations-Szenarien. Aber iOS 26+ ist ne spezifische Anforderung – für ältere Devices musst du weiterhin mit App-Reinstall rechnen.

🖼️ Redesigned UEM Console – Now GA

Die neu designte WS1 UEM Admin-Console ist jetzt generell verfügbar. Sie ist auf einem modernisiertem Tech-Stack gebaut, geprägt von iterativem User Research und Testing. Die neue Experience reorganisiert Navigation in logischere Kategorien, stellt die meistgenutzten Features in den Vordergrund, und ersetzt Labels, die Institutional Knowledge brauchten, durch Sprache, die sofort klar ist .

UI-Überarbeitungen sind immer zweischneidig. Manche Admins haben Jahrzehnte in der alten Console gelebt. Aber wenn das Research-driven ist und auf Usability-Testing basiert, sollte das okay sein. Wird schnell klar, ob das wirklich besser ist oder nur anders. Ich bin gespannt drauf.

📊 Phased Deployments mit Percentage-based Rollout – GA

Phased Deployments sind jetzt GA, und diese Release fügt ne neue Capability hinzu: Admins können jede Phase jetzt nach Prozentanteil der Zielgruppe definieren, statt Gruppen explizit zu spezifizieren .

Praktisch: „Rollout an 10% → 25% → 50% → 100%“ ohne dass du Gruppen manuell aufteilen musst.

Das ist ein DLP-Playing-Field. Apple hat das via MDM-Restrictions seit Jahren, Microsoft Intune auch. Jetzt kann WS1 auch prozentual rollout – das ist gut.

🐧 Ansible in Linux Custom Config Profiles + SUSE Update Management

Zwei Linux-Highlights:

  1. Ansible Support: Enterprise Linux Environments vertrauen oft auf Ansible für Configuration Management. In 2604 bringt WS1 UEM diese Capability direkt ins Custom Configuration Profile. Ansible ist jetzt neben Bash, Python und Puppet als unterstützter Payload-Type verfügbar. Admins können Ansible Playbooks nutzen, um enrolled Linux Devices zu konfigurieren, mit Support für Ansible Collections und Roles .
  2. Device Update Profile für SUSE: Das Device Update Profile erweitert sich auf SUSE-basierte Linux Devices (openSUSE, SLED, SLES). Admins können das Level und die Frequenz von automatischen Updates konfigurieren, Security- und Policy-spezifische Update Rules, und Notifications für neue Major OS Versions .

Das ist solider Enterprise-Linux-Support. Ansible ist das Orchestration-Tool, und wenn WS1 das nativ unterstützt, brauchst du weniger Custom Integrations. Für SUSE-Shops ist das dann ne große Erleichterung.

🔧 Platform-specific ADE Default Profiles (iOS & macOS)

Ein Clarity-Feature: Admins können jetzt platform-spezifische Default ADE Profiles assignen. iOS und macOS können unterschiedliche On-Boarding-Profile haben, ohne dass man überall Conditional Logic bauen muss.

⚠️ Handlungsbedarfe & Deprecations

Vulnerability Defense: Limited Availability Status

Vulnerability Defense ist noch nicht GA. Wenn du das architekturiert, solltest du mit dem Omnissa-Account-Team aligned sein. Das kann sich bis GA noch verschieben.

CrowdStrike-Lizenzierung

Wenn du Vulnerability Defense einführen willst, brauchst du nicht nur WS1 UEM, sondern auch CrowdStrike Falcon Exposure Management. Das ist ein separater Lizenzstack – kalkuliere das mit in deine TCO.

Windows Server 2016+ Requirement

Windows Server Management funktioniert nur ab 2016. Wenn du ältere Server-Flotten hast (2012 R2, 2008 R2), brauchst du weiterhin separate Tools.

iOS 26+ für App Preservation

App Preservation during Migration funktioniert nur auf iOS/iPadOS 26+. Ältere Devices haben weiterhin App-Wipe während Migration.

Vergleich zu Microsoft Intune: Wo WS1 Vorteile hat

Der 2604 Release ist eines der expansivsten in letzter Zeit und baut auf 2602-Momentum auf . Wenn du Intune mit WS1 vergleichst:

Feature Workspace ONE UEM 2604 Microsoft Intune
Windows Server Management ✅ Jetzt GA ❌ Nicht native
macOS Enterprise App Repository ✅ GA (curated) ⚠️ Basic app store integration
Rugged Device Support ✅ OEMConfig first ❌ Limited
Linux Management ✅ Ansible

Intune Release 2604 – Die wichtigsten Neuerungen (KW 27.04.2026)

4. Mai 2026 / / Keine Kommentare

Intune Release 2604 – Die wichtigsten Neuerungen (KW 27.04.2026)

🤔 Was mir an dieser Release auffällt

Ehrlich gesagt, die 2604er Release ist bemerkenswert solide. Keine großen Breaking Changes, aber dafür drei sehr sinnvolle Punkte, die ich täglich in Kundenprojekten höre:

  1. EPM endlich für alle User – bisher war das ein nerving restrictions für Shared Devices (Kiosk, Hotspot-Devices)
  2. Android 14: Credential Manager-Kontrolle – das schreit geradezu nach Zero-Trust-Architektur
  3. Vision Pro & Apple TV management – ok, nichts für den Massenmarkt, aber für Specialized Use Cases ein Game-Changer

Lass mich die Details durchkauen.

📊 Feature-Übersicht: Was sich ändert

Feature Plattform Kategorie Wichtigkeit
EPM: Support-approved Elevation für alle User Windows Security/Privilege Mgmt 🔴 High
Android 14: Credential Manager Permissions Android Enterprise Device Config 🔴 High
Location Services Settings Katalog (neu) Android Enterprise Device Config 🟡 Medium
Apple Access Management (ABM/ASM) iOS/macOS Enrollment/Access 🟡 Medium
visionOS & tvOS ADE Support visionOS/tvOS Enrollment 🟡 Medium
Ubuntu 26.04 LTS Support Linux Device Management 🟡 Medium
Neue Device Page (Public Preview) All UI/UX 🟢 Low (UX)
EPM: Suspend/Restore für Managed Hosting Windows Device Management 🟡 Medium

🔧 Die wichtigsten Features im Detail

1️⃣ Endpoint Privilege Management (EPM): Support-Approved Elevations für ALLE User

Vorher:
– Support-approved file elevation requests funktionieren nur für:
– Den Primary User des Devices
– Den User, der das Device enrolled hat
– Auf Shared Devices (Hotspot, Kiosk, Hoteling): komplettes Blockkade

Nachher (2604):
– Alle User auf einem Device können Support-Approved Elevation Requests stellen
– Der Support-Admin muss nicht mehr jonglieren, welcher User gerade logged ist

Szenarios wo das hilft:
– Shared Hotspot-Geräte in Logistik-Hubs
– Kiosk-Modus für Retail/Hospitality
– Hot-Desking in großen Büros

Was ich dir empfehle:

Intune Admin Center → Endpoint Privilege Management →
Policies → [Deine Policy] → Elevation Settings prüfen

Vorsicht: Das ist ein Feature von Intune Suite – nicht im Standard-Intune Plan 1 enthalten. Kosten-Impact checken!

2️⃣ Android 14+: Credential Manager Permissions – Das Security-Highlight

Das Problem:
– Android 14 blockt standardmäßig Third-Party Credential Provider auf Corporate Devices
– Passkey-Adoption scheitert, weil kein Custom Password Manager nutzbar ist
– Microsoft Authenticator kann nicht als Default-Provider fungieren

Die Lösung (2604):
Neue Config im Intune Admin Center:

Apps → Android → Configuration → Managed Devices
→ Android Enterprise → Credential Manager Permissions

Was du hier steuern kannst:
✅ Spezifische Apps als System-Credential-Provider zulassen
✅ Passkey-basierte Sign-in aktivieren
✅ Nur vertraute Credential Sources erlauben
❌ Google Password Manager bleibt blockiert (Known Limitation!)

Unterstützte Device Types:
– Android COBO (Fully Managed)
– Android COSU (Dedicated)
– Android COPE (Corporate-Owned Work Profile)
– Android BYOD mit Work Profile (AM API)

Meine Einschätzung:
Das ist Zero-Trust für Android. Du kannst jetzt explizit definieren: „Nur Microsoft Authenticator + 1Password dürfen Passkeys speichern.“ Game-changer für Finance/Legal-Geräte.

⚠️ Warnung: Google Password Manager funktioniert nicht – musst du in deinen Rollout-Docs erwähnen!

3️⃣ Android Enterprise: Location Settings – Mehr Granularität

Neu (war vorher Binary-Block):
Drei Optionen statt Ja/Nein:

Option Verhalten Use Case
Device default OS-Standard, User kann togglen Flexible Policies
Location enabled Erzwungen an, User kann nicht aus Fleet Tracking, Delivery
Location disabled Erzwungen aus, User kann nicht an High-Security Devices

Gilt für:
– Android 10 und älter (COPE, COBO, COSU)

Warum sag ich dir das?
Der alte „Block location“ Setting war ein Sledgehammer. Jetzt kannst du differenzieren: Fleet-Devices tracken, Admin-Devices privat halten.

4️⃣ Apple Access Management (neu) – For ABM/ASM Admins

Was ist neu:
– Direkt in Apple Business Manager / Apple School Manager konfigurierbar
– Du steuert jetzt aus ABM, welche Devices ein User nutzen darf
– Welche Apps & Services verfügbar sind (z.B. App Store blockieren?)

Gilt für:
– iOS/iPadOS
– macOS

Impact für Intune Admins:
Das ist eher ein Apple-seitiges Feature. Aber wenn dein ABM Admin das nutzt, synchronisiert es mit Intune. Wichtig: In deine ABM-Onboarding-Docs aufnehmen!

5️⃣ 🎯 visionOS & tvOS ADE Support – The Future is Here

Brechen wir’s runter:

Zum ersten Mal unterstützt Intune:
– Apple Vision Pro Management
– Apple TV Management
– Ohne User Affinity (userless ADE)

Technische Details:
– Über Apple Business Manager / Apple School Manager
– Intune Plan 2 erforderlich (Teil Microsoft 365 Suite)
– Voraussetzung: tvOS 26+ oder visionOS 26+
– Custom Configuration Uploads möglich
– Enrollment Restrictions & Device Actions funktionieren

Wo erscheinen diese Devices?

Intune Admin Center → Devices → All Devices →
Apple Mobile Devices (Filter: tvOS/visionOS)

Szenarios:
– 🏥 Krankenhaus: Vision Pro für Chirurgie-Planung + MDM-Lockdown
– 🏬 Retail: Apple TV in Stores mit gepinnten Apps
– 🎓 Education: VisionOS für AR-Learning, zentral verwaltet

⚠️ WICHTIG: Keep devices updated! tvOS/visionOS 26+ = Sicherheit. Das ist kein „kann“, das ist Pflicht für deine Governance.

6️⃣ Linux: Ubuntu 26.04 LTS Support + 22.04 EOL-Warnung

Timeline:

Version Status Maßnahme
Ubuntu 22.04 LTS EOL August 2026 ⚠️ Migration planen
Ubuntu 26.04 LTS Neu supported ✅ Rollout ready

Praktisch:
Devices auf 22.04 können enrolled bleiben, aber:
1. Du solltest Upgrade-Kampagne starten
2. Im Intune Admin Center kannst du identifizieren:

Devices → All Devices → Filter: Linux → Add Column: OS Version

7️⃣ New Device Page (Public Preview) – UI/UX Facelift

Das ist in Preview – noch nicht produktiv!

Enable:

Intune Admin Center → Devices → All Devices → Toggle: „Preview new device view“

Was ändert sich:
– Single unified view für Device-Info statt 5 verschiedene Tabs
– Neue Struktur:
– Device action status – Was läuft gerade?
– Tools and reports – Compliance, Config Status, Remediations
– Properties – Editable Device Infos
– Device details – Hardware & Entra-Infos

Wichtig:
– Nur bei Devices → All Devices aktiv
– Wenn du ein Device aus Report-View öffnest → alte UI
– Keine Funktionalitäts-Changes, rein UI

Meine Einschätzung:
Langfristig überraschend gut durchdacht. Aber warte bis GA, bevor du es im Training zeigst.

⚠️ HANDLUNGSBEDARF: Breaking Changes & Deprecations

🔴 CRITICAL: Google Password Manager blocked auf Android Work Profile

Was passiert:

Android COPE / BYOD Work Profile + Android 14
→ Google Password Manager funktioniert NICHT als Credential Provider

Dein Handeln:
1. Audit: Welche User nutzen Google Password Manager?
2. Communication: „Wir wechseln zu [Microsoft Authenticator / 1Password]“
3. Policy: Setze explizit authorized credential providers
4. Timeline: VOR Android 14 Roll-out implementieren!

🟠 WARNING: Ubuntu 22.04 LTS EOL August 2026

Was passiert:
Nach August 2026 keine Security Patches für 22.04

Dein Handeln:
1. Identifiziere alle Ubuntu 22.04 Devices (Filter in Intune)
2. Kommuniziere Migration zu 26.04 LTS
3. Teste 26.04 LTS in Pilot vor August 2026
4. Hardware-Check: Manche ältere Geräte unterstützen 26.04 nicht!

🟡 NOTICE: visionOS/tvOS 26+ Requirement

Was ist neu:
Apple Vision Pro & Apple TV management nur mit tvOS 26+ / visionOS 26+

Dein Handeln:
– Falls du Vision Pro pilotierst: Update-Strategie definieren
– Alte tvOS-Versionen bleiben „unmanaged“
– Monitoring: „Devices with unsupported OS version“ tracken

📚 Microsoft Learn Ressourcen

Alle offizielle Docs:

  1. EPM Support-Approved Elevations

  2. Android Credential Manager Config

  3. Android Settings Catalog

  4. Apple ADE Overview

  5. Linux Device Enrollment

  6. Ubuntu 26.04 Details

Wer MUSS upgraden:

✅ Android Enterprise Admins (Credential Manager Control ist ein Must-Have für Security)
✅ EPM-Nutzer auf Shared Devices (endlich nicht mehr Workarounds!)
✅ Apple-Shops mit tvOS/Vision Pro Piloten

Wer kann warten (bis GA):

⏳ Reine iOS/macOS Orgs (Features sind nett, nicht game-changing)
⏳ Linux-only Shops (Ubuntu 26.04 ist Standard, 22.04 EOL ist erst Aug 2026)
⏳ Wer Device Page neue UI noch nicht braucht (noch in Preview)

Meine persönliche Einschätzung:

Nach 16+ Jahren MDM: Diese Release ist stabil und pragmatisch. Keine Überraschungen, keine großen Deprecated Features, aber echte Mehrwerte bei Android Security + Credential Management.

Das Android Credential Manager Feature verdient eure volle Aufmerksamkeit. Das ist nicht nur ein „nice-to-have“ – das ist Zero-Trust für Mobile Devices.

Rollout-Plan:

Phase 1 (Juni 2026): Pilot mit Android Credential Manager (5% Devices)
Phase 2 (Juli 2026): EPM Policies für Shared Devices updaten
Phase 3 (Aug 2026): Ubuntu 22.04 → 26.04 Migration starten
Phase 4 (Sept 2026): visionOS/tvOS in Pilot (wenn relevant)
„`

🔗 Schnelle Links
Intune What’s New – Service Release 2604
Microsoft Intune Blog
Intune Roadmap
Endpoint Privilege Management Docs

XPenology Update: Von DSM 6.2.3 auf DSM 7.2.2 mit dem Arc Loader

20. April 2026 / / Keine Kommentare

XPenology Update: Von DSM 6.2.3 auf DSM 7.2.2 mit dem Arc Loader

Fünf Jahre alter NAS-Build, frisches DSM 7.2.2 – wie das auf eigener Hardware klappt und was der Arc Loader von AuxXxilium damit zu tun hat.

Hey Ho Folks,

heute gibt es mal etwas abseits von MDM und Intune – aber wer mich kennt, weiß: ich bin ein Spielkind. Und das Spielkind hatte jahrelang ein stabiles HP ProLiant MicroServer N54L zuhause laufen – mit XPenology DSM 6.2.3-25426 Update 3 aus dem Jahr 2020. Darauf laufen Docker Container, ein Medienserver, HomeBridge, Portainer, Pangolian Gateway und diverse andere Smarthome-Dienste.

Die Zeit war reif: raus aus 2020, rein ins Jahr 2025 – und das bedeutet DSM 7.2.2.

In diesem Post zeige ich euch Schritt für Schritt, wie das mit dem Arc Loader von AuxXxilium funktioniert – und ja, auch für Mac-User!

ℹ️ Was ist XPenology?

XPenology ist ein inoffizieller Bootloader, der es ermöglicht, Synology DSM auf eigener (x86) Hardware zu betreiben.

Man bekommt die gewohnte Synology-Oberfläche und alle DSM-Features – ohne an Synology-Hardware gebunden zu sein.

Mehr dazu: https://xpenology.net/en/introduction/

🔄 Warum überhaupt updaten?

DSM 6.2.3 ist seit 2020 eingefroren – es gibt zwar noch Security Patches, aber keine neuen Features mehr. DSM 7.x bringt hingegen vieles mit:

  • Deutlich verbessertes Container Manager Package (ehemals Docker)
  • Btrfs-Verbesserungen & stabilere Volume-Verwaltung
  • Neuere Synology-Pakete & aktive Weiterentwicklung
  • Bessere Performance auf moderner Hardware
  • Aktive Sicherheitsupdates & Support-Laufzeit

⚠️ Achtung: Kein offizieller Support!

XPenology ist ein Community-Projekt und kein offiziell von Synology unterstützter Weg.

Einsatz auf eigene Verantwortung – kein Produktiveinsatz ohne entsprechendes Bewusstsein für das Risiko.

Vor dem Update unbedingt ein vollständiges Backup aller Daten erstellen!

🛠️ Was du brauchst – Voraussetzungen

Was

Details

Hardware

HP ProLiant MicroServer N54L oder kompatibles x86-System

Bootfähiger USB-Stick

Mindestens 1 GB, alle Daten werden überschrieben

Arc Loader IMG

Download von auxxxilium.tech/redpill/

balenaEtcher (Mac)

Download von etcher.balena.io – GUI-Tool zum Flashen

Terminal (Mac-Alternative)

dd-Befehl – kein separates Tool nötig

Netzwerkzugang

Router-Zugang zum Ermitteln der NAS-IP-Adresse

Backup!

Unbedingt vor dem Update ein vollständiges Backup erstellen!

⚙️ Was ist der Arc Loader?

Der Arc Loader ist ein brillanter Fork auf XPenology-Basis, entwickelt von AuxXxilium Tech. Das Projekt ist Made in Germany 🇩🇪 – und was da an Arbeit drinsteckt, ist einfach beeindruckend. Der Loader erkennt automatisch die Hardware, bietet eine Browser-basierte Konfigurationsoberfläche und patcht das DSM-Image vollautomatisch.

ℹ️ Arc Loader Highlights

Browser-GUI über Port 7681 für einfache Konfiguration

Automatisches Hardware-Erkennen (NIC, HDD-Controller, etc.)

Model Selection Helper: findet kompatible Synology-Modelle für eure Hardware

Auto Mode: vollautomatisches Image-Patching ohne manuellen Eingriff

Unterstützt DSM 7.1 und DSM 7.2.x

📀 Schritt 1: Bootfähigen USB-Stick erstellen

Zuerst brauchen wir das Arc Loader IMG – Download unter: https://auxxxilium.tech/redpill/

Mac-Variante: balenaEtcher (empfohlen)

Für Mac-User ist balenaEtcher die einfachste Option. Download unter etcher.balena.io, DMG starten, IMG laden und auf den USB-Stick flashen. macOS fragt nach dem Passwort – das ist normal.

Mac-Variante: Terminal (dd)

Wer lieber ohne GUI arbeitet:

# 1. Image entpacken (falls .gz oder .zip)

gunzip arc-loader.img.gz

# 2. USB-Stick identifizieren

diskutil list

# 3. Stick aushängen (X = Disknummer, z.B. 2)

diskutil unmountDisk /dev/diskX

# 4. Image schreiben (rdiskX für schnellere Übertragung)

sudo dd if=arc-loader.img of=/dev/rdiskX bs=4m

sync

⚠️ Wichtiger Hinweis nach dem Flashen

macOS meldet nach dem Flashen, dass der USB-Stick nicht lesbar ist – das ist vollkommen normal!

Der Stick ist korrekt beschrieben und bootfähig. Die Meldung einfach wegklicken (nicht formatieren).

🌐 Schritt 2: Arc Loader konfigurieren

USB-Stick in den Zielserver einstecken und vom Stick booten. Danach Arc Loader im Browser aufrufen:

http://<IP-ADRESSE-DES-NAS>:7681

ℹ️ Tipp: IP-Adresse finden

Der Arc Loader bekommt beim ersten Start eine neue IP-Adresse per DHCP – diese ist NICHT identisch mit der bisherigen NAS-IP!

Einfach im Router-Dashboard nachschauen: welches Gerät hat sich zuletzt neu eingebucht?

Alternativ: nmap -sn 192.168.x.0/24 im Terminal – alle aktiven Hosts im Netzwerk auflisten.

Modell auswählen (CHOOSE MODEL)

Im Arc-Menü mit den Pfeiltasten navigieren und CHOOSE MODEL wählen. Welches Modell passt zur eigenen Hardware? Hier hilft der Model & Platform Selection Helper auf der Arc Wiki-Seite:

Wiki

Mein Setup: epyc7002 Plattform → Modell SA6400. Der Helper hat mir satte 26 kompatible Modelle gelistet – da lässt sich sicher für jeden etwas finden.

DSM Version wählen

Nach der Modellwahl folgt die DSM-Version. Hier eine Übersicht zum aktuellen Stand:

Version Status & Hinweis
DSM 6.2.3 Legacy – keine aktiven Updates mehr, nur noch Security Patches
DSM 7.1 Stabil, breite Hardware-Kompatibilität
DSM 7.2.2 ✅ Empfohlen – stabil, aktuelle Features, Arc Loader-Support
DSM 7.3 ⚠️ Noch nicht empfohlen – AuxXxilium gibt Version noch nicht frei (Bugs)

Auto Mode vs. Manual Mode

  • Auto Mode: Arc erkennt Hardware automatisch und baut das Image selbst. Empfohlen für die meisten Systeme.
  • Manual Mode: Volle Kontrolle über alle Parameter – nur für Fortgeschrittene mit spezieller Hardware.
💡 Empfehlung: Auto Mode

Für Standard-x86-Hardware wie den HP MicroServer N54L ist der Auto Mode absolut ausreichend und funktioniert zuverlässig.

Arc erkennt NIC, HDD-Controller und andere Komponenten automatisch korrekt.

🚀 Schritt 3: Image bauen und DSM installieren

Nach der Konfiguration startet Arc den Build-Prozess: Das DSM-Image wird heruntergeladen und automatisch gepatcht. Anschließend bootet das System neu.

⚠️ WICHTIG: Beim Boot-Screen warten!

Nach dem Neustart erscheint ein Boot-Screen mit einem Timer – NICHT Enter drücken!

Arc muss erst die NIC vollständig laden (passiert ganz am Ende des Bootprozesses).

Geduld: Das kann 2-3 Minuten dauern. Erst dann ist DSM über den Browser erreichbar.

Sobald der Arc Loader vollständig hochgefahren ist, DSM-Weboberfläche aufrufen:

http://<IP-ADRESSE-DES-NAS>:5000

Auf der Welcome-Seite startet die eigentliche DSM-Installation. Hier kurze Übersicht der Schritte:

  • DSM-Installationsassistent startet: Installieren auswaehlen
  • DSM 7.2.2 wird installiert – Dauer: ca. 5-10 Minuten
  • System startet automatisch neu
  • Bei bestehendem System: vorhandene Konfiguration auf den Daten-Volumes wird erkannt und kann übernommen werden
  • Nach finaler Initialisierung: Login mit bestehendem Benutzernamen möglich

ℹ️ Bestehende Daten & Konfiguration

Wer von DSM 6.x auf DSM 7.x upgraded und die gleichen Daten-Volumes beibehält, kann die vorhandene Konfiguration meist direkt übernehmen.

DSM erkennt die Volumes beim ersten Boot automatisch und bietet die Wiederherstellung der Einstellungen an.

Dennoch gilt: Backup vor dem Update ist Pflicht – verlasst euch nicht blind darauf!

🔧 Nach dem Update: Was jetzt?

DSM 7.2.2 läuft – aber nach einem Major-Upgrade von 6.x auf 7.x gibt es erfahrungsgemäß einige Punkte, die Aufmerksamkeit brauchen:

  • Pakete aktualisieren: Package Center öffnen und alle verfügbaren Updates einspielen
  • Überholte Pakete entfernen: Manche DSM-6.x-Pakete sind in DSM 7.x nicht mehr kompatibel
  • Container Manager prüfen: Docker-Container nach dem Upgrade auf Funktionstüchtigkeit prüfen
  • Medienserver (z.B. Plex, Emby): Hier haben sich unter DSM 7.x einige Dienste geändert – etwas Zeit einplanen
  • HomeBridge & Portainer: Bei mir problemlos übernommen, kurz die Logs prüfen
  • Benutzerrechte & Freigaben: Einmal durchgehen, ob alle Shares korrekt konfiguriert sind

💡 Mein persönliches Fazit

Das System läuft nach dem Update deutlich stabiler und ruhiger als vorher.

Alle Portainer-Container, Scripts und Services sind direkt wieder angesprungen.

Der Medienserver brauchte etwas Extra-Aufmerksamkeit – das war zu erwarten.

Hut ab an AuxXxilium: Der Arc Loader ist ein wirklich beeindruckendes Community-Projekt. Einfach WOW.

📌  Kurzfassung

💡 TL;DR

1. Arc Loader IMG von auxxxilium.tech herunterladen

2. Mit balenaEtcher (Mac) oder dd (Terminal) auf USB-Stick flashen

3. NAS vom Stick booten → Arc Loader über http://<IP>:7681 aufrufen

4. Passendes Synology-Modell auswählen (Wiki-Helper nutzen!) → DSM 7.2.2 wählen → Auto Mode

5. Arc baut das Image automatisch, System bootet neu

6. DSM-Installation über http://<IP>:5000 starten

7. Bestehende Konfiguration übernehmen, Pakete updaten, fertig!

💬 Eure Meinung interessiert mich!

Betreibt ihr auch ein XPenology-Setup? Welches Modell habt ihr gewählt und welche Erfahrungen habt ihr mit dem Arc Loader gemacht? Schreibt es in die Kommentare!

Besonders interessiert mich: Wer hat den Arc Loader mit exotischerer Hardware (AMD Ryzen, Intel i-Serie, etc.) zum Laufen gebracht? Und welche Modell-Kombi hat sich bewährt?

Garmin schweigt, Strava spricht – wie ich mein eigenes Performance-Dashboard gebaut habe

8. April 2026 / / Keine Kommentare

Garmin kann alles – gibt aber nichts raus.

Garmin brachte vor ein paar Monaten mit Connect+ ein Performance-Dashboard raus. Ganz nett und macht  Spaß, aber kostet halt Geld. Da nun auch mein Sohn mit einer Garmi Forerunner 165 unterwegs ist, wollte ich ihm dein Dashboard zur Verfügung stellen. Einfach um die Daten auszuwerten.
Und da mein Verstand der Programmierung nicht ganz so zugeneigt ist, habe ich einmal ein Seöbstversuch mit der KI/AI Claude gewagt (da Sie ja aktuell in aller Munde ist).
Was dann passierte, war eine mehrstundige Entwicklungsreise mit Claude – inklusive echter Fehler, echter Debugging-Sessions und einem Ergebnis das ich so nicht erwartet hatte: ein vollstaendiges, mobil-optimiertes Performance-Dashboard mit PMC-Chart, Rennprognosen, PWA-Support und automatischer Device-Erkennung. Und einer Erkenntnis uber Garmin, die ich schon ahnte, aber so direkt noch nie formuliert hatte.

Garmin: Die beste Hardware im Spiel – und eine API-Blackbox

Fangen wir mit dem Elefanten im Raum an. Garmin macht schlicht die beste Fitness-Hardware die es gibt (nein ich werde nicht gesponsort oder ähnliches, aber ich habe halt schon Jahrelang Apple und auch Wahoo getestet und genutzt). Die Uhr trackt alles – Herzfrequenz, VO₂max, Training Readiness, Schaltqualität, Body Battery, Stresslevel. Die Sensoren sind präzise, die Akkulaufzeit ist unschlagbar, das Ökosystem auf Garmin Connect ist ausgereift. Wer ernsthaft trainiert, läuft oder radelt, kommt an Garmin kaum vorbei.

Das Problem: Garmin hält seine API-Türen konsequent geschlossen (UND JA DAS NERVT ECHT DERBE Wütend).

Die Garmin Health API und die Connect API existieren – aber sie sind ausschließlich für zertifizierte Unternehmenspartner und Gesundheitsplattformen zugänglich. Kein offener Developer-Zugang, kein simples OAuth wie bei anderen Plattformen. Wer da rein will, braucht eine formale Partnerschaft mit Garmin. Das ist nicht mal bürokratisch umständlich – es ist schlicht nicht vorgesehen.

⚠️ Kurz zusammengefasst: Garmin ist das Apple-Ökosystem unter den Fitness-Plattformen. Alles drin, nichts raus. Hervorragende Hardware, aber die Daten gehören Garmin – und die teilen sie nicht leichtfertig.

Strava: Die Datenkrake, die uns rettet Feiernde Hände

Garmin synchronisiert automatisch alle Aktivitäten zu Strava. Lauf beendet, Uhr abgenommen, zehn Sekunden später ist die Aktivität auf Strava. Das ist der Standardworkflow für die meisten Garmin-Nutzer – und genau dieser Umweg wird zur Lösung.

Strava ist im Grunde die Datendrehscheibe für alles was sich auf zwei Beinen oder Rädern bewegt. Jede App, jedes Gerät, jede Plattform synct zu Strava. Und im Gegensatz zu Garmin hat Strava eine vollständig offene, gut dokumentierte API mit echtem OAuth-Flow und Rate Limits die man als Entwickler versteht.

💡 Die Erkenntnis: Strava ist nicht die Datenanwendung – Strava ist die Datenkrake, die all unsere Aktivitäten von allen Geräten saugt und als strukturierte API wieder rausgibt. Garmin liefert die Qualitätsdaten, Strava liefert den Zugang.

Der Umweg ist also eigentlich gar keiner. Er ist der einzig gangbare Weg – und wie sich zeigen wird, auch der bessere.

Iteration 1: Der erste Prototyp – und das CORS-Problem

Der erste Ansatz war ein React-Artifact direkt im Chat. Strava API abfragen, Daten anzeigen, fertig. Klingt einfach. Das Problem kommt beim Token-Austausch. Stravas OAuth-Endpoint blockiert Browser-Requests aus Sicherheitsgruenden – CORS macht das zunichte. Der Access Token kann nicht direkt im Browser geholt werden. Ein serverseitiger Schritt ist zwingend.

Die Lösung in Version 1: ein curl-Befehl den man manuell im Terminal ausführet, den Token copy-pastet. Funktioniert – als User kein Problem. Als dauerhafte Lösung aber nicht tragbar.

Das Ergebnis war ein dunkles Dashboard mit Strava-Orange, Athletenprofil, den letzten 30 Aktivitäten und YTD-Statistiken. Nicht schlecht für einen ersten Wurf. Aber der curl-Workflow war nichts, was ich meinem Sohn zumuten wollte. 😄 Sah halt auch sch***e aus ⁠Zwinkern.

Iteration 2: PHP auf den Webspace – der richtige Ansatz

PHP löst das CORS-Problem elegant: Der Token-Austausch passiert serverseitig per cURL, der Browser bekommt den fertigen Token nie zu Gesicht. Dazu: automatisches Token-Refresh, Session-basierte Authentifizierung und paginierter Datenabruf für bis zu 12 Monate Aktivitätshistorie.

// Token läuft ab? Kein Problem – läuft automatisch im Hintergrund

if (time() > $_SESSION[‚expires_at‘]) {

// Neuen Token per refresh_token holen

// User merkt nichts davon

}

Die Strava API gibt maximal 200 Aktivitäten pro Request zurück. Ein Jahr Training kann locker 400-500 Einträge bedeuten – also paginiert man. Seite für Seite bis alle Daten da sind, dann alles lokal filtern.

Was in Version 2 dazukam:

  • PHP-OAuth ohne manuelles curl – Strava-Login direkt im Browser, kein Gebastel
  • 12 Monate Aktivitaetshistorie, vollständig paginiert
  • Chart.js: Wochenvolumen gestapelt (Laufen/Radfahren), Pace-Trend, Sport-Verteilung
  • GitHub-style Trainingskalender (Heatmap der letzten 26 Wochen)
  • Sortierbare Aktivitätstabelle mit Suche und Filtern

Das Sicherheitsproblem: Wer darf rein?

Drei Optionen wurden diskutiert: htaccess-Passwort, PHP-Passwortabfrage, oder die eleganteste Lösung: die Strava Athlete-ID als Whitelist.

Nach dem ersten Login sieht man die eigene numerische Strava-ID im Header. Diese wird einmalig in der Konfigurationsdatei eingetragen. Danach kommt jeder andere Account nach dem OAuth-Callback auf eine Fehlermeldung – ohne jemals Daten zu sehen.

💡 Schöner Nebeneffekt: PHP-Sessions sind per Browser vollständig isoliert. Jeder Nutzer sieht automatisch nur seine eigenen Daten – ohne aufwändige Benutzerverwaltung.

Das Athleten-Limit: Wenn Strava querläuft (Runde 1)

Dann wollte auch mein Sohn das Dashboard nutzen. Und Strava lieferte prompt:

Fehler 403: Limit der verbundenen Sportler überschritten

Neue, nicht-verifizierte Strava API-Apps dürfen nur eine begrenzte Anzahl an Athleten verbinden. Nicht weil irgendetwas falsch konfiguriert ist – sondern weil Strava im Sandbox-Modus ein hartes Limit setzt.

Die Lösung: Jeder bekommt seine eigene Strava API-App. Kostenlos, dauert zwei Minuten.

$APPS = [

‚ICH‘ => [

‚client_id‘ => ‚12345‘, // Meine API-App

‚client_secret‘ => ‚abc…‘,

],

’sohn‘ => [

‚client_id‘ => ‚67890‘, // Seine API-App

‚client_secret‘ => ‚xyz…‘,

],

];

Ruft jemand strava.php ohne Parameter auf, erscheint eine Profilauswahl. Mit ?app=ICH oder ?app=sohn geht es direkt ins persoenliche Dashboard. Sessions vollständig isoliert – kein Athleten-Limit mehr.

Iteration 3: Das grosse Feature-Update – wie Garmin Connect, aber meins

Performance Management Chart (PMC)

CTL (Fitness, 42-Tage-EMA), ATL (Fatigue, 7-Tage-EMA) und TSB (Form = CTL minus ATL) als überlagerte Linien. Basis ist die Suffer Score aus der Strava API. Der Form-Indikator zeigt: Peak Form, Frisch, Neutral, Müde oder Übertraining. Das kenn ich von Garmin – und ja, es trifft meistens.

Rennprognosen per Riegel-Formel

Aus den schnellsten fünf Läufen werden automatisch Zielzeiten für 5K, 10K, Halbmarathon und Marathon berechnet: T2 = T1 x (D2/D1)^1.06 – bekannt aus der Laufwissenschaft, erstaunlich zuverlässig.

Herzfrequenz-Zonen und dynamische Filter

Z1 bis Z5 automatisch aus der maximalen Herzfrequenz berechnet. Zeitraum frei wählbar: 1M, 3M, 6M, 12M, alles. Sport-Filter, Freitextsuche, sortierbare Aktivitätstabelle. Alles live, alles ohne Seiten-Reload.

Feature Technik Details
Performance Management Chart CTL, ATL, TSB als Linien Wie Garmin Connect – selbst gehostet
Rennprognosen Riegel-Formel automatisch 5K / 10K / HM / Marathon
Herzfrequenz-Zonen Z1–Z5 automatisch Basis: Max-HF aus eigenen Daten
Dynamische Filter Zeitraum + Sport + Suche Live ohne Seiten-Reload
Trainingskalender GitHub-style Heatmap 26 Wochen Ueberblick
Bestleistungen Pro Sportart Laengste, schnellste, hoechste
Aktivitaetstabelle Alle Spalten sortierbar Mit Paginierung

Iteration 4: Mobile First – weil 90% Handy

Das bisherige Layout war Desktop-first – suboptimal wenn das Dashboard zu 90% vom Smartphone aus genutzt wird. Also: kompletter Neuaufbau, mobile-first.

  • Bottom Navigation Bar – vier Tabs, immer unten fixiert, daumenfreundlich erreichbar
  • KPI-Karten horizontal swipebar – Snap-to-Card, kein Tabellen-Cramming auf 375px
  • Aktivitäten als Cards statt Tabelle – Tabellen auf Mobile sind einfach keine gute Idee
  • PWA-Support – startet ohne Safari-UI vom iPhone-Homescreen als Vollbild-App
  • Safe Area Support – Notch, Home Indicator, Dynamic Island: alles berücksichtigt

💡 Tipp: URL im Safari oeffnen, ‚Zum Home-Bildschirm‘ auswählen. Das Dashboard startet danach als Vollbild-App ohne Browser-Chrome. Fühlt sich nativ an.

Praxistest: Drei Fehler, drei Lernmomente

Bis hierher klingt alles glatt. War es nicht. Der Praxistest hat drei echte Probleme geliefert – die ich nicht verschweigen will, weil sie den interessantesten Teil der Geschichte ausmachen.

Fehler 1: Authorization Error beim Sohn

Nach dem Autorisieren bei Strava kam direkt beim Redirect zurück: Authorization Error. Ursache: In der Strava API-App war als Callback-Domain lajdych.com eingetragen, die Seite lief aber unter www.lajdych.com. Strava ist da gnadenlos exakt – ein fehlendes www reicht für einen 400er.

⚠️ Merke: Die Callback-Domain muss exakt mit der Domain übereinstimmen die im Browser aufgerufen wird. Kein https://, kein Pfad, nur die Domain – und genau so wie sie in der URL steht.

Fehler 2: Logout und Profilwechsel funktionierten nicht

Der Logout hat die Session gelöscht – aber dann zurück zu ?app=ICH geleitet. Damit wurde app_key sofort wieder in die Session geschrieben und man landete wieder auf der Login-Seite desselben Profils statt auf der Profilauswahl.

Der Fix: Logout leitet jetzt zu $baseUrl ohne jeden Parameter. Zusätzlich gibt es ?switch=1 als eigenen Endpunkt der nur den app_key löscht und zur Profilauswahl zurückschickt.

// Logout: KEIN ?app= in der Redirect-URL!

header(‚Location: ‚ . $baseUrl); exit;

// Profil wechseln

if (isset($_GET[’switch‘])) {

unset($_SESSION[‚app_key‘]);

header(‚Location: ‚ . $baseUrl); exit;

}

Fehler 3: HTTP 500 nach dem Update

Nach dem Einbauen der Device-Detection-Logik kam ein blanker HTTP 500. Kein Fehlertext im Browser, nur weisser Bildschirm. Ursache: beim Einfügen des neuen Code-Blocks hatte ich das schliessende <?php endif; ?> des Haupt-Dashboard-Blocks gelöscht. PHP bekam ein syntaktisch unvollständiges if/else und hat die Datei komplett verweigert.

Das ist die Art von Fehler, die halt manchmal trotzdem passiert er & proggen ist nicht meine passion Nicht amüsiert. Weil man auf den Inhalt schaut und nicht auf die Klammern. Display Errors einschalten war richtig, hat hier aber nichts angezeigt, weil der Parse Error vor dem Output passiert. Der Blick in die Server-Error-Logs hätte es sofort gezeigt. 😄

Iteration 5: Automatische Device-Erkennung

Das Dashboard erkennt jetzt automatisch ob es auf einem Handy oder am Desktop aufgerufen wird – und passt die Ansicht entsprechend an. Kein manueller Wechsel, keine separaten URLs.

$isMobile = (bool) preg_match(

‚/(android|iphone|ipad|ipod|mobile|blackberry|opera mini|windows phone)/i‘,

$_SERVER[‚HTTP_USER_AGENT‘] ?? “

);

iPhone, iPad, Android: Mobile-Ansicht mit Bottom-Nav und swipebaren KPI-Karten. Alles andere: Desktop-Ansicht mit Top-Tab-Navigation, 5-Spalten-KPI-Grid und breiteren Charts. Zusätzlich gibt es einen manuellen Override-Button im Header – wird in der Session gespeichert.

Das Athleten-Limit: Runde 2

Und dann kam es nochmal. Nachdem alles lief und ich mich mit meinem Account einloggen wollte:

Fehler 403: Limit der verbundenen Sportler überschritten

Diesmal nicht wegen meines Sohns – sondern weil durch die vielen Verbindungsversuche, Fehler und Neustarts während der Entwicklung das Kontingent der App aufgebraucht war. Strava zählt nicht gleichzeitig aktive Athleten, sondern alle die jemals verbunden waren – inklusive fehlgeschlagener Versuche.

Die Lösung: App löschen und neu anlegen. Frische App, frisches Kontingent. Für meinen Sohn dasselbe.

⚠️ Wichtig für alle die das nachbauen: Beim Testen häufen sich schnell verbrauchte Kontingente an. Sobald alles stabil läuft, eine frische API-App anlegen und die finalen Credentials eintragen. Verhindert genau diesen Frust.

Das Ergebnis: Eine Datei, ein Upload, fertig

Das Endergebnis ist eine einzige strava.php. Kein Node.js, kein npm, kein Build-Prozess, keine externen Abhängigkeiten außer PHP mit cURL. Einfach hochladen, API-Keys eintragen, fertig.

Was Technik Details
Multi-User Je eigene Strava API-App Vollständig isolierte Sessions
OAuth Automatisch + Token-Refresh Kein manuelles Token-Handling
Datenabruf 12 Monate, paginiert Bis zu mehrere Hundert Aktivitäten
PMC Chart CTL, ATL, TSB Mit Form-Indikator + Trainingstipp
Rennprognosen Riegel-Formel 5K / 10K / HM / Marathon
HF-Zonen Z1–Z5 Verteilung nach Trainingszeit
Heatmap 26 Wochen GitHub-style Trainingskalender
Filter Zeitraum + Sport + Suche Dynamisch, live, ohne Reload
Device-Erkennung PHP User-Agent + Session Auto Mobile/Desktop + manueller Override
Mobile Bottom Nav + PWA Safe Area, swipeable KPIs
Logout/Switch Session-basiert Sauberer Wechsel zur Profilauswahl

Und hier ein paar kleine Screenshots:

Alles in allem, eine tolle Erfahrung & eine wunderbare Kooperation zwischen Claude & mir