Ivanti DSM End of Life: Mit Intune und RealmJoin neu anfangen
Ivanti DSM erreicht am 31. Dezember 2026 das End of Life. Wie du den Wechsel zu Microsoft Intune mit RealmJoin planst, den Repackaging-Aufwand klein hältst und die Softwareverteilung dabei modernisierst.
Ivanti DSM erreicht am 31. Dezember 2026 das End of Life. Nach diesem Datum gibt es keine Updates, keine Sicherheitspatches und keinen Herstellersupport mehr. Wer DSM weiterhin betreibt, braucht eine Migrationsstrategie, die das ersetzt, was DSM heute leistet, ohne alles von Grund auf neu zu bauen, und die zu der Art passt, wie IT inzwischen betrieben wird: cloud-verwaltete Geräte, Self-Service und kontinuierliche Updates.
RealmJoin ist als Ergänzung zu Microsoft Intune gebaut und übernimmt in DSM-Umgebungen genau den Teil, den Intune offen lässt: Paketierung, Patching, Self-Service und Automatisierung. Dieser Leitfaden führt durch eine Ivanti-DSM-Migration zu Intune und RealmJoin, vom ersten Assessment bis zu dem Tag, an dem DSM abgeschaltet wird.
Was nach dem Ivanti DSM End of Life passiert
Ivanti DSM über das End-of-Life-Datum hinaus zu betreiben, ist technisch möglich, die Software hört nicht über Nacht auf zu arbeiten. Die Risiken wachsen aber:
- Sicherheitslücken werden nicht mehr geschlossen
- Wichtige Software-Updates, die geschäftskritisch, aber nicht sicherheitsrelevant sind, lassen sich ebenfalls nicht mehr ausrollen
- Compliance-Frameworks wie ISO 27001 können ein nicht mehr unterstütztes DSM als untragbares Risiko einstufen
- Bugs und Integrationsprobleme müssen ohne Herstellersupport im eigenen Haus gelöst werden
- Migrationspartner und Know-how werden knapper, je näher die Deadline rückt
Die Deadline steht fest. Wie viel dann noch auf DSM läuft, nicht.
Softwareverteilung nach Ivanti DSM
Ivanti DSM war für ein klassisches IT-Modell entworfen: Infrastruktur im eigenen Rechenzentrum, domänengebundene Windows-Geräte und zentrale, weitgehend manuelle Prozesse. Moderne Umgebungen verlangen etwas anderes:
- Cloud-verwaltete Geräte, die nicht vom Unternehmensnetz abhängen
- Self-Service-Zugang zu Software für Endnutzer
- Kontinuierliche Updates für Drittanbieteranwendungen
- Weniger manuelle Paketierung und Pflege
Die Frage lautet also nicht mehr „Was ersetzt Ivanti DSM?“, sondern „Was trägt unser künftiges IT-Betriebsmodell?“.
Warum Microsoft Intune das Fundament ist
Microsoft Intune ist der cloud-native Endpoint-Management-Dienst in Microsoft 365. Er bringt Geräte-Enrollment und Lifecycle-Management, Sicherheitsrichtlinien und Compliance-Durchsetzung, Conditional Access mit Microsoft Entra ID sowie plattformübergreifenden Support für Windows, macOS, iOS und Android. Für eine Organisation, die auf Microsoft 365 läuft, ist er das logische Fundament für einen DSM-Ersatz.
Was Intune allein nicht vollständig abdeckt:
- Anwendungspaketierung in großem Maßstab
- Automatisiertes Patchen von Drittanbietersoftware
- Softwareverteilung im Self-Service
- Effiziente Verwaltung eines großen Softwarekatalogs
Was RealmJoin zu Intune ergänzt
RealmJoin erweitert Microsoft Intune zu einer Plattform für Application Lifecycle und Automatisierung und schließt genau diese Lücken. Apps und Patching ist das Modul, auf das es bei einer DSM-Migration am meisten ankommt, Automatisierung, Helpdesk-Werkzeuge und die Verwaltung lokaler Administratoren kommen mit dazu.
Fertige, gepflegte Anwendungspakete
- Mehr als 3.000 Unternehmensanwendungen, bereit zum Ausrollen
- Hunderte macOS-Apps, ausgeliefert über Intune
- Die kompletten iOS- und Android-App-Stores, verwaltet aus derselben Konsole (demnächst verfügbar)
- Neue Herstellerversionen werden innerhalb von 15 Minuten erkannt und laufen über die Preview- und Main-Kanäle mit der Verzögerung aus, die du festlegst
Was nicht im Katalog steht, wird auf Anfrage in kurzer Zeit paketiert, oder du lädst deinen eigenen Installer als Organic Package hoch. Wie das den Repackaging-Aufwand einer DSM-Migration klein hält, steht unter Größe des Paketkatalogs. Eigenentwickelte Anwendungen werden über auditierte Git-Repositories, CI/CD-basierte Paketierungs-Pipelines und standardisierte Qualitätskontrollen unterstützt. Die Dokumentation zum Package Store beschreibt, was im Katalog steht und wie Pakete gepflegt werden.
Self-Service-Softwareportal
Endnutzer installieren freigegebene Anwendungen selbst über den App Catalog auf dem Gerät. Das entlastet den Helpdesk und macht den Übergang für die Nutzer leichter, während der Migration und danach. Die Dokumentation zum Self-Service-Portal zeigt, wie es funktioniert.
Automatisiertes Patchen von Drittanbietersoftware
Sobald eine Anwendung abonniert ist, hält RealmJoin sie aktuell: kontinuierliche Updates, weniger Angriffsfläche, keine manuelle Pflege.
Software Lifecycle Management
Versionskontrolle und gestaffelte, automatisierte Rollouts, Nutzungsauswertung und Reporting sowie Sichtbarkeit der Software-Assets auf jedem Gerät. Vollständiges Lifecycle-Management ohne eigene Werkzeuge.
Runbook-Automatisierung und Remediation
RealmJoin bringt eine Bibliothek mit 175 Runbooks und Remediation-Skripten mit, gepflegt auf GitHub. Sie decken wiederkehrende Konfigurations- und Einstellungsaufgaben im gesamten Microsoft-365-Stack ab: Intune, Entra ID, Exchange Online und Teams.
Runbooks sind PowerShell-Skripte, die in Azure Automation in deiner eigenen Subscription laufen und aus dem RealmJoin-Portal ausgelöst werden. Admins und Supportmitarbeiter führen sie aus, ohne Intune-Experten zu sein und ohne hochprivilegierte Intune- oder Entra-Rollen zu halten, granulare Berechtigungen entscheiden, wer was ausführen darf.
Remediation-Skripte ergänzen sie, indem sie Konfigurationsprobleme direkt auf verwalteten Clients beheben. Wie die Runbooks liegen sie auf GitHub und werden über das Portal verwaltet.
Die Bibliothek enthält außerdem Skripte für Reporting und Auditing. Jede Aktion lässt sich zentral in Azure Log Analytics im eigenen Tenant protokollieren.
LAPS für cloud-verwaltete Geräte
Microsoft Entra und Intune bringen eine eingebaute LAPS-Lösung mit, beschränkt auf ein einziges lokales Administratorkonto pro Gerät. RealmJoin ergänzt eine eigene agentenbasierte Implementierung mit drei Kontotypen, jeder für einen bestimmten Zweck:
- Emergency-Konto: ein dauerhaftes lokales Administratorkonto für den Break-Glass-Zugriff, auch wenn das Gerät weder das Netz noch Intune erreicht.
- Support-Konto: wird bei Bedarf für die tägliche Supportarbeit angelegt und nach einer konfigurierbaren Ablaufzeit automatisch wieder entfernt, sodass keine dauerhaften Adminzugänge zurückbleiben.
- Privileged-Konto: lässt Power User über SelfLAPS temporäre lokale Administratorrechte für sich selbst anfordern, ohne dass die IT eingreifen muss.
Alle Kontotypen werden im RealmJoin-Portal konfiguriert, samt Erstellung bei Bedarf, Ablaufzeiten und Passwortvorgaben. Die Passwörter liegen verschlüsselt in einem Azure Key Vault im eigenen Tenant, und jede Passwortanfrage wird revisionssicher protokolliert.
Eine Konsole für Helpdesk und Betrieb
Darüber hinaus ergänzt RealmJoin eine gemeinsame Konsole für Helpdesk und Betrieb: Geräteinventar, integrierte Helpdesk-Werkzeuge und administrative Aktionen mit einem Klick.
Ivanti DSM vs. Intune vs. Intune + RealmJoin
| Fähigkeit | Ivanti DSM | Intune | Intune + RealmJoin |
|---|---|---|---|
| Softwareverteilung | ✓ | ✓ | ✓ |
| Entra ID-Integration | Eingeschränkt | ✓ | ✓ |
| Mobile Device Management | Eingeschränkt | ✓ | ✓ |
| Cloud-native Architektur | — | ✓ | ✓ |
| Patchen von Drittanbietersoftware | ✓ | Eingeschränkt | ✓ |
| Fertiger App-Katalog | Eingeschränkt | Eingeschränkt | ✓ |
| Sicherheitsupdates für Drittanbieter-Apps über 2026 hinaus | — | — | ✓ |
| Self-Service-Portal | Eingeschränkt | Eingeschränkt | ✓ |
| Runbook-Automatisierung | — | — | ✓ |
| LAPS für Cloud-Geräte | — | Eingeschränkt | ✓ |
| Sichtbarkeit von Deployments | ✓ | Eingeschränkt | ✓ |
| Herstellersupport über 2026 hinaus | — | ✓ | ✓ |
Bei Intune bedeutet „Eingeschränkt“ in den Zeilen zu Katalog und Patching das Add-on Enterprise App Management der Intune Suite: ein kuratierter Katalog mit Updates für die darin enthaltenen Apps, separat lizenziert.
Warum RealmJoin eine starke Ivanti-DSM-Alternative ist
Organisationen nutzen RealmJoin, um die Softwareverteilung in Intune-Umgebungen zu modernisieren und den Betriebsaufwand im großen Maßstab zu senken. Es ist kein Eins-zu-eins-Ersatz für Ivanti DSM, sondern eine Modernisierungsschicht für Microsoft Intune.
- Erspart den größten Teil des Anwendungs-Repackagings
- Verkürzt den Zeitplan der Migration
- Ergänzt Automatisierung für die Routinearbeit rund um Intune
- Ermöglicht cloud-native Softwareverteilung
- Verbessert die Erfahrung der Endnutzer
Statt DSM nachzubauen, heben Organisationen unterwegs ihr IT-Betriebsmodell auf einen neuen Stand.
Die wichtigsten Entscheidungen beim Ivanti-DSM-Ersatz
Größe des Paketkatalogs
DSM-Umgebungen umfassen häufig Hunderte über viele Jahre gewachsene Anwendungen. Sie neu zu paketieren, ist typischerweise der aufwendigste Teil einer DSM-Migration.
RealmJoin setzt dabei auf drei Ebenen an. Der Package Store liefert 3.000+ fertige, kontinuierlich gepflegte Pakete, ausrollbar über den RealmJoin Agent oder Intune, und deckt damit die Mehrheit der gängigen Unternehmensanwendungen ohne jeden Paketierungsaufwand ab. Für Anwendungen, die nicht im Store stehen, paketiert das Packaging-Team auf Anfrage. Generic Packages enthalten keine kundenspezifische Konfiguration und stehen allen Kunden ohne Zusatzkosten zur Verfügung, nur Pakete mit kundenspezifischer Anpassung ziehen vom Custom-Packaging-Kontingent ab. Und Organic Packages lassen dich deinen eigenen Installer als ZIP-Datei über das Portal hochladen, für den reinen Transport der Binaries mit fester Konfiguration. Sie werden innerhalb von Minuten automatisch gebaut, brauchen kein Ticket und kosten nichts extra, kommen dafür aber mit einem festen Installationspfad und lassen sich nach der Erstellung nicht mehr aktualisieren.
Der größte Teil eines DSM-Katalogs lässt sich damit ohne nennenswerten Repackaging-Aufwand und ohne Zusatzkosten abdecken: über den Store, über generische Paketierungsanfragen oder über Organic Packages für die einfacheren Binaries.
Modernisierung oder Lift-and-Shift
Das Ivanti DSM End of Life ist eine Gelegenheit, auf cloud-native Infrastruktur zu wechseln, Altlasten abzulegen, den Betriebsaufwand zu senken und Skalierbarkeit zu gewinnen. Organisationen, die modernisieren, erreichen langfristig bessere Ergebnisse als die, die das Altsystem nachbilden.
Kernbestandteile der Migration
Eine vollständige Migration von DSM zu Intune umfasst Anwendungspakete, Workflows der Softwareverteilung, Geräte- und Sicherheitsrichtlinien, Nutzer- und Gruppenkonfigurationen sowie Patch-Management-Prozesse. Intune in Kombination mit RealmJoin bietet für alles davon ein modernes Gegenstück.
Ivanti-DSM-Migration zu Intune in zehn Schritten
1. Die bestehende DSM-Umgebung analysieren
Nimm den aktuellen Aufbau auseinander: Anwendungen, Deployment-Workflows, Abhängigkeiten und Infrastruktur. Das definiert Umfang und Komplexität der Migration und verhindert Überraschungen mitten im Projekt.
2. Geschäftskritische Anwendungen und Use Cases identifizieren
Priorisiere die Anwendungen, die für den Tagesbetrieb unverzichtbar sind. Das hält das Geschäft am Laufen und bestimmt, welche Workloads zuerst validiert werden, bevor der breitere Rollout beginnt.
3. Die Zielarchitektur definieren
Setze Microsoft Intune als cloud-natives Management-Fundament und lege fest, wie RealmJoin es um Application Lifecycle Management, Automatisierung und Softwareverteilung erweitert. Dokumentiere diese Architektur, bevor du irgendetwas anderes anfasst.
4. Intune aufsetzen und RealmJoin parallel evaluieren
RealmJoin setzt Microsoft Intune als Grundlage voraus. Für Organisationen, die noch nicht auf Intune sind, läuft dieser Schritt in zwei parallelen Spuren: Intune für den Microsoft-365-Tenant aktivieren und RealmJoin onboarden. Buch eine Demo, um die Migration gegen deine aktuelle Umgebung zu prüfen.
5. DSM-Anwendungen auf RealmJoin-Pakete abbilden
Vergleiche das aktuelle Anwendungsportfolio mit dem RealmJoin-Katalog. Ermittle, welche Anwendungen bereits durch Generic Packages abgedeckt sind, und markiere die Lücken, die paketiert werden müssen. Dieses Mapping ist die Grundlage des Migrationsplans.
6. Paketierung für die fehlenden Anwendungen anfordern
RealmJoin bietet Packaging as a Service. Stell eine Anfrage für das, was der Katalog nicht abdeckt: Generic Packages werden mit allen Kunden geteilt und sind im Abonnement enthalten, Organic Packages sind innerhalb von Minuten fertig, und nur kundenspezifische Anpassung zieht vom Custom-Packaging-Kontingent ab. Der größte Teil des internen Paketierungsaufwands einer DSM-Migration verschwindet an dieser Stelle.
7. Intune und RealmJoin für das Deployment konfigurieren
Konfiguriere Intune-Richtlinien und Compliance-Einstellungen, binde RealmJoin an und lege Paketzuweisungen und Deployment-Gruppen fest. RealmJoin-Pakete folgen strukturierten Zuweisungs- und Konfigurations-Workflows, was den Prozess nachvollziehbar und wiederholbar hält.
8. Deployments in einem Piloten validieren
Teste reale Szenarien vor dem breiten Rollout: Installationsverhalten, Zuweisungslogik und Targeting, Update- und Patching-Workflows. Die gestaffelten Rollouts von RealmJoin über die Preview- und Main-Kanäle machen es unkompliziert, das Verhalten in einer kontrollierten Gruppe zu prüfen, bevor skaliert wird.
9. Self-Service freischalten und den Rollout skalieren
Sobald der Pilot validiert ist, aktiviere den App Catalog für den Self-Service und weite das Deployment in kontrollierten Phasen aus. Das reduziert die Einbindung des Helpdesks, verbessert die Erfahrung der Endnutzer während des Übergangs und gibt der IT Sichtbarkeit über den Fortschritt des Rollouts.
10. Ivanti DSM außer Betrieb nehmen
Sobald alle Anwendungen auf RealmJoin-Pakete migriert sind, über Intune ausrollbar und per Lifecycle-Automatisierung verwaltet, nimm Ivanti DSM außer Betrieb und schließe den Übergang ab. Halte diesen Schritt an eine vollständige Validierung gebunden, zu frühes Abschalten ist einer der häufigsten Fehler bei Migrationen.
Es ist nicht zu spät
Das Ivanti DSM End of Life rückt näher, und das ist in Ordnung. Du musst bis dahin nicht fertig sein, du musst angefangen haben, und der Anfang geht schnell. Ein einziger Microsoft-Entra-Admin-Consent verbindet RealmJoin mit deinem Tenant, der größte Teil deines Katalogs steht bereits im Package Store, und wir haben Kunden in weniger als acht Stunden von null zu ihren ersten Pilot-Deployments gebracht. Von dort läuft der Wechsel in Stufen, die du steuerst: zuerst die Pilotgruppe, dann die Preview- und Main-Kanäle, Self-Service, wenn du so weit bist. Was am Jahresende noch auf DSM läuft, ist eine schrumpfende Liste, kein Risiko. Buch eine Demo und wir fangen mit deinem Katalog an.
Häufige Fragen zur Ivanti-DSM-Migration
Wann erreicht Ivanti DSM das End of Life?
Am 31. Dezember 2026.
Kann ich Ivanti DSM nach dem End of Life weiter nutzen?
Ja, aber ohne Updates, Sicherheitspatches und Herstellersupport, was Risiken für Sicherheit, Compliance und Betrieb mit sich bringt.
Worauf sollte ich in einem DSM-Migrationsprojekt zuerst achten?
Auf die Größe des Anwendungskatalogs, den Paketierungsaufwand, Self-Service-Fähigkeiten, Patch-Automatisierung und darauf, wie gut das Ziel zu einer cloud-verwalteten Umgebung passt.
Was ist RealmJoin?
RealmJoin ist eine Plattform für Application Lifecycle und Automatisierung rund um Microsoft Intune: fertige Anwendungspakete, automatisiertes Patching, ein App Catalog im Self-Service, Runbook-Automatisierung und die Verwaltung lokaler Administratoren (LAPS).
Wie senkt RealmJoin den Migrationsaufwand?
Indem es den größten Teil des Repackagings erübrigt. Ein großer, kontinuierlich gepflegter Katalog von Windows- und macOS-Anwendungen deckt die Schnittmenge ab. Was fehlt, wird auf Anfrage paketiert, als Generic Package ohne Zusatzkosten geteilt, sofern keine kundenspezifische Konfiguration im Spiel ist, oder in Minuten als Organic Package hochgeladen. Nur kundenspezifische Anwendungen ziehen vom Custom-Packaging-Kontingent ab.
Wie lange dauert eine Ivanti-DSM-Migration?
Die ersten Pilot-Deployments dauern einen Tag, kein Quartal: Den Tenant anzubinden ist ein Admin-Consent, und der größte Teil des Katalogs steht bereits im Package Store. Wie lange der vollständige Wechsel dauert, hängt von der Größe deines Katalogs und dem Tempo ab, das du wählst, er läuft in Stufen, die du steuerst.
Braucht RealmJoin Infrastruktur im eigenen Rechenzentrum?
Nein. RealmJoin ist eine SaaS-Plattform, gehostet in Microsoft Azure in Europa. Sie wird mit einem Admin-Consent an Microsoft Intune und Microsoft 365 angebunden, und die sensiblen Teile wie Runbooks, lokale Administratorkennwörter und Logs laufen in deinem eigenen Tenant.
Noch etwas?
Schau in die FAQ in der Dokumentation oder nimm Kontakt auf.
Quellen
- Ivanti, Desktop & Server Management (DSM): "Desktop & Server Management (DSM) will reach End of Life (EOL) on December 31, 2026. After this date, product updates and official support will no longer be provided."
- Ivanti, End-of-Life Support for Ivanti DSM and former HEAT products und der Zeitplan zum Produkt-End-of-Life.
- Microsoft Learn, Microsoft Intune Enterprise Application Management: der Enterprise App Catalog hinter den Zellen „Eingeschränkt“ im Vergleich.
DSM ersetzen, nicht nachbauen
RealmJoin ist der Begleiter zu Microsoft Intune: 3.000+ gepflegte Pakete, Paketierung auf Anfrage, gestaffelte Updates, Self-Service und 175 Runbooks, mit einem einzigen Admin-Consent an deinen Tenant angebunden. Die meisten DSM-Kataloge sind abgedeckt, bevor das erste eigene Paket nötig wird.