Power Automate versus PowerShell + Aufgabenplanung — Jedes Automatisierungswerkzeug dort einsetzen, wo es passt, statt sie zu vermischen

„Bei uns läuft seit fast zehn Jahren ein nächtlicher PowerShell-Batch auf dem Buchhaltungsserver. Gleichzeitig haben Mitarbeiter auf der Fachseite in letzter Zeit begonnen, Anfrage- und Benachrichtigungs-Flows in Power Automate zu bauen. Beides heißt ‚Automatisierung‘, doch die Art, wie es gebaut wird, und wo es lebt, ist völlig unterschiedlich – und während beide Familien weiterwachsen, kann niemand sagen, in welchem der beiden eine neue Automatisierung gebaut werden soll, oder wer den Gesamtüberblick hat.“ Das höre ich in letzter Zeit oft von kleinen und mittleren Unternehmen, die Microsoft 365 bereits eingeführt haben.

PowerShell + Aufgabenplanung und Power Automate sind beide Werkzeuge, um „eine feste Aufgabe automatisch zu erledigen“, doch ihre Stärken überschneiden sich kaum. Gerade weil sie sich nicht überschneiden, wird es schmerzhaft, alles auf eine Seite zu zwingen – und sie ohne festgelegte Grenze zu vermischen erzeugt einen Flickenteppich, den niemand warten kann. Dieser Artikel ordnet den Charakterunterschied der beiden ein und erklärt dann die Kriterien für die Entscheidung, worin gebaut werden soll, sowie die Verbindungsmuster, wenn Sie sie doch mischen. Die übergreifende Designtheorie zu Power Automate wird in „Geschäftsprozesse mit Power Automate automatisieren ── Cloud-Flows, Desktop-Flows und robuste Fehlerbehandlung“ behandelt, eine Einführung in PowerShell selbst in „PowerShell-Befehlsgrundlagen ── Was Sie zuerst lernen sollten und wie Sie es sicher einsetzen“, sodass ich mich hier eng auf „was wählen“ und „wie verbinden“ konzentriere.

1. Die wichtigsten Punkte vorab

• Das erste Kriterium ist wo sich das Ziel befindet. Liegt das Ziel bei lokalen Dateien, Freigabeordnern, Servern oder dem Betriebssystem, verwenden Sie PowerShell + Aufgabenplanung; liegt es bei Daten, Benachrichtigungen und Genehmigungen auf Microsoft 365 wie SharePoint, Outlook oder Teams, verwenden Sie Power Automate.
• PowerShells Schwachpunkt ist es, Menschen zu benachrichtigen. Das lange Zeit übliche Send-MailMessage ist offiziell veraltet, und es gibt innerhalb von PowerShell keinen direkten Ersatz.¹ Benachrichtigung und Genehmigung Power Automate zu überlassen ist am Ende günstiger.
• Power Automates Schwachpunkte sind es, lokale Ressourcen zu erreichen und große Datenmengen zu verarbeiten. Damit ein Cloud-Flow einen internen Dateiserver erreicht, brauchen Sie ein lokales Datengateway oder eine Desktop-Flow-Integration, und beides fällt außerhalb der mit Microsoft 365 gebündelten Nutzungsrechte (beides sind Premium-Funktionen).²³⁴
• Wenn Sie beide verbinden wollen, ist der erste Kandidat lose Kopplung, bei der PowerShell eine Ergebnisdatei in SharePoint ablegt und Power Automate sie mit einem „Wenn eine Datei erstellt wird“-Trigger erkennt und dann mit Benachrichtigung und Genehmigung fortfährt.⁵
• Power Automate for desktop verfügt über eine Aktion „PowerShell-Skript ausführen“, sodass Sie vorhandene Skripte aus einem Flow heraus aufrufen können. Das Auslösen aus einem Cloud-Flow heraus ist jedoch eine Premium-Funktion, und Sie müssen zudem den ausführenden Rechner verwalten.⁶⁴
• Der Ausführungsverlauf eines Cloud-Flows ist standardmäßig nur 28 Tage lang einsehbar.⁷ Für Verarbeitung, die einen Prüfnachweis braucht, bewahren Sie die Nachweise in einer PowerShell-seitigen Protokolldatei auf oder schreiben Sie sie zurück in eine SharePoint-Liste.
• Am Ende ist die richtige Antwort oft überhaupt keine technische: Bauen Sie es in dem Werkzeug, das jemand tatsächlich warten kann. Eine Automatisierung, die nur ihr Autor reparieren kann, ist unabhängig vom Werkzeug dasselbe Risiko.

2. Der Charakter der beiden Werkzeuge

Zunächst wollen wir bestätigen, dass diese beiden Werkzeuge in unterschiedlichen Arenen antreten.

Wichtig ist, dass sich sowohl „wo es läuft“ als auch „wer es baut“ zwischen der linken und rechten Seite dieser Tabelle unterscheidet. PowerShell + Aufgabenplanung läuft auf einem internen Rechner, wird von jemandem gebaut, der Code schreiben kann, und wird als Code verwaltet. Power Automate läuft in der Cloud, kann auch von einem versierten Fachanwender gebaut werden und erfordert keine Pflege einer Ausführungsplattform. Mit anderen Worten: Beides zu haben ist nicht bloß eine Doppelung von Werkzeugen – es ist das Nebeneinander zweier Kulturen: „Automatisierung durch die IT-Abteilung“ und „Automatisierung durch die Fachseite“. Genau deshalb scheitert der Versuch, per Dekret alles auf eine Seite zu vereinheitlichen, in der Regel.

3. Eine Entscheidungstabelle für die Wahl des Werkzeugs

Wenn mich jemand fragt, teile ich die Frage in drei auf: Wo befindet sich das Ziel, wer wird es hauptsächlich bauen und warten, und muss ein Mensch benachrichtigt oder um Genehmigung gebeten werden? Konkrete Beispiele machen das leichter fassbar, daher hier eine Entscheidungstabelle.

Liest man die Spalten vertikal, sehen Sie, dass das Werkzeug fast eins zu eins durch die Spalte „Ziel“ bestimmt wird. Die Ausnahme ist der Fall in der letzten Zeile, der „lokale Verarbeitung, Benachrichtigung in der Cloud“ überspannt – und genau dort kommen die Integrationsmuster aus Kapitel 6 ins Spiel.

Umgekehrt werden folgende Entscheidungswege später wehtun.

• Selbst die Dateiverarbeitung in Power Automate zwängen, nur weil Sie Benachrichtigungen wollen. Ein Gateway oder RPA einzuführen, um lokale Ressourcen zu erreichen, erhöht sowohl Lizenzen als auch zu Verwaltendes (Kapitel 5).
• Die IT-Abteilung eine SharePoint-Anfrageflow-Lösung in PowerShell bauen lassen, die von der Fachseite genutzt wird. Das ist möglich, aber SharePoint-Schreibvorgänge und Teams-Benachrichtigungen in Code zu schreiben lohnt den Aufwand kaum und erzeugt ein Einzelstück, das die Fachseite nicht anfassen kann.
• Jeden frei wählen lassen, weil beide Werkzeuge funktionieren würden. Das führt direkt zum Wartungsproblem aus Kapitel 7. Schon eine einzige interne Regel zu vereinbaren – „wenn das Ziel hier liegt, ist dies das Werkzeug“ – trägt viel dazu bei, die Unordnung des Nebeneinanders zu zähmen.

4. Die Grenzen der PowerShell-Seite

E-Mail- und Teams-Benachrichtigungen sind mühsam

In dem Moment, in dem jemand „lass mich per E-Mail wissen, wenn es fertig ist“ an einen nächtlichen PowerShell-Batch anhängt, wird das Gespräch plötzlich schwieriger. Das seit Jahren verwendete Cmdlet Send-MailMessage ist offiziell als veraltet markiert, mit der Begründung, dass es keine sichere Verbindung zu einem SMTP-Server garantieren kann, und die Warnung hält ausdrücklich fest, dass es innerhalb von PowerShell keinen direkten Ersatz gibt. Als Alternativen werden die Drittanbieter-Bibliothek MailKit genannt oder – für Nutzer von Exchange Online – das Microsoft-Graph-PowerShell-SDK (Send-MgUserMail).¹

Der Versand über Graph funktioniert zwar, doch App-Registrierung in Microsoft Entra ID, die Vergabe von Berechtigungen (Scopes) und die Verwaltung eines Zertifikats oder Geheimnisses summieren sich für eine einzelne Benachrichtigung zu einer Menge Vorbereitung. Dasselbe gilt für Teams-Benachrichtigungen: Sie direkt aus Code anzustoßen legt die Authentifizierungshürde hoch. Hier würde ich schlicht empfehlen, sich zu entscheiden, die Benachrichtigung Power Automate zu überlassen. Mit den Standard-Connectoraktionen von Outlook und Teams lässt sich in Minuten etwas zusammenstellen, ganz ohne zusätzliche App-Registrierung.

„Verwilderte Aufgaben“, die auf dem PC einer Einzelperson laufen

Ein häufiger Unfall bei Automatisierung über die Aufgabenplanung ist der Fall, in dem die Aufgabe auf dem PC eines Mitarbeiters statt auf einem Server platziert ist. Fährt diese Person den PC herunter und geht nach Hause, läuft sie nicht; und sie stoppt lautlos, wenn sich das Passwort des Ausführungsbenutzers ändert oder die Person das Unternehmen verlässt. Schlimmer noch: Da die Aufgabenplanung lokal auf jedem Rechner liegt, gibt es keine einzige Stelle, an der aufgelistet ist, was im Unternehmen wo läuft.

Die Gegenmaßnahmen sind wenig glamourös: (1) geplante Aufgaben auf einem dafür vorgesehenen Server konsolidieren (oder, falls das nicht geht, auf einem dauerhaft laufenden Verwaltungs-PC); (2) die Liste der Aufgaben samt Zweck und Zuständigem dokumentieren; und (3) die Aufgabendefinitionen selbst als Skripte mit Register-ScheduledTask und Ähnlichem festhalten, sodass sie sich bei einem Rechnerwechsel reproduzieren lassen.⁸ Selbst wenn Sie die Skriptkörper in Git aufbewahren, lässt sich die Umgebung nicht reproduzieren, solange die Einstellungen der Aufgabenplanung (Startzeit, Ausführungsbenutzer, Arbeitsordner) manuelle Handarbeit bleiben.

Zugangsdaten speichern

Sobald sich ein Skript mit einer Datenbank oder einem externen Dienst verbindet, stellt sich unweigerlich die Frage, wo das Passwort aufbewahrt werden soll. Es direkt in die .ps1 zu schreiben, kommt nicht infrage; PowerShells Standardantwort ist das Modul SecretManagement plus die Erweiterung SecretStore. Geheimnisse werden lokal verschlüsselt gespeichert, und das Skript ruft sie mit Get-Secret ab.⁹ Die Konfiguration für unbeaufsichtigte Ausführung über die Aufgabenplanung (die Einrichtung im Kontext des Automatisierungskontos) ist ebenfalls offiziell dokumentiert.¹⁰ Beachten Sie, dass diese Modulfamilie inzwischen als funktional abgeschlossen gilt und die Entwicklung neuer Funktionen beendet ist, während die Unterstützung bei Sicherheitskorrekturen fortgeführt wird.⁹

Power Automate hält Verbindungen (Authentifizierung) zu Connectoren dagegen auf Plattformseite, sodass der Ersteller dieses Problem nie bedenken muss. Das ist eine verborgene Stärke von Power Automate – und schafft umgekehrt ein anderes Verwaltungsproblem, da Verbindungen an das Konto des Flow-Besitzers gebunden sind. Dieser Punkt wird in „Personenabhängigkeit bei Power Automate vermeiden ── Besitz, Verbindungen und Übergabe gestalten“ behandelt.

5. Die Grenzen der Power-Automate-Seite

Es kann lokale Dateien oder interne Systeme nicht erreichen

Da Cloud-Flows in Microsofts Cloud laufen, können sie Freigabeordner im internen Netzwerk oder lokale Datenbanken nicht direkt erreichen. Es gibt zwei Hauptwege dorthin.

1. Ein lokales Datengateway. Sie installieren intern eine dauerhaft laufende Anwendung, die eine Brücke zur Cloud schlägt. Dafür müssen keine eingehenden Ports geöffnet werden, es funktioniert nur mit ausgehenden Verbindungen, was es zu einem recht sicheren Mechanismus macht.¹¹ Es ermöglicht Verbindungen zu Dateisystemen, SQL Server und Ähnlichem über das Gateway – aber die Nutzung eines Gateways erfordert eine unterstützende Lizenz.²
2. Über einen Desktop-Flow (RPA). Der Cloud-Flow ruft einen auf einem PC laufenden Desktop-Flow auf und delegiert die lokale Verarbeitung an ihn. Dieses „Auslösen und Planen aus einem Cloud-Flow heraus“ ist selbst eine Premium-Funktion.⁴

Der entscheidende Punkt ist, dass keines von beidem in den mit Microsoft 365 gebündelten Power-Automate-Nutzungsrechten enthalten ist. Die mit Microsoft 365 mitgelieferte Basislizenz umfasst weder Premium-Connectoren noch lokale Gateways noch RPA.³ Mit anderen Worten: „Ich möchte Dateien auf dem Freigabeordner mit Power Automate verarbeiten“ ist eine teurere Anfrage, als sie aussieht. Die Lizenzstufen und die Grenze zwischen Standard und Premium werden in „Power-Automate-Lizenzierung und die Grenze zwischen Standard- und Premium-Connectoren“ dargelegt, prüfen Sie das also, bevor Sie sich entscheiden.

Es gibt zwei realistische Optionen, die Zusatzkosten vermeiden. Entweder verlagern Sie den Speicherort der zu verarbeitenden Dateien nach SharePoint/OneDrive, oder Sie überlassen die Freigabeordner-Seite PowerShell und lassen Power Automate nur die Cloud-seitige Arbeit übernehmen. Letzteres ist das Integrationsmuster im nächsten Abschnitt.

Große Datenmengen und komplexe Logik sind mühsam

Verarbeitung, die eine CSV mit mehreren hunderttausend Zeilen Zeile für Zeile in einer Flow-Schleife durchläuft, liegt außerhalb dessen, wofür Power Automate konzipiert ist. Es gibt zudem lizenzabhängige Tageslimits für die Anzahl der Aktionsausführungen: Bei den mit Microsoft 365 gebündelten Nutzungsrechten sind das 6.000 Aktionen pro Benutzer und Tag.³ Abgleich, Aggregation und Transformation großer Datenmengen sind zudem genau die Art von Verarbeitung, die in PowerShell oder .NET geschrieben in Minuten fertig ist. Für konkrete Techniken lassen sich die in „Praktische PowerShell-Befehlsrezepte ── die kleinen Werkzeuge, die Sie täglich nutzen, weiterentwickeln“ behandelten Kombinationen von Group-Object und Compare-Object direkt anwenden.

Logik mit tief verschachtelten Bedingungsverzweigungen ist zudem auf der Flow-Zeichenfläche schwer zu lesen, und Sie können dafür keine Tests schreiben. Die Grenze von 30 Tagen für einen einzelnen Cloud-Flow-Lauf¹² ist bei Genehmigungswartezeiten relevant, aber davor gilt: „Logik, deren Verzweigungsdiagramm nicht auf ein A4-Blatt passt“, gehört ins Reich des Codes.

Der Ausführungsverlauf verschwindet nach 28 Tagen

Der Ausführungsverlauf eines Cloud-Flows wird standardmäßig nur 28 Tage lang angezeigt.⁷ Für eine Anforderung wie „in drei Monaten möchte ich prüfen, ob der Batch an jenem Tag gelaufen ist“, nützt der Ausführungsverlauf nichts. Mit PowerShell können Sie eine eigene Protokolldatei schreiben und sie so viele Jahre aufbewahren, wie Sie möchten (dieses Design wird ausführlich im Artikel zur Protokollpflege behandelt). Brauchen Sie mit Power Automate einen Prüfnachweis, bauen Sie einen Schritt in den Flow selbst ein, der die Ergebnisse zurück in eine SharePoint-Liste schreibt. Für den Aufbau von Fehlerbenachrichtigung und Wiederholungen siehe „Fehlerbehandlung und Wiederholungsdesign in Power Automate ── Verhindern, dass „der Flow lief doch, und ist dann einfach stehen geblieben““.

6. Verbindungsmuster zum Mischen der beiden

Da sich die Stärken der beiden Werkzeuge nicht überschneiden, entsteht unweigerlich Arbeit, die „Verarbeitung in PowerShell, Benachrichtigung und Genehmigung in Power Automate“ überspannt. Es gibt drei Verbindungsmuster.

Muster a: Lose Kopplung über Dateien (empfohlen)

Ein unter der Aufgabenplanung laufendes PowerShell-Skript legt seine Ergebnisse (eine Ergebnis-CSV, eine Zusammenfassung) in einer SharePoint-Bibliothek ab, und die Power-Automate-Seite erkennt dies mit dem Trigger „Wenn eine Datei erstellt wird (nur Eigenschaften)“ des SharePoint-Connectors und fährt mit Benachrichtigung oder Genehmigung fort. Das ist ein echter Trigger auf dem Standard-Connector, und Änderungen werden typischerweise innerhalb weniger Minuten erfasst (er funktioniert per Abfrage von SharePoint auf Änderungen, ist also nicht sofort).⁵

flowchart TD
    T[Aufgabenplanung startet um 02:00] --> PS[PowerShell-Skript<br/>Aggregation, Dateiverarbeitung, Protokollierung]
    PS --> OUT[Ergebnis-CSV und Zusammenfassung schreiben]
    OUT --> UP[In eine SharePoint-Bibliothek ablegen]
    UP --> TRG[Cloud-Flow startet<br/>Wenn eine Datei erstellt wird]
    TRG --> CHK{Inhalt der Zusammenfassung}
    CHK -- Normal abgeschlossen --> OK[Abschlussmeldung an Teams]
    CHK -- Fehler vorhanden --> NG[Besitzer benachrichtigen<br/>bei Bedarf zu Genehmigungs-/Reaktions-Flow weiterleiten]

Wie PowerShell Dateien in SharePoint ablegt, wählen Sie danach, wie die Aufgabe läuft. Den Ausgabeordner zu einem Synchronisierungsziel von OneDrive/SharePoint zu machen (sodass das Skript nur in einen lokalen Ordner schreibt) ist der einfachste Ansatz, doch der Sync-Client ist eine Anwendung, die in einer angemeldeten Benutzersitzung läuft. Bei einer nächtlichen Aufgabe, die so konfiguriert ist, dass sie „unabhängig davon läuft, ob der Benutzer angemeldet ist“, oder auf einem Server, an dem niemand angemeldet ist, läuft die Synchronisierung nicht – die lokal geschriebene Datei wird nie hochgeladen, und der Flow wird nie ausgelöst, sodass Sie einen stillen Leerlauf erhalten. Für kleinen Betrieb, der tagsüber auf einem bedienten PC läuft, genügt Synchronisierung; ist unbeaufsichtigte nächtliche Ausführung jedoch die Voraussetzung, laden Sie entweder direkt aus dem Skript mit PnP.PowerShell oder der Graph-API hoch, oder stellen Sie eine dauerhaft angemeldete Sitzung für die Synchronisierung bereit und beziehen Sie sie in Ihre Überwachung ein. Das bringt zusätzlichen Authentifizierungsaufwand mit sich, beseitigt aber strukturell das Problem „die Datei, von der ich sicher war, sie abgelegt zu haben, ist nicht da“.

Der Grund, warum ich dieses Muster empfehle, ist, dass die Grenze in sichtbarer Form fixiert ist: eine Datei. Die PowerShell-Seite weiß nicht, dass Power Automate existiert, und die Power-Automate-Seite weiß nicht, was im Skript steckt. Fällt eine der beiden Seiten aus, verrät der Blick darauf, ob die Datei in SharePoint liegt, sofort, auf welcher Seite das Problem liegt. Sie können den Besitz auch aufteilen: Das Skript gehört der IT, der Benachrichtigungs-Flow einem versierten Fachanwender – diese Arbeitsteilung funktioniert einfach. Obendrein dient die abgelegte Datei auch als Prüfnachweis, der das 28-Tage-Problem des Ausführungsverlaufs ausgleicht.⁷

Muster b: PowerShell aus Power Automate for desktop heraus aufrufen

Power Automate for desktop (PAD) verfügt über eine Aktion „PowerShell-Skript ausführen“, mit der sich beliebiger PowerShell-Code aus einem Desktop-Flow heraus ausführen und die Ausgabe in einer Variablen (PowershellOutput) empfangen lässt.⁶ Da Sie vorhandene Skript-Assets als Flow-Komponenten aufrufen können, lässt sich ein Aufbau realisieren, bei dem „die eigentliche Verarbeitung ein Skript bleibt und PAD nur den Start sowie die umgebenden Bildschirmvorgänge übernimmt“.

Es gibt jedoch drei Vorbehalte. Erstens startet diese Aktion intern powershell.exe – also Windows PowerShell 5.1.¹³ Skripte, die unter der Annahme von PowerShell 7 geschrieben wurden, laufen möglicherweise nicht unverändert. Zweitens gibt es eine Timeout-Einstellung (standardmäßig 10 Sekunden), sodass Sie beim Aufruf eines länger laufenden Batches diese explizit verlängern oder auf unbegrenzt setzen müssen.⁶ Drittens: Möchten Sie das unbeaufsichtigt nach Zeitplan ausführen, ist das Auslösen aus einem Cloud-Flow eine Premium-Funktion,⁴ und Sie benötigen zudem eine Lizenz für unbeaufsichtigte Ausführung sowie die Verwaltung des ausführenden Rechners. Ob es sich lohnt, extra zu bezahlen, um „nach Zeitplan in PAD statt in der Aufgabenplanung zu laufen“, verdient einen nüchternen Blick. Für ein Unternehmen, das bereits RPA (Bildschirmautomatisierung) in PAD mit vorhandener Ausführungsplattform betreibt, ist es eine Option; ansonsten genügt Muster a.

Muster c: Eine selbst gebaute API, die HTTP-Anfragen empfängt

Das bedeutet, einem Flow über den Trigger „Wenn eine HTTP-Anfrage empfangen wird“ eine URL zu geben und ihn aus PowerShell mit Invoke-RestMethod anzustoßen – oder umgekehrt intern eine kleine Web-API aufzubauen und sie aus einem Flow heraus aufzurufen. Dieser Trigger gehört zum Premium-Connector für HTTP-Anfrage/-Antwort.¹⁴ Es gibt zudem einen OAuth-Authentifizierungsmechanismus, mit dem sich Einschränkungen für den Aufrufer konfigurieren lassen (nur Benutzer innerhalb des Mandanten und Ähnliches).¹⁵

Es ist das flexibelste Muster mit hoher Echtzeit-Reaktionsfähigkeit und der Möglichkeit, Parameter zu übergeben – doch URL-Verwaltung, Authentifizierung und erneutes Senden bei Fehlern bedeuten, dass Sie sich unmittelbar im Bereich der Entwicklung bewegen. An diesem Punkt ist es nicht länger „Power Automate und PowerShell integrieren“, sondern ein kleines Systementwicklungsprojekt, sodass dies die Stufe ist, auf der Sie entscheiden, ob Sie es intern tragen oder das Design extern begutachten lassen.

Zusammengefasst: Beginnen Sie mit Muster a; verwenden Sie b, wenn Sie die PAD-Plattform bereits haben; und verwenden Sie c nur, wenn eine klare Echtzeitanforderung besteht. Lose gekoppeltes Design gilt allgemein für dateibasierte Integration, und die Etikette gegenseitigen Ausschlusses und der Übergabe wird ebenfalls in „Grundlagen des gegenseitigen Ausschlusses bei dateibasierter Integration - Best Practices für Dateisperren und atomare Beanspruchung“ behandelt.

7. Das Problem „niemand kann beides“

Bisher habe ich Entscheidungskriterien in technischen Begriffen beschrieben, doch was in der Praxis am Ende den Ausschlag gibt, ist „wer kann es warten“. Eine Person in der IT, die PowerShell schreiben kann, eine Person auf der Fachseite, die Power Automate anfassen kann, und niemand, der beides versteht. In kleinen und mittleren Unternehmen ist das normal.

Selbst für Verarbeitung, die technisch zu PowerShell passt, ist es also durchaus vernünftig, sich für Power Automate zu entscheiden, weil die Person, die es schreiben könnte, kurz vor dem Ausscheiden steht (oder umgekehrt). Wichtiger als die Vorzüge der Werkzeuge ist, ob es in fünf Jahren noch jemanden intern geben wird, der es reparieren kann. Die Entscheidungstabelle (Kapitel 3) ist „die optimale Antwort unter der Annahme, dass jemand es warten kann“ – und wo diese Person nicht existiert, biegen Sie die optimale Antwort auf die vorhandenen Menschen zu.

Darüber hinaus gibt es zwei Dinge, die Sie unabhängig vom Werkzeug tun sollten.

• Eine Bestandsaufnahme dessen erstellen, was existiert. Kombinieren Sie die Liste der Aufgabenplanungsaufgaben (auf welchem Rechner, zu welcher Zeit, was läuft, unter wessen Verwaltung) und die Liste der Power-Automate-Flows (Besitzer, Verbindungen, Zweck) in einem einzigen Register. Das Beängstigendste in einem Unternehmen, in dem zwei Familien nebeneinander existieren, ist, dass die eine für die andere unsichtbar ist.
• Dinge in übergabefähiger Form aufbewahren. Skripte gehören in Git, Aufgabendefinitionen in Registrierungsskripte,⁸ Flows in Mitbesitzer-Einstellungen und Exporte. Automatisierung ohne Spezifikationsdokument ist dasselbe wie die Massenproduktion von Miniaturversionen eines Systems ohne Quellcode und ohne Dokumentation. Das konkrete Übergabedesign auf der Flow-Seite ist im Artikel zur Personenabhängigkeit zusammengefasst.

8. Zusammenfassung

PowerShell + Aufgabenplanung und Power Automate sind keine konkurrierenden Werkzeuge; es sind getrennte Werkzeuge, deren Zuständigkeitsbereiche sich kaum überschneiden. Lokale Rechner, Server, Dateien und große Datenmengen gehören zu PowerShell; Daten, Benachrichtigungen und Genehmigungen auf Microsoft 365 gehören zu Power Automate. Diese Grundlinie bestimmt, wohin der Großteil der Automatisierung gehört.

Für Arbeit, die die Grenze überschreitet, ist es sowohl lizenzrechtlich als auch wartungstechnisch die vernünftige Wahl, die beiden nicht auf eine Seite zu zwingen, sondern sie mit loser Kopplung über eine in SharePoint abgelegte Datei zu verbinden. PowerShells Benachrichtigungsschmerz (das veraltete Send-MailMessage) und Power Automates Schmerz beim Erreichen lokaler Ressourcen (Gateways und RPA als Premium) werden jeweils direkt von der Stärke des anderen abgedeckt.

Und mit ebenso viel Gewicht wie die Wahl des Werkzeugs sollten Sie im Voraus entscheiden, wer es wartet und wo was läuft. Das Nebeneinander zweier Automatisierungsfamilien ist an sich gesund. Problematisch wird es nur, wenn sie ohne Ordnung vermischt werden. Ich nehme auch Anfragen auf der Stufe entgegen, auf der es heißt: „Wir möchten einen Gesamtüberblick über die Automatisierung im Unternehmen gewinnen“, oder: „Bitte beurteilen Sie von Fall zu Fall, in welchem Werkzeug wir bauen sollten.“

Verwandte Artikel

• Geschäftsprozesse mit Power Automate automatisieren ── Cloud-Flows, Desktop-Flows und robuste Fehlerbehandlung
• Wenn Aufgaben der Aufgabenplanung nicht laufen oder mit 0x1 enden ── die Ursache isolieren und für zuverlässigen Betrieb gestalten
• PowerShell-Skripte in der Praxis ── Protokollauswertung, Archivierung und Reporting sicher automatisieren
• Power-Automate-Lizenzierung und die Grenze zwischen Standard- und Premium-Connectoren
• Personenabhängigkeit bei Power Automate vermeiden ── Besitz, Verbindungen und Übergabe gestalten
• Geplante Flows in Power Automate gestalten ── Monatsabschluss, Werktagsprüfungen und Erinnerungen in der Praxis

Verwandte Beratungsbereiche

Die KomuraSoft LLC übernimmt alles von der Ordnung interner PowerShell-Batches bis zu Design-Reviews von Automatisierungsplattformen einschließlich Power Automate – einschließlich der Beurteilung, in welchem Werkzeug eine bestimmte Aufgabe gebaut werden sollte.

• Technische Beratung & Design-Review
• Windows-App-Entwicklung
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Sollte ich Automatisierung mit Power Automate oder mit PowerShell bauen?

Die Grundregel richtet sich danach, wo sich das Ziel befindet. Liegt das Ziel in der internen Windows-Umgebung – lokale Dateien, Freigabeordner, Server, Datenbanken, Betriebssystemvorgänge –, ist PowerShell + Aufgabenplanung meist stabiler und leichter zu warten. Liegt das Ziel bei Daten, Benachrichtigungen und Genehmigungen auf Microsoft 365 wie SharePoint, Outlook oder Teams, passt ein Power-Automate-Cloud-Flow besser. Es ist auch völlig praxistauglich, die eigentliche Verarbeitung von der Benachrichtigung zu trennen: die aufwendige Verarbeitung in PowerShell, Benachrichtigungen und Genehmigungen für Menschen in Power Automate.

Ist es schwierig, E-Mail- oder Teams-Benachrichtigungen aus PowerShell zu versenden?

Das traditionell verwendete Cmdlet Send-MailMessage ist offiziell als veraltet markiert, weil es keine sichere Verbindung zu einem SMTP-Server garantieren kann, und es gibt innerhalb von PowerShell keinen direkten Ersatz. Mit Send-MgUserMail aus dem Microsoft-Graph-PowerShell-SDK lässt sich zwar E-Mail versenden, das erfordert jedoch eine App-Registrierung und die Vergabe von Berechtigungen – eine ziemliche Hürde nur für eine Benachrichtigung. In der Praxis ist die einfachste Lösung, PowerShell nur bis zum Schreiben der Ergebnisse in eine Datei laufen zu lassen und Erkennung sowie Benachrichtigung Power Automate zu überlassen.

Kann Power Automate Dateien auf einem lokalen Freigabeordner verarbeiten?

Das kann es, aber damit ein Cloud-Flow Dateien im internen Netzwerk erreicht, benötigen Sie ein lokales Datengateway, und das Recht, ein Gateway zu nutzen, ist nicht in den mit Microsoft 365 gebündelten Power-Automate-Nutzungsrechten enthalten – es erfordert eine höherstufige Lizenz. Auch das Aufrufen eines Desktop-Flows (RPA) aus einem Cloud-Flow heraus ist eine Premium-Funktion. Möchten Sie zusätzliche Lizenzen vermeiden, ist der realistische erste Schritt, das Design entsprechend auszurichten: entweder die zu verarbeitenden Dateien nach SharePoint/OneDrive verlagern oder die Freigabeordner-Seite PowerShell + Aufgabenplanung überlassen.

Was ist der einfachste Weg, einen nächtlichen PowerShell-Batch mit Power Automate zu verbinden?

Ich empfehle lose Kopplung über Dateien. Ein unter der Aufgabenplanung laufendes PowerShell-Skript schreibt eine Ergebnis-CSV oder eine Zusammenfassungsdatei in eine SharePoint-Bibliothek, und die Power-Automate-Seite erkennt dies mit dem Trigger „Wenn eine Datei erstellt wird (nur Eigenschaften)“ und fährt mit Benachrichtigung oder Genehmigung fort. Keiner der beiden Mechanismen muss das Innere des anderen kennen, sodass sich bei einem Ausfall leicht isolieren lässt, auf welcher Seite das Problem liegt, und Sie können sogar unterschiedliche Personen für jede Seite zuständig machen. Sie können PowerShell auch direkt mit der Aktion „PowerShell-Skript ausführen“ in Power Automate for desktop aufrufen, das bringt jedoch zusätzliche Lizenzierungs- und Rechnerverwaltungsvoraussetzungen mit sich.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.