Sinn und Zweck jedes Skriptes und jedes Programms ist die Automation einer Aufgabe. Einem Programmierer stehen zur Lösung meist mehrere Möglichkeiten aus mehreren "Automation Interfaces" zur Verfügung. Nehmen wir als Beispiel das Verschieben einer Datei von einem Ort zu einem anderen. Unter Powershell kann diese Automation realisiert werden:

     - natürlich über ein komfortables cmdlet namens move-item.

     - über .Net Klassen aus dem Namensraum System.IO wie File und FileInfo

     - über die COM-Klasse FileSysteminfo. COM ist nicht mehr ganz so präsent in der Powershell wie noch in VBS. Dennoch benötigt man diese Schnittstelle zum Steuern von
       Anwendungen, die nur über ein COM-Interface erreichbar  sind, wie MS Excel. 

     - auch WMI stellt eine Klasse Win32_Directory bereit, mit der Files und Ordner zumindest kopiert und gelöscht werden können. WMI ist schon etwas betagter hat aber den Vorteil,
       daß die WMI-Klassen wirklich sehr konsistent aufgebaut sind und es für viele Technologien ihre eigenen Klassen in eigenen Namespaces mitbringen ("root/virtualization, root/dns")

     - über dutzende freie und kostenpflichtige CommandlineTools wie copy, fcopy, xcopy, scopy, robocopy. Unter
       Powershell kann man solche Tools sehr schön einsetzen und deren Augaben weiterverwenden.

COM und WMI standen bereits in VBS zur Verfügung. Mit den cmdlets und damit .Net haben sich die Möglichkeiten für Skriptprogrammierer erheblich erweitert und vereinfacht.
Auf  .Net, COM und WMI möchte ich in diesem Kapitel relativ allgemein eingehen, auf WMI etwas genauer. 

.Net

Component Object Model

WMI

In vielen Beispielen der nachfolgenden Kapitel zu einzelnen Fachgebieten habe ich mehrere Lösungsvarianten verwendet. In diesem Kapitel und seinen Unterkapiteln geht es um mehr um die prinzipielle Vorstellung der Interfaces.


Neben den genannten Interfaces existieren noch etliche mehr, teilweise auch nur für bestimmte Aufgabenbereiche, wie den ADSI- und den WinNT-Provider für die Verwaltung von ActiveDirectory.
Weitere Interfaces sind beispielsweise ADO (ActiveX Data Object) und API (Application Programming Interface), die aber in der Powershell eher selten verwendet werden.

Es ist meines Erachtens wichtig zu verstehen, daß man erstens in der Powershell Werkzeuge aus verschiedenen Schubladen (Interfaces) holen und benutzen kann und diese zweitens in Powershell wunderbar kombinieren kann.