Fast jeder Kommandointerpreter bietet die Möglichkeit, gleich beim Start eine vom Benutzer gewünschte Konfiguration zu laden und sich somit an individuelle Vorgaben anzupassen. Das gilt auch für die PowerShell, die gleich mehrere Profildateien ausliest, um Einstellungen für verschiedene Geltungsbereiche zu übernehmen. Zulässig ist praktisch alles, was die PowerShell ausführen kann.

Statt auf Dauer am veralteten Konzept von cmd.exe und Batch-Dateien herumzudoktern, hat Microsoft mit der PowerShell einen Nachfolger für den alten Kommandointerpreter und seine Scripting-Technik entwickelt. Während aber praktisch alle Admins die Mittel der alten Kommandozeile in ihrer täglichen Arbeit nutzen, ist das Wissen über die PowerShell noch nicht so verbreitet.

Microsoft startete TechNet Gallery, ein Community-Portal für Scripts und Tools, die durchwegs kostenlos heruntergeladen werden können. Da es sich um eine Weiterentwicklung des TechNet Script Center handelt, enthält es bereits eine Vielzahl von Ressourcen. Die Gallery fügt diesen noch anwendungsspezifische Tools hinzu, unter anderem für App-V und die System-Center-Produkte.

Während Powershell 2.0 zum Lieferumfang von Windows 7 und Server 2008 R2 gehört, muss man sie in älteren Versionen des Betriebssystems nachträglich installieren und konfigurieren. Die Anpassungen betreffen vor allem die gegenüber PowerShell 1.0 stark erweiterten Remoting-Funktionen, die mit dem Parameter -computer eine Ausführung zahlreicher Cmdlets auf entfernten Rechnern ermöglichen.

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.

Es ist bei Microsoft üblich, zu neu eingeführten Windows-Server-Funktionen neben der Möglichkeit der Bedienung per GUI auch immer die entsprechenden PowerShell-Cmdlets zu liefern. Damit kann man etwa die entsprechenden Funktionen auch auf Server Core ausführen. Dies trifft auch auf den Best Practices Analyzer zu: Die dazugehörigen Cmdlets erlauben seine komplette Verwendung in einer PowerShell-Umgebung.

Um PowerShell-Befehle oder Cmdlets auszuführen, muss man zuvor nicht unbedingt ein Fenster des PowerShell-Interpreters öffnen. Man kann dem Befehl powershell.exe nach dem Parameter -Command auch direkt Kommandos übergeben, die daraufhin ausgeführt werden, wonach sich der Interpreter selbsttätig wieder beendet. Verwendbar ist diese Vorgehensweise etwa per Start → Ausführen, aus einer cmd.exe-Eingabeaufforderung heraus oder im Taskplaner.

In der Vorein­stellung ist Power­Shell kompr­omiss­los auf Sicher­heit getrimmt: Man kann generell keine Scripts ausführen, nur die Shell interaktiv benutzen. Damit soll ver­hindert werden, dass Schad­code ausge­führt und ein Computer oder Benutzer­konto dadurch kompro­mittiert wird.

Viele PowerShell-Cmdlets funktionieren nicht nur auf dem lokalen Rechner, sondern auch remote auf entfernten PCs. Dabei gibt es zwei Arten: Ein Teil der Cmdlets benötigt PowerShell-Remoting, das heißt der entfernte Rechner muss für das Ausführen von PowerShell-Remotebefehlen konfiguriert sein.

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.