Microsoft stellt die PowerShell unter die liberale Lizenz Community Promise, die beispielsweise auch für die Common Language Infrastructure von .NET gilt. Sie erlaubt es nun jedem, PowerShell auf beliebige Betriebssysteme zu portieren, ohne dafür einen Vertrag mit Microsoft abschließen oder patentrechtliche Konsequenzen fürchten zu müssen.
Während der Batch-Prozessor früher mit Hilfe von syntaktischen Tricks gerade einmal die Gleichheit eines Kommandozeilenarguments mit einem bestimmten Wert feststellen konnte, ist er heute immerhin zu allen Vergleichsoperationen fähig. Auch wenn er damit insgesamt noch weit von den Möglichkeiten einer Unix- oder Powershell entfernt ist, erschließen die Operatoren doch einige Einsatzgebiete für Batch-Dateien.
Moderne IT-Umgebungen sind hochgradig verteilt und dynamisch, mit Anwendungen in privaten und öffentlichen Clouds. Hinzu kommen hybride Arbeitsmodelle mit Usern an wechselnden Standorten. Für einen optimalen Netzwerkbetrieb sollten Unternehmen daher vom herkömmlichen Monitoring zu einer Observability-Plattform wechseln.
Es gibt Gelegenheiten, da möchte man eine Batch-Datei nicht im Kontext des aktuellen Verzeichnisses laufen lassen, sondern dort, wo sie abgelegt wurde. Gründe dafür könnten etwa sein, dass man die Stapeldatei als Administrator startet und nicht will, dass sie in \windows\system32 operiert. Oder sie muss zur Laufzeit eine bestimmte Datei auslesen, die im gleichen Verzeichnis liegt.
Grundlegende Kenntnisse über den Aufruf der PowerShell selbst, von Befehlen und Scripts bleiben sehr theoretischer Natur, wenn man nicht weiß, was man eigentlich an Cmdlets zur Verfügung hat, was diese leisten können und welche Parameter sie akzeptieren. Die Auswahl hängt konkret davon ab, welche Module geladen sind; so gibt es etwa im Startmenü von Domänen-Controllern einen PowerShell-Link, der die Active-Directory-Module gleich beim Start lädt und so Cmdlets für die AD-Verwaltung zur Verfügung stellt.