Was Rewst richtig macht
Fangen wir mit dem Steelman an. Rewst löst ein reales Problem. Vor Rewst (und Liongard und einer Handvoll ähnlicher Tools) hatten MSPs zwei schlechte Optionen für tenant-übergreifende PowerShell-Automatisierung: Sich in jeden Client-Tenant einzeln einloggen und Skripte lokal ausführen, oder eine selbstgebaute Orchestrierung mit Service-Accounts und Scheduler aufsetzen. Beides skaliert schlecht.
Rewst hat das Muster “PowerShell aus einer Control Plane über N Client-Tenants ausführen” produktisiert. Darin ist es gut. MSPs, die es einsetzen, sparen bei wiederholbaren Aktionen echte Stunden pro Woche — User-Provisioning, Lizenzzuweisung, Gruppenverwaltung, Mailbox-Konfiguration.
Wir behaupten nicht, dass Rewst ein schlechtes Produkt ist. Wir behaupten, dass es um die falsche Achse herum entworfen wurde.
Was skripting-zentrierte Architekturen falsch machen
Ein PowerShell-Skript ist ein Ausführungsartefakt. Man liest den Code, führt ihn aus, bekommt Output.
Aber ein Skript, das einen Nutzer zu einer Global-Admin-Gruppe hinzufügt, ist nicht nur Code. Es ist ein Autorisierungsereignis, das ein Auditor zwei Jahre später rekonstruieren möchte. Ein Skript, das das Passwort eines Nutzers zurücksetzt und an eine Backup-Adresse mailt, ist nicht nur Code — es ist ein Compliance-Ereignis, potenziell ein Legal-Hold-Ereignis, potenziell ein Vertrauens-Ereignis für den Kunden, wenn die falsche Adresse gewählt wurde.
Skripting-zentrierte Automatisierungsplattformen behandeln das Skript als primäres Artefakt und Governance als Metadaten, die man nachträglich hinzufügt. Ausführungslogs existieren; Freigabe-Workflows existieren; Redaktionsfunktionen existieren. Aber sie sind obendrauf komponiert, in der Betriebsschicht des MSP, nicht eingebacken.
Was in der Praxis schiefgeht:
- Die Freigabeschicht ist auf Workflow-Ebene, nicht auf Aktionsebene. Sobald der Workflow läuft, werden die einzelnen Aktionen ohne Review pro Aktion ausgeführt. Bei Bulk-Passwort-Resets während eines bekannt-sicheren Ereignisses in Ordnung. Weniger in Ordnung, wenn der Workflow in einem seiner Zweige falsch war.
- Sensibler Output im Log ist das Problem des MSP. Service-Account-Tokens, einmalige Recovery-Codes, generierte Passwörter — wenn das PowerShell sie auf stdout ausgibt, landen sie im Ausführungslog. Sie zu redigieren ist ein Clean-up-Schritt, keine erstklassige Pipeline-Angelegenheit.
- Die Audit-Story ist ausführungszentriert, nicht änderungszentriert. “Welches PowerShell ist an diesem Tag gegen diesen Client-Tenant gelaufen?” ist beantwortbar. “Wer hat die Privilegienänderung bei Nutzer X um 15:47 autorisiert?” ist manchmal beantwortbar, manchmal nicht — weil Autorisierung möglicherweise ein impliziter Nebeneffekt der Workflow-Konfiguration war, kein diskretes Ereignis.
Das sind keine hypothetischen Beschwerden. Das sind die konkreten Audit-Fragen, die SOC-2-Prüfer, CMMC-Assessoren und HIPAA-Auditoren MSPs stellen, die ihren Betrieb auf Automatisierungsskripten aufbauen.
Governance-First: Was sich ändert
Die Automatisierungsschicht von JieGou startet von einer anderen Prämisse: Der Client-Tenant ist eine Governance-Grenze, und jede Aktion, die diese Grenze überschreitet, ist ein prüfbares Ereignis.
Die Konsequenzen:
-
Freigabe pro Aktion, nicht pro Workflow. Ein Job, der “das Passwort des CEO zurücksetzt und an seine Recovery-Adresse mailt”, ist ein einzelnes prüfbares Ereignis. Der Freigeber sieht vor der Freigabe das gerenderte PowerShell, den Ziel-Tenant und den Wirkungsradius der Aktion. Freigabe pro Workflow (das Rewst/Liongard-Modell) vermischt den Review-Punkt mit dem Kompositions-Punkt — man gibt einmal frei, “dieser Workflow sieht okay aus”, und danach feuern all seine einzelnen Zweige.
-
Shadow-Mode ist eine erstklassige Stufe, keine Workflow-Variante. Jede Aktion kann im Shadow-Mode laufen: Das PowerShell wird vorbereitet, die Eingaben werden aufgelöst, der Output wird simuliert, ohne Microsoft Graph / Exchange / was auch immer zu rufen. Der MSP-Operator sieht exakt, was passiert wäre. Erst danach wird auf Live hochgestuft.
-
Output-Redaktion ist in die Runner-Pipeline eingebaut. Der PowerShell-Runner erfasst stdout/stderr, führt einen Redaktions-Pass durch (entfernt Token-förmige, Passwort-förmige und andere sensibel-förmige Strings) und speichert nur die redigierte Version im Audit-Log. Der Operator sieht die redigierte Version in der UI. Der rohe Output wird nie persistiert.
-
KI-generierte Aktionen teilen sich die Pipeline. Das ist der bedeutsame architektonische Unterschied. Wenn ein KI-Entwurf vorbereitet wird — sei es ein PowerShell-Snippet, eine Ticket-Antwort oder ein Zeit-Eintrag — landet er in derselben Freigabe-Warteschlange wie menschlich initiierte Aktionen. Der MSP-Operator muss nicht getrennt “Dinge, die die KI getan hat” und “Dinge, die Skripte getan haben” regieren. Es ist eine Warteschlange.
-
Notfall-Overrides sind auditiert, nicht undokumentiert. Manchmal kann ein Ausfall nicht warten. Owner- und Admin-Rollen können eine ausstehende Freigabe überschreiben, indem sie einen Grund angeben. Die Override-Aktion, der Grund, die Identität des Freigebers und der ursprüngliche Antrag werden alle aufbewahrt. Das Override existiert für Notfälle, nicht als Abkürzung.
Wie sich das im direkten Vergleich anfühlt
Wir haben einen Feature-für-Feature-Vergleich auf der PowerShell-Automation-Feature-Seite veröffentlicht. Zusammenfassung der wichtigsten Zeile:
Freigabe pro Aktion. Rewst: nur auf Workflow-Ebene; sobald der Flow läuft, feuern einzelne Aktionen ohne Review pro Aktion. JieGou: auf einzelner Aktionsebene — jede Änderung einzeln freigeben oder ablehnen, mit sichtbarem gerendertem PowerShell.
Man kann die Augen zusammenkneifen und argumentieren, das sei dasselbe, wenn man Workflows in Ein-Aktions-Zweigen entwirft. Stimmt. Aber Workflows bleiben in einem MSP mit 20 Kunden nicht so ordentlich, und der Druck, größere Workflows zu komponieren, wächst mit der Größe. Freigabe pro Aktion hält die prüfbare Einheit auf der richtigen Granularität.
Wann Rewst immer noch die richtige Wahl ist
Wir tun nicht so, als sei JieGou für jeden MSP richtig. Fälle, in denen Rewst die bessere Wahl bleibt:
- Sie haben Ihre Automatisierungsbibliothek bereits in Rewst standardisiert und Ihr Team hat ein Jahr Muscle Memory darin. Die Wechselkosten sind real.
- Das Wertversprechen Ihres MSP lautet “wir automatisieren aggressiv, Governance ist zweitrangig”. Das ist eine vertretbare Positionierung. JieGou ist für MSPs, die Governance erstklassig haben wollen.
- Sie brauchen eine bestimmte Rewst-native Integration, die wir nicht ausliefern. Wir decken die gängigen MSP-Integrationen ab (ConnectWise Manage, Microsoft Graph, Exchange, Intune, Azure AD), aber Rewst hat in einigen Nischen einen tieferen Katalog.
Wohin der Markt unserer Meinung nach geht
Der MSP-Channel ist 18 Monate in die “KI für MSPs”-Konversation. Zwei Dinge haben sich bewegt:
-
Compliance-Käufer (MSPs mit MSA-Klauseln für SOC-2-Nachweise) wollen governance-native Automatisierung. Nicht “wir legen Governance obendrauf”. Sie wollen, dass die Plattform, die sie für den MSP-Betrieb gekauft haben, genau die Plattform ist, die dem Auditor antwortet — gleiches Audit-Log, gleiche Freigabe-Spur, gleiche Redaktion.
-
KI-unterstützte Aktionen sind operativ nicht mehr getrennt von geskripteten Aktionen. Wenn die KI-Schicht Ihres MSP eine Ticket-Antwort entwirft und die Automatisierungsschicht Ihres MSP den Ticket-Zeit-Eintrag schreibt, und beide durch denselben Client-Tenant reisen, sollen sie eine Pipeline sein. Nicht zwei Pipelines, die man abgleichen muss.
JieGou ist für diese beiden Marktverschiebungen gebaut. Rewst ist es nicht — by design. Das macht Rewst nicht falsch. Es macht es zu einem anderen Produkt für einen anderen MSP.
Wenn dieser andere MSP Sie sind, sollten Sie Rewst weiter verwenden, und der Rest dieses Artikels ist nicht für Sie.
Wenn Sie der MSP sind, der governance-native, AI-native, audit-native Operationen will — wir zeigen Ihnen gerne die Pipeline end-to-end in Aktion. Demo buchen oder das Operational-Bleed-Audit machen, um zu sehen, was Ihre aktuellen Lücken kosten.