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

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 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 (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Rheinwerk Computing
ISBN 978-3-8362-1528-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

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.

23 Windows PowerShell

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 wirkt, als ellenlage Kommandos einzutippen.

In den letzten sechzehn 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-Scripts ablaufen zu lassen, ist, vorsichtig gesagt, 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 Enter -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 ist die PowerShell standardmäßig installiert und über ein Icon an einem wirklich hervorgehobenen Platz aufrufbar (Abbildung 23.1.

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.



Galileo 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. Auf 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 Funktionen entwickeln.

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


Galileo 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, basiert alles, wo »etwas passiert«, auf Cmdlets. Mithilfe des Cmdlets 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 bei diesem Kommando ebenfalls aufgeführt.

Die Benennung eines Cmdlets folgt einem vergleichsweise »sprechenden« Prinzip, nämlich 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 also 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 Paramenter -? 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 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 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 23.5 Es klappt – tatsächlich!

Zum Thema Cmdlets bleibt festzuhalten:

  • Cmdlets haben durchweg recht sprechende Namen und zwar nach dem Schema Verb-Subjekt, 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.

Galileo 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. Letzerer ist nun nicht nur länger, man wird es vermutlich aus purer Gewohnheit immer wieder mit dir probieren. Hier schlägt nun die Stunde der Aliasse: Wie Sie auf Abbildung 23.6 sehen können, steckt hinter dem Alias dir das Cmdlet Get-ChildItem. Die Aufrufparameter entsprechen also genau den »normalen« Parametern des Cmdlets.

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 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 diesen 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.


Galileo 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, 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 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, welche die Ausführung von eigenen (nicht signierten) Skripten unterstützt und dennoch die PowerShell-Umgebung möglichst »verschlossen« hält, ist RemoteSigned.

Um dies 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 23.8 Abfragen und Setzen der Ausführungsrichtlinie

Ob es jetzt die beste aller Ideen ist, die »Signatur-Pflicht« 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, halten 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 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 23.10 Das passiert, wenn ein signiertes Skript mutwillig modifiziert worden ist.

Der Sonderfall Profile.ps1

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

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

Sie können die Position 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 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, das ist 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, welche 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 23.12 Das passiert auch bei Profile.ps1-Dateien: Wenn keine Skriptausführung zugelassen ist, gibt’s eine Fehlermeldung.


Galileo Computing - Zum Seitenanfang

23.1.4 Pipelines topZur 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 wesentliches 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 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 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 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.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows Server 2012 R2






 Windows Server
 2012 R2


Zum Katalog: Office 365






 Office 365


Zum Katalog: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Vmware vSphere 5






 Vmware vSphere 5


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2010
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.


[Rheinwerk Computing]

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