Wie lange System Center Orchestrator unterstützt wird
Für die Planung zählt, welche Orchestrator-Version im Einsatz ist. Microsoft legt für jede Version ein festes Supportende fest (Fixed Lifecycle Policy). Angegeben ist jeweils der letzte unterstützte Tag:
| Version | Mainstream-Support | Erweiterter Support |
|---|---|---|
| System Center 2016 Orchestrator | 11.01.2022 | 11.01.2027 |
| System Center 2019 Orchestrator | 09.04.2024 | 09.04.2029 |
| System Center 2022 Orchestrator | 13.04.2027 | 13.04.2032 |
| System Center 2025 Orchestrator | 08.01.2030 | 09.01.2035 |
Für System Center 2016 Orchestrator endet der erweiterte Support am 11. Januar 2027; danach liefert Microsoft keine Sicherheitsupdates mehr. Neuere Versionen bleiben deutlich länger im Support. Ein Wechsel des Werkzeugs ist also keine Pflicht, sondern eine Entscheidung zwischen mehreren Wegen.
Die Wege nach SCOrch 2016
- Upgrade auf System Center 2025 Orchestrator: Die Runbooks bleiben in derselben Umgebung, der Support reicht bis Januar 2035. Lizenzierung und Betrieb der System-Center-Infrastruktur bleiben bestehen.
- Azure Automation: Microsoft bietet ein Migrations-Toolkit an, das die eigene Anleitung als Beta führt. Es wandelt Runbooks in grafische Runbooks um. Monitor-Aktivitäten, Variablen und Verbindungen werden nicht übernommen, und für den Zugriff auf lokale Systeme ist ein Hybrid Runbook Worker nötig.
- Service Management Automation (SMA): SMA führt Runbooks im eigenen Rechenzentrum aus, unterstützt aber keine grafischen Runbooks. Orchestrator-Runbooks müssen dafür laut Microsoft von Hand in PowerShell neu geschrieben werden.
- NodePilot: ein quelloffener, selbst gehosteter Workflow-Orchestrator für Windows mit grafischem Designer und einem Import für
.ois_export-Dateien. Die Runbook-Automatisierung bleibt im eigenen Netz; Aufwand entsteht beim Prüfen und Nacharbeiten der importierten Abläufe.
Welcher Weg passt, hängt von Lizenzsituation, Cloud-Strategie und den eingesetzten Integration Packs ab. Eine Bestandsaufnahme der vorhandenen Runbooks ist in jedem Fall der erste Schritt.
Mit den bestehenden Runbooks anfangen
Wer System Center Orchestrator ablösen möchte, muss mehr als die sichtbaren Aktivitäten übernehmen. Auch Verbindungen, Bedingungen, Published Data und die verwendeten Identitäten bestimmen das Verhalten eines Runbooks. NodePilot bietet einen Import für SCOrch-Exporte im Format .ois_export, um vorhandene Abläufe als Ausgangspunkt zu verwenden.
Was der Import leistet und wo Prüfung nötig ist
Unterstützte Aktivitäten werden auf NodePilot-Aktivitäten abgebildet. Nicht unterstützte Aktivitäten bleiben als deaktivierte Platzhalter sichtbar. Ein Importbericht hält fest, welche Stellen Aufmerksamkeit brauchen. Verschlüsselte Zugangsdaten werden nicht rekonstruiert; importierte Workflows sind zunächst deaktiviert.
Im Beitrag SCOrch-Runbooks importieren und das Ergebnis prüfen sind der Importablauf und seine Grenzen beschrieben. NodePilot ist kein zugesagter Ersatz für jede Integration oder jedes Verhalten von System Center Orchestrator.
Eine Migration in kleinen Schritten beurteilen
- Ein repräsentatives Runbook und seine erwarteten Ergebnisse auswählen.
- Den Export importieren und alle Hinweise im Importbericht durchgehen.
- Zielsysteme, Dienstkonten, Datenreferenzen und Zeitpläne prüfen.
- Erfolgs- und Fehlerfälle in einer Testumgebung mit dem bisherigen Verhalten vergleichen.
- Erst danach den geprüften Workflow bewusst aktivieren.
SCOrch und NodePilot im Vergleich
| Merkmal | System Center Orchestrator | NodePilot |
|---|---|---|
| Zielsysteme | agentenlos | agentenlos über WinRM, dasselbe Modell |
| Runbooks erstellen | Runbook Designer als Desktop-Anwendung | Designer im Browser mit Live-Status jedes Schritts |
| Testen | Runbook Tester mit Haltepunkten | Schritt-Debugger in der echten Engine, mit bedingten Haltepunkten und Variablenwerten zur Laufzeit |
| Versionen | nicht eingebaut | jede Änderung als Version, mit Vergleich und Rollback |
| Schnittstellen | Web-API zum Starten und Überwachen von Jobs | REST-API für alle Funktionen, np-CLI und MCP-Server |
| Datenbank | SQL Server | PostgreSQL oder SQL Server |
| Lizenz | kommerziell | Apache 2.0, keine Kosten pro Host |
| Support | Hersteller | Community; ein Open-Source-Projekt mit einem Maintainer |
Die Tabelle beschreibt den Funktionsumfang. Ob ein bestimmtes Runbook ohne Nacharbeit läuft, zeigt erst der Import mit anschließendem Test.
Eigener Betrieb und offene Lizenz
NodePilot läuft in der eigenen Windows-Umgebung und ist unter Apache 2.0 veröffentlicht. Die Voraussetzungen für den eigenen Betrieb und die Installationsanleitung helfen bei der Evaluation. Ein Supportvertrag oder eine Betriebsgarantie folgt aus der Open-Source-Lizenz nicht.
Beispiel: Eine tägliche Statusabfrage migrieren
Ein guter Anfang ist ein Runbook, das auf einem Testrechner einen Dienstzustand abfragt und das Ergebnis weitergibt. Erwartete Ausgabe und Fehlerverhalten werden vorab notiert. Nach dem Import werden Platzhalter ersetzt und der Ablauf mit einem vorhandenen sowie einem absichtlich ungültigen Dienstnamen getestet. Erst wenn Ausgabe, Verzweigung und Protokoll übereinstimmen, wird der Zeitplan aktiviert.
| Prüfpunkt | SCOrch-Ausgangspunkt | In NodePilot prüfen |
|---|---|---|
| Aktivitäten | Runbook und verwendete Integration Packs | Abbildung im Importbericht; Platzhalter ersetzen |
| Datenfluss | Published Data und Linkbedingungen | Variablenreferenzen und Zweige mit echten Testwerten |
| Identität | Ausführungskonto und gespeicherte Zugangsdaten | Zugangsdaten neu konfigurieren und Zielzugriff testen |
| Zeitplan | Bisherige Auslöser | Trigger prüfen; importierte Workflows bleiben zunächst deaktiviert |
SCOrch-Import, Aktivitätszuordnung und Einschränkungen · Ausführung und Fehlersuche in der Browserdemo ansehen.