•  
  •  
Microsoft Windows PowerShell Modul Versions-Wirrwarr entwirrt

Microsoft Windows PowerShell Modul Versions-Wirrwarr entwirrt

Windows PowerShell kann durch so genannte Snapins oder durch Module, in der Funktionalität mit zusätzlichen Befehlen oder Providern erweitert werden.

Windows PowerShell Module

Dazu stellt Microsoft selbst, viele Module zur Verfügung.
Einige werden mit der Windows PowerShell selbst ausgeliefert und andere werden erst bei der Installation von Windows Features nachinstalliert. Es gibt auch Module die von der Version des Windows Betriebssystems abhängig sind.

Man kann auch Module oder Snapins von Drittanbieter Installieren. Dies ist aber nicht Gegenstand dieses Artikels. Dazu habe ich einen eigenen Artikel geschrieben.
Siehe hier: Windows PowerShell Module finden
http://www.powershell-group.eu/windows-powershell-module-finden/

Exkursion, Snapins:
Snapins sind eine veraltete Technik um die Windows PowerShell zu erweitern.
Snapins haben den Nachteilhaben, dass Sie mit Administrationsrechten Installiert werden müssen um sich in der Registry zu registrieren.
Deshalb sollte niemand mehr Snapins herstellen, sondern man sollte Module herstellen, die auch ein User durch einfaches Kopieren ‚Installieren‘ und nutzen kann.

Deshalb spreche ich im Folgenden nur allgemein von Modulen.

Ob ein Modul oder ein Snapin verfügbar ist, hängt von verschiedenen Faktoren ab.
Bei den Microsoft Modulen sieht man in der TechNet Dokumentation zu einem Modul, in welcher PowerShell Version oder in welchem Betriebssystem ein Modul vorhanden ist.
Leider habe ich keine Tabelle gefunden, die einen Überblick über alle Windows PowerShell Module von Microsoft gibt.

Microsoft legt fest, zu welcher Technik ein Modul gehört.

Microsoft Windows PowerShell Core Module

Die so genannten PowerShell-Core Module, sind an die Windows PowerShell gebunden und werden mit dieser ausgeliefert. Diese werden auch mit dem Windows Management Framework (WMF) installiert.
Eine Liste von den PowerShell-Core Modulen findet man z.B. hier:
Module Reference for Windows PowerShell version 4
http://technet.microsoft.com/en-us/library/hh847741.aspx

Die Tabelle die man dort findet, sagt leider nichts darüber aus, mit welcher Windows PowerShell Version ein Modul eingeführt wurde.
Das Core Modul „Microsoft.PowerShell.Core“ gibt es schon seit der Windows PowerShell Version 1.0. Dieses Modul wird jedoch immer mit der Windows PowerShell weiter entwickelt und hat nun den neuesten Stand von der PowerShell 4.0 und in Zukunft von der PowerShell 5.0 und so weiter.
Das Modul PSScheduledJob hingegen, wurde erst mit der Windows PowerShell Version 3.0 eingeführt.

Die PowerShell-Core Module sind also auch abhängig von der Installierten PowerShell Version!

Microsoft Windows Betriebssystem Module

Einige Module sind abhängig von der Version des Betriebssystems und sind deshalb keine PowerShell-Core Module. Diese Module gehören dann zum Windows Betriebssystem.
Das Modul zur Verwaltung von Windows Scheduled Task (Aufgabenplanung) z.B. ist erst ab den Betriebssystemen Windows 8.1 und Server 2012 R2 verfügbar.
Diese Module werden aus Technischen- oder Marketinggründen, meistens nicht für frühere Betriebssysteme nachträglich angeboten (kein downlevel support).

Feature oder Technik gebundene Microsoft PowerShell Module

Einige Module machen überhaupt erst mit einer bestimmten vorhandenen Technik Sinn.
Als Beispiele seien da die folgenden Module genannt:
ActiveDirectory für die Verwaltung des Active Directories, das SQLPS Modul um  den SQL Server zu verwalten.
Das Exchange Team z.B.  war einer der ersten, die ein Windows PowerShell Snapin extra zum Verwalten von Exchange entwickelt haben.

Microsoft hat mit der Common Engineering Criteria (CEC) eine Vorschrift, welche Features alle Server Teams in Ihre Produkte einbauen müssen.
Die Windows PowerShell steht in der CEC.
Somit haben auch SharePoint, Lync und viele andere Microsoft Server Produkte ihre eigenen Windows PowerShell Module.
Für CEC siehe: http://www.microsoft.com/cec/en/us/default.aspx

Diese Module sind meistens nur auf den Servern verfügbar, auf denen die entsprechende Technik installiert ist.
Deshalb kann man die PowerShell Module für diese Techniken meistens auch nur auf diesen Servern verwenden.

Möchte man diese (Server-) Module auch von einem Windows Clientbetriebssystem  aus benutzen, so kann man diese oft durch eine Technik benutzen die sich Implicit Remoting nennt.
Einen sehr guten Artikel über diese implizite Remoting hat Don Jones im TechNet Magazine veröffentlicht.
Windows PowerShell: Implicit Remoting
http://technet.microsoft.com/en-us/magazine/ff720181.aspx

Andere Techniken wie z.B. das ActiveDirectory Modul, kann man auch auf Windows Clients installieren.
Hierzu muss man die Remoteserver-Verwaltungstools (RSAT) Installieren und zusätzlich in der Windows Software Verwaltung als Feature Aktivieren.

Um z.B. Exchange von einem Windows Client aus zu verwalten kann man die Exchange-Verwaltungstools installieren oder man Verwaltet den Exchange Server über das Windows Remoting.
Auch hier gibt es ein historisch gewachsenes Versions-Wirrwarr, das ich nicht kenne, weil ich kein Exchange verwalte.

The following two tabs change content below.
Profile photo of Peter Kriegel

Peter Kriegel

IT Professionell, SysAdmin
Ich arbeite mit Computern seit 1984 (Comodore Amiga war mein erster). Seit dem Jahr 1990 Programmiere ich in C,C++ und Basic Sprachen. Seit dem Jahr 2000 bin ich Computer Administrator. In diesem Jahr habe ich die Prüfungen für den Microsoft Certified System Administrator MCSA 2000 absolviert. Als System Administrator benutze ich VBScript ,DOS Batches, Office VBA. Seit 2005 Programmiere ich mit Visual Basic .NET (VB.NET) (.NET V2). Dort entwickle ich Datenbank-Bedienungsoberflächen für den Microsoft SQL Server (GUI Frontend). PowerShell benutze ich seit 2009. In einem sehr großen Active Directory (> 100000 Workstations) verwalte ich (und meine 9 Kollegen) ca. 3000 Windows Clients, die in 37 OUs geordnet sind.

Kommentar verfassen