Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was ist .NET?
6 Installation
7 Die Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint Foundation und SharePoint Server
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Windows Server 2012 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2012 R2

Windows Server 2012 R2
Rheinwerk Computing
1392 S., 4., aktualisierte Auflage 2014, geb.
59,90 Euro, ISBN 978-3-8362-2013-2
Pfeil 23 Windows PowerShell
Pfeil 23.1 Ein paar Grundlagen
Pfeil 23.1.1 Cmdlets
Pfeil 23.1.2 Alias
Pfeil 23.1.3 Skripte
Pfeil 23.1.4 Pipelines
Pfeil 23.2 Die Entwicklungsumgebung
Pfeil 23.3 PowerShell-Fazit

23Windows PowerShell Zur nächsten Überschrift

Sondern so viel wir aus Städten erbeuteten, wurde geteilet;
Auch nicht ziemt es dem Volke, das einzelne wieder zu sammeln.
Aber entlass’ du jetzo dem Gotte sie; und wir Achaier
Wollen sie dreifach ersetzen und vierfach, wenn uns einmal Zeus
Gönnen wird, der Troer befestigte Stadt zu verwüsten.

Der erste »richtige« Windows Server, also Windows NT 3.1 Advanced Server, fiel unter anderem dadurch positiv auf, dass viele Verwaltungsaufgaben mit einer grafischen Benutzeroberfläche erledigt werden konnten. Das damals sehr populäre Netware 3.1 war nur über eine Textoberfläche mit hübscher Klötzchengrafik zu administrieren, und bei Unix-Betriebssystemen war hartes Kommandotippen angesagt. Windows-Administratoren wurde damals irgendwie eine geringere Kompetenz (»Mausschubser«, »Klicki-Klicki-Bunti-Kollege«) unterstellt, da das auf den ersten Blick irgendwie alles einfacher wirkte, als ellenlange Kommandos einzutippen.

In den letzten 16 Jahren (NT 3.1 Advanced Server erschien 1993) dürfte es sich herumgesprochen haben, dass Windows dermaßen komplex und vielfältig ist, dass die grafische Oberfläche beim Konfigurieren und Administrieren doch nicht alles von selbst macht, sondern man schon ein wenig Ahnung haben muss von dem, was man tut. Weiterhin wird wohl kaum jemand abstreiten, dass eine grafische Oberfläche diverse Vorteile hat, die so offensichtlich auf der Hand liegen, dass ich sie wohl nicht aufzählen muss.

Microsoft hat sich jahrelang auf die grafische Oberfläche als Schnittstelle zwischen seinen Produkten und dem Anwender konzentriert und die Kommandozeile weitgehend vernachlässigt:

  • Die Eingabeaufforderung befindet sich in etwa auf dem Intelligenzniveau von DOS 3.3 (erschien 1987).
  • Der Windows Script Host (WSH), der in der Lage ist, VB-Skripte ablaufen zu lassen, ist, vorsichtig ausgedrückt, auch nicht unbedingt der Höhepunkt aller verfügbaren Skripting-Umgebungen.

Trotz der grafischen Oberfläche hat Microsoft wohl einen gewissen Druck verspürt, sich der immens vernachlässigten Themen Kommandozeile und Skripting anzunehmen. Es gibt dabei ja durchaus etliche Vorteile:

  • Viele Aufgaben sind auf der Kommandozeile einfach schneller auszuführen als mit der grafischen Oberfläche, was diese beiden einfachen Beispiele zeigen:
    • Wenn man sich in der Dateistruktur gut auskennt, lässt sich die Datei c:\temp\inet\staging.aspx wesentlich schneller mit einem Kommandozeilenaufruf nach c:\inetpub\wwwroot\app2\default.aspx kopieren als mit dem Windows Explorer. Voraussetzung ist natürlich, dass die Eingabeaufforderung wenigstens ein bisschen intelligent ist und beispielsweise Verzeichnisse und Dateien beim Druck auf die ÿ-Taste auflisten kann.
    • Wenn Sie beispielsweise alle *.aspx-Dateien aus einem Verzeichnis oder einer Verzeichnisstruktur kopieren wollen, ist es deutlich einfacher, dies per Kommandozeile zu erledigen, als die Dateien mühsam im Windows Explorer herauszusuchen und zu kopieren.
  • Etliche Aufgaben erfordern mehr Arbeitsschritte als nur das Kopieren einer Datei. Hier sind kleine Skripte außerordentlich hilfreich. Gut, man könnte solche Aufgabensequenzen natürlich auch im Stil der SQL-Server-Wartungspläne als kleinen Workflow zusammenklicken. Wenn etwas komplexere Abhängigkeiten zu bearbeiten sind, geht es aber in letzter Konsequenz mit einer Art »kleinen Programmiersprache« deutlich einfacher.
  • Alle Aufgaben aus dem Bereich der Massendatenpflege sind per Kommandozeile einfacher zu formulieren. Ein kleines Beispiel: Ändern Sie im Active Directory beim Attribut Telefonnummer die Teilnehmernummer bei allen Benutzern am Standort Bonn. Wenn das 400 Benutzer sind, ist das mit dem grafischen Werkzeug Active Directory-Benutzer und -Computer schon eine ziemliche Strafarbeit. Mit einer einigermaßen intelligenten Befehlszeilenumgebung sollte sich das in einer Zeile formulieren lassen.
  • Die Technologien sind mittlerweile so umfangreich geworden, dass es annähernd unmöglich geworden ist, jede Einstellung über eine grafische Oberfläche zu administrieren. Das plakativste Beispiel ist der Exchange Server 2007. Bei diesem Serverprodukt sind viele Admins das erste Mal ernsthaft mit der PowerShell in Berührung gekommen, denn es gibt viele Einstellungen, die eben nicht über das grafische Konfigurationswerkzeug vorzunehmen sind, sondern nur über die PowerShell.
  • Schon seit geraumer Zeit lässt sich nicht mehr jede Aufgabe über die grafische Oberfläche lösen – Exchange Server 2007 ist da übrigens nur ein Beispiel. Wer etwa mit SharePoint vertraut ist, weiß, dass viele essenzielle Aufgaben mit dem Kommandozeilenwerkzeug stsadm.exe erledigt werden müssen. Es ist kein Problem, beliebige weitere Dinge zu finden, die nur per Texteingabe konfiguriert und administriert werden können. Es erscheint mir durchaus sehr wünschenswert, wenn die diversen Kommandozeilenanwendungen Schritt für Schritt unter das einheitliche Dach der PowerShell rutschen. Wie konsequent Microsoft dieses Ziel verfolgt, kann ich Ihnen natürlich nicht versprechen – die Vision ist aber da.

Egal ob Sie nun sowieso Kommandozeilenfan sind oder sich eher mit wenig Begeisterung an das Thema herantasten: Der routinierte Umgang mit der PowerShell dürfte zumindest mittelfristig unvermeidbar sein.

Einigermaßen bemerkenswert ist übrigens auch, dass sich in der Liste der Neuerungen diverse PowerShell-Erweiterungen finden – ein weiteres Indiz dafür, dass die Shell zunehmend wichtig wird.

Auf einem Windows Server 2008 (ohne R2) war die PowerShell übrigens ein Feature, das nachinstalliert werden musste. In der R2-Version war die PowerShell standardmäßig installiert und über ein Icon an einem wirklich hervorgehobenen Platz aufrufbar, bei Server 2012 und 2012 R2 ist sie natürlich ebenfalls dabei (Abbildung 23.1).

Abbildung

Abbildung 23.1 Im Windows Server 2008 R2 ist die PowerShell bereits installiert.

PowerShell

Die Windows PowerShell ist ein so umfassendes Thema, dass es mehrere wirklich umfangreiche Bücher darüber gibt. Dieses Kapitel hat nicht den Anspruch, die PowerShell ganzheitlich vorzustellen, vielmehr soll ein erster Eindruck vermittelt werden. Themen wie Skripting oder gar Programmierung müssen notwendigerweise der spezialisierten Literatur vorbehalten bleiben.


Rheinwerk Computing - Zum Seitenanfang

23.1 Ein paar Grundlagen Zur nächsten ÜberschriftZur vorigen Überschrift

Wie jede Umgebung lebt auch die PowerShell zunächst davon, dass es Kommandos gibt, die eingegeben werden können und dann eine Aktion ausführen. Mit dem Befehl Get-Command können die zur Verfügung stehenden Befehle angezeigt werden. In Abbildung 23.2 ist die Ausgabe gezeigt, auf der Sie drei Typen von Kommandos erkennen können:

  • Cmdlets: Dies sind kleine (oder auch weniger kleine) Funktionen, die quasi das Rückgrat der PowerShell bilden.
  • Aliasse: Ein Alias ruft ein Cmdlet auf. Aliasse setzen die wesentlichen (Windows-)Kommandozeilen- und Unix-Shell-Befehle auf PowerShell-Cmdlets um. So wird beispielsweise der allseits bekannte Befehl dir auf Get-ChildItem umgeleitet.
  • Functions: Funktionen sind eine »Kombination« von Cmdlets. Einige Funktionen sind bereits vorhanden, Sie können natürlich auch eigene entwickeln.

Abbildung

Abbildung 23.2 Mögliche Kommandos lassen sich mit »get-Command« aufrufen.


Rheinwerk Computing - Zum Seitenanfang

23.1.1 Cmdlets Zur nächsten ÜberschriftZur vorigen Überschrift

Cmdlets können diverse Aufgaben ausführen und sind letztendlich das Herzstück der PowerShell: Sie können Dateien kopieren, Objekte erzeugen, den Bildschirm löschen oder eine E-Mail versenden. Kurz gesagt, wenn »etwas passiert«, basiert alles auf Cmdlets. Mithilfe des Cmdlet get-Command -CommandType cmdlet lassen sich die standardmäßig vorhandenen Cmdlets abrufen – das ist schon eine ganz ansehnliche Menge. Wenn PowerShell-Erweiterungen, beispielsweise für Active Directory, installiert sind, werden sie mit diesem Kommando ebenfalls aufgeführt.

Die Benennung eines Cmdlet folgt einem vergleichsweise »sprechenden« Prinzip, dem Schema Verb-Substantiv, beispielsweise Send-MailMessage, Start-Service oder Clear-Host. Es lässt sich also relativ gut erkennen, was ein Cmdlet tatsächlich tut. Häufig gibt es korrespondierende Cmdlets, beispielsweise Get-Mailbox (um Informationen über eine Exchange-Mailbox zu erfragen) und Set-Mailbox (um Attribute zu ändern).

Cmdlets sind unter Umständen sehr komplex, nehmen also beispielsweise viele Parameter entgegen. Es ist daher wünschenswert, Informationen über ein Cmdlet erhalten zu können. Genau dies ist auch umgesetzt, wobei zwei Möglichkeiten zur Verfügung stehen:

  • Sie rufen das Cmdlet mit dem Parameter -? auf.
  • Sie rufen get-help NameDesCmdlets auf.

Abbildung 23.3 zeigt die zweite Variante. Sie sehen, dass die Erläuterungen schon einigermaßen hilfreich sind.

Abbildung

Abbildung 23.3 So können Sie die Hilfe zu einem Cmdlet abfragen.

Mit der PowerShell beziehungsweise den Standard-Cmdlets lassen sich interessante Dinge veranstalten, beispielsweise E-Mails verschicken. Gut, eine E-Mail per Kommandozeilenbefehl zu versenden, ist zwar für sich allein gesehen nicht so unbedingt das absolute Killer-Feature. In einem Skript ergibt es aber schon Sinn, bei erfolgreicher Abarbeitung oder einem Fehler eine Nachricht zu verschicken.

Auf Abbildung 23.4 ist zu sehen, wie eine E-Mail mit dem Befehl Send-MailMessage versendet wird. Zwei Aspekte sind wichtig:

  • Sie müssen die benötigten Parameter übergeben.
  • In diesem Fall muss eine Variable gesetzt werden, die den SMTP-Server spezifiziert.

Abbildung

Abbildung 23.4 Wird mit der PowerShell eine E-Mail gesendet, sieht das so aus.

Der Vollständigkeit halber möchte ich Ihnen das Ergebnis nicht vorenthalten: Abbildung 23.5 zeigt die E-Mail, die mit dem Cmdlet erzeugt wurde.

Abbildung

Abbildung 23.5 Es klappt – tatsächlich!

Zum Thema Cmdlets bleibt festzuhalten:

  • Cmdlets haben durchweg recht sprechende Namen, die dem Schema Verb-Substantiv folgen, also beispielsweise Send-MailMessage.
  • Cmdlets »tun etwas«, sie stellen sozusagen das funktionale Rückgrat der PowerShell dar.
  • Wenn für Applikationen oder Dienste »PowerShell-Module« mitgeliefert werden, handelt es sich dabei im Allgemeinen um zusätzliche Cmdlets.
  • Cmdlets können beliebig komplizierte Aktionen durchführen. Die notwendigen Parameter werden über Aufrufoptionen oder zu setzende Variablen übergeben.
  • Mit get-help cmdletname oder cmdletname -? kann die Hilfe zu einem Cmdlet aufgerufen werden.
  • Entwickler können eigene Cmdlets erstellen. Das SDK steht im Microsoft Download-Center zur Verfügung.

Rheinwerk Computing - Zum Seitenanfang

23.1.2 Alias Zur nächsten ÜberschriftZur vorigen Überschrift

Jeder PowerShell-Benutzer dürfte eine gewisse »Kommandozeilen-Vorgeschichte« haben. Entweder ist er ein alter Windows-Kommandozeilen-Hase, oder aber ihm sind die Unix-Kommandos in Fleisch und Blut übergegangen. Um zu schauen, welche Dateien in einem Verzeichnis liegen, sind wir es vermutlich alle gewohnt, dir oder ls einzutippen. Der entsprechende PowerShell-Befehl lautet Get-ChildItem. Letzterer ist nun nicht nur länger, man wird es vermutlich auch aus purer Gewohnheit immer wieder mit dir probieren. Hier schlägt nun die Stunde der Aliasse: Wie Sie in Abbildung 23.6 sehen können, steckt hinter dem Alias dir das Cmdlet Get-ChildItem. Die Aufrufparameter entsprechen also genau den »normalen« Parametern des Cmdlet.

Wenn Sie eigene Aliasse definieren wollen, um die Tipparbeit bei langen Cmdlet-Namen zu optimieren, ist das natürlich ebenfalls möglich. Um das Cmdlet mit dem etwas unhandlichen Namen Send-MailMessage als smm aufrufen zu können, geben Sie folgenden Befehl ein:

      Set-Alias smm Send-MailMessage
   

Abbildung

Abbildung 23.6 »dir« ist ein Alias für »Get-ChildItem«.

Das ist nicht weiter spektakulär und führt sofort zum gewünschten Ergebnis, hat aber einen Haken: Wird die PowerShell neu gestartet, ist der Alias weg.

Um einen Alias permanent zu speichern, können Sie den zuvor gezeigten Aufruf in der Skriptdatei profile.ps1 unterbringen. Da es auf einem System mehrere Dateien dieses Namens geben kann (und wird) und Aspekte wie die Signierung von Skripten ebenfalls zu berücksichtigen sind, verweise ich an dieser Stelle auf den nächsten Abschnitt, in dem es um Skripte geht.


Rheinwerk Computing - Zum Seitenanfang

23.1.3 Skripte Zur nächsten ÜberschriftZur vorigen Überschrift

Skripte sind bei allen Kommandozeilenumgebungen die Grundlage für die Automatisierung von Befehlsabläufen. Dies ist auch bei der PowerShell nicht anders, wobei hier zusätzlich einige Sicherheitsmechanismen eingebaut worden sind.

Allgemeines zu Skripten

Ein wirklich simples Skript, in dem lediglich zwei Eingaben aneinandergereiht sind, sehen Sie in Listing 23.1. Zunächst wird eine Variable gesetzt und dann ein Cmdlet aufgerufen.

$PSEmailServer="ubinfex2.ubinf.intra"
send-mailmessage -to ulrich@boddenberg.de -from powershell@ubinf.intra -subject "TestFromScript" -body "Das ist der Messagetext."

Listing 23.1 Ein einfaches PowerShell-Skript

Das Skript können Sie beispielsweise mit Notepad erstellen und mit der Dateiendung .ps1 abspeichern.

Nun können Sie die Skriptdatei ausführen – und werden eine Enttäuschung erleben (Abbildung 23.7). In der Fehlermeldung ist die Rede davon, dass die Ausführung von Skripten auf dem System deaktiviert ist.

Abbildung

Abbildung 23.7 Der Aufruf des Skripts führt nicht zum erhofften Ergebnis. Es erscheint lediglich eine Fehlermeldung.

Der Grund für diese Meldung ist, dass die PowerShell aus Sicherheitsgründen durchaus restriktiv mit Skripten umgeht. Die derzeitige Einstellung können Sie mit dem Befehl Get-ExecutionPolicy abrufen – standardmäßig ist Restricted eingetragen (Abbildung 23.8).

Die möglichen Werte für die Ausführungsrichtlinie sind:

  • Restricted: Eine Ausführung von Skripten und das Laden von Konfigurationsdateien ist nicht möglich (Standardeinstellung).
  • AllSigned: Sämtliche Skripte und Konfigurationsdateien müssen von einem vertrauenswürdigen Herausgeber signiert worden sein.
  • RemoteSigned: Aus dem Internet geladene Skripte und Konfigurationsdateien müssen signiert sein, lokal erstellte werden ohne Signatur ausgeführt.
  • Unrestricted: Alle Skripte und Konfigurationsdateien werden akzeptiert, allerdings wird vor der Ausführung von unsignierten aus dem Internet geladenen Dateien eine Warnmeldung angezeigt.
  • Bypass: Nichts wird blockiert, es erfolgen keine Warnungen.

Die Einstellung, die die Ausführung von eigenen (nicht signierten) Skripten unterstützt und dennoch die PowerShell-Umgebung möglichst »verschlossen« hält, ist RemoteSigned.

Um diese als aktive Ausführungsrichtlinie zu setzen, geben Sie einfach folgenden Befehl ein (Abbildung 23.8):

      Set-ExecutionPolicy RemoteSigned
   

Wenn Sie nun die Ausführung des Skripts nochmals initiieren, wird es funktionieren und (hoffentlich) brav seine Arbeit verrichten.

Abbildung

Abbildung 23.8 Abfragen und Setzen der Ausführungsrichtlinie

Ob es jetzt die beste aller Ideen ist, die »Signaturpflicht« für Skripte abzuschalten, darf natürlich bezweifelt werden. Durch die Signatur lässt sich immerhin verhindern, dass nicht vertrauenswürdige Skripte ausgeführt werden oder aber ursprünglich vertrauenswürdige Skripte unautorisiert verändert werden.

Wenn Sie sich fragen, wie eine signierte Skriptdatei aussieht, halte ich in Abbildung 23.9 die Antwort bereit: Unter dem eigentlichen Code befindet sich die Signatur. Wenn etwas geändert wurde, passt die bestehende Signatur nicht mehr.

Abbildung

Abbildung 23.9 So sieht eine signierte Skriptdatei aus.

Wird die PowerShell mit einer Ausführungsrichtlinie betrieben, die eine korrekte Signatur erfordert, führt ein Skript mit einer fehlerhaften Signatur zu einer Fehlermeldung und einem Abbruch der Ausführung (Abbildung 23.10).

Abbildung

Abbildung 23.10 Das passiert, wenn ein signiertes Skript mutwillig modifiziert worden ist.

Der Sonderfall Profile.ps1

In Abschnitt 22.1.2 habe ich Ihnen gezeigt, wie man einen eigenen Alias anlegen kann, allerdings gab es dabei das Problem, dass diese Einstellung nicht persistent ist.

Da es keine sinnvolle Option ist, bei jedem Start den Set-Alias-Befehl einzugeben, ist eine Automatisierungsmöglichkeit dringend erforderlich. Der Dreh- und Angelpunkt ist die Datei profiles.ps1, die an mehreren Stellen im Dateisystem liegen kann.

Sie können die Positionen der verschiedenen Dateien über den Variablennamen leicht selbst herausfinden (Abbildung 23.11). Die verschiedenen Varianten sind selbsterklärend:

  • $Profile
  • $Profile.CurrentUserCurrentHost
  • $Profile.CurrentUserAllHosts
  • $Profile.AllUserCurrentHost
  • $Profile.AllUserAllHosts

Abbildung

Abbildung 23.11 So lässt sich die Position der Profile-Dateien herausfinden.

Sie können also Ihren Alias-Befehl in die passende Profile.ps1-Datei eintragen, eine »ganz normale« Skriptdatei, die beim Start der PowerShell ausgeführt wird. »Ganz normal« ist übrigens auch das Verhalten, wenn in der PowerShell-Umgebung keine Skriptausführung zugelassen ist (Abbildung 23.12).

Merken Sie sich also die beiden folgenden Fakten:

  • Sie können beim Start einer PowerShell-Umgebung in verschiedenen Profile.ps1-Dateien beliebige Skripte ausführen, die die Umgebung vorbereiten.
  • Da dies normale Skriptdateien sind, gelten die üblichen Regeln für Skripte: Die Ausführung von Skripten muss generell gestattet sein, je nach Ausführungsrichtlinie muss die Datei signiert sein.

Abbildung

Abbildung 23.12 Das passiert auch bei Profile.ps1-Dateien: Wenn keine Skriptausführung zugelassen ist, gibt’s eine Fehlermeldung.


Rheinwerk Computing - Zum Seitenanfang

23.1.4 Pipelines Zur vorigen Überschrift

Eine der wesentlichen Eigenschaften der PowerShell ist die Möglichkeit, Pipelines zwischen Cmdlets zu verwenden. Das ist übrigens nicht nur eine »Randfunktion«, sondern ein wirklich zentrales Konzept, das sich in der Praxis sehr intensiv nutzen lässt.

Sie müssen sich zum Verstehen eigentlich nur folgende Skizze vorstellen:

Befehl1 >> Befehl2 >> Befehl3 >> Befehl4

In etwas ausführlicheren Worten heißt das:

  • Die Ausgabe von Befehl1 wird an Befehl2 übergeben.
  • Die Ausgabe von Befehl2 wird an Befehl3 übergeben.
  • Die Ausgabe von Befehl3 wird an Befehl4 übergeben.

Damit es nicht allzu theoretisch bleibt, gibt’s hier ein kleines praktisches Beispiel:

  • Der Befehl Get-ChildItem gibt die Objekte (in diesem Fall Dateien) des aktuellen Verzeichnisses aus.
  • Die Ausgabe des ersten Befehls wird beim Aufruf von Get-ChildItem|Remove-Item an den zweiten Befehl weitergeleitet.
  • Wie Sie sehen, klappt es: Es sind keine Elemente mehr vorhanden.

Abbildung

Abbildung 23.13 Arbeiten mit Pipelines

Auf diese Weise lassen sich (fast) beliebig komplexe Aktionen in einer Zeile ausdrücken.

Beliebt ist die Verwendung von Pipelines übrigens auch, um Ausgaben zu filtern. Mit dem einfachen dir der »normalen« Kommandozeile ist es schon nicht so trivial, herauszufinden, welche Dateien im aktuellen Verzeichnis größer als 10.000.000 Bytes sind. Die PowerShell-Vorgehensweise mit einer Pipeline funktioniert wie folgt:

  • Die Ausgabe aller Dateien wird mit dem Cmdlet Get-ChildItem initiiert.
  • Die Ergebnismenge wird an das WHERE-Objekt übergeben, in dem der entsprechende Filter definiert wird.

Abbildung

Abbildung 23.14 Die Antwort auf die Frage: »Welche Dateien sind größer als 10.000.000 Byte?«

Das beliebteste Beispiel in der Literatur ist das Filtern der Prozessliste – das möchte ich Ihnen natürlich auch nicht vorenthalten. Abbildung 23.15 zeigt, wie es gemacht wird und wie die Ausgabe aussieht. Natürlich könnten Sie noch einen dritten Befehl anhängen, der beispielsweise die Prozesse terminiert (in diesem Fall nicht empfehlenswert).

Abbildung

Abbildung 23.15 In allen Büchern zum Thema beliebt: Welche Prozesse wurden von einem Hersteller, dessen Name mit Microsoft beginnt, gestartet?

Bei der praktischen Arbeit gilt gerade für die Pipelines: »The sky is the limit.« Wenn Sie ein wenig Routine mit der PowerShell entwickelt haben, werden Sie das Feature lieben.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern


  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Windows Server 2012 R2






Windows Server 2012 R2
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Office 365






 Office 365


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Linux-Server






 Linux-Server


Zum Rheinwerk-Shop: Vmware vSphere 5






 Vmware vSphere 5


Zum Rheinwerk-Shop: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo