Jens_Mander

Es gibt wohl zwei Dinge beim Skripten die gerade am Anfang sehr stiefmütterlich behandelt werden.
Dokumentation Versionierung Dies liegt vor allem daran, dass man am Anfang des Skriptens viel Spaß am Experimentieren hat und bestimmt auch viel im Code springt oder ein paar Skripte parallel schreibt. Da kommt einem am Anfang gar nicht der Gedanke, dass man ja doch recht häufig speichert, aber immer unter dem gleichen Dateinamen. Vielleicht ab und zu mal eine -test oder eine-2 dranhängt. Aber mit einer ordentlichen Versionierung hat das eher nichts zu tun.

Dokumentation/Kommentierung

Bei mir hat sich bewährt, dass ich am Anfang eines Skriptes erst einmal als Kommentar das Ziel des Skriptes definiere. Dieser kann sich ja immer wieder verändern, aber später spart man sich auch diese Arbeit, wenn man das Skript einmal in andere Hände geben möchte, denn dann gehört so ein Text einfach dazu.
Wenn ihr Funktionen schreibt, dann sollten folgende Punkte aufgeführt sein:
SYNOPSIS Hier sollte in 1-2 Sätzen die Bestimmung der Funktion stehen DESCRIPTION Eine ausführlichere Beschreibung was diese Funktion macht PARAMETER param1 Beschreibung des param1 PARAMETER param2 Beschreibung des param2 Notes Zusätzliche Notizen LINK Zugehörige URLs Die erste URL wird aufgerufen wenn das CDMlet Get-Help -Online <Funktionsname> aufgerufen wird INPUTS Typen der Datenübergabe die erlaubt sind OUTPUTS Typen der Datenausgabe die von dieser Funktion ausgegeben werden können Funktionen benennen
Bei der Wahl des Funktionsnamens sollte man sich an die offizielle Nomenklatur halten. Das bedeutet, dass der Name mit einem Verb und einem Substantiv durch ein "-" getrennt aufgebaut sein sollte. Get-Verb gibt euch eine offizielle Liste der Verben und in welchem Kontext diese stehen.
Wenn ihr allerdings eine Funktion nur für euch schreibt die nur lokal eingesetzt wird, schreibt vor den Funktionsnamen "private:" oder „script:“
Versionierung
Beim Versionieren habe ich früher bei größeren Änderungen einfach den Versionszähler hochgesetzt und nebenbei eine Liste der Änderungen in einem Onenote Dokument gepflegt.
Ihr könnt natürlich auch die Änderungen in einem Textdokument oder direkt im Skript kommentieren.
Auch hier bieten die ISESteroids wieder eine sehr komfortable Lösung des Versionierens.
 

Der Pfeil im Bild zeigt euch, wie ihr den Reiter der Versionierung aufrufen könnt. Auf der rechten Seite seht ihr Die File Version History. Links ein Button „Ad New Version“ und auf der rechten Seite eine Checkbox „Auto Mode“. Wenn bei Auto Mode der Haken gesetzt ist, wird automatisch eine neue Version angelegt sobald man Änderungen durchgeführt hat und darauf folgend speichert.
In dem Reiter der einzelnen Versionen seht ihr links eine Klassifikationsmöglichkeit, wie zum Beispiel Stable, Alpha Release und weitere. Über den Knopf Compare öffnet sich das Programm WinMerge und zeigt die Veränderungen zur Vorgängerversion. Hier nutze ich den Button Notes um, wie der Name schon sagt, mir Notizen zu den Versionsunterschieden zu kommentieren.
 
Falls ihr noch Anregungen, Fragen oder Hinweise habt, gerne her damit.

Hallo Welt!
Nach einer längeren Zeit der Beitragsflaute mal wieder ein neuer Post. Dafür gibt es dieses mal auch etwas mehr und wieder einen Veranstaltungsbericht. Dieses mal jedoch nicht von einer Konferenz, sondern von einem Seminar mit anschließender Prüfung zur Zertifizierung.
Vom 05.07.2016 bis zum 07.07.2016 bin ich mit einem Kollegen in Köln auf einer prüfungsvorbereitenden Schulung zum Thema "Usability Engineering and User Experience" gewesen und habe dort einiges an Wissen erworben, das ich gerne auszugsweise(da sonst jeglichen Rahmen sprengend) mit euch teilen möchte.
Innovative Software braucht doch keine Kreativität "UX aus der Dose"
Im April 2016 habe ich mit zwei Kollegen die "OBJEKTspektrum information days" in Frankfurt am Main besucht und dort einen extrem interessanten Vortrag von einem mir recht sympathischen Sprecher gesehen.
In dem Vortrag mit dem provokanten Titel "Innovative Software braucht doch keine Kreativität – Ein Usability-Engineering How-to-Guide" beschrieb der Sprecher Herr Thomas Geis, wie man mithilfe der EN ISO 9241 und anderer Erkenntnisse aus dem Bereich "Entwicklung gebrauchstauglicher Produkte" mit rein methodischem Vorgehen sogenannte "Erfordernisse" an ein Produkt identifizieren kann, die unabhängig von bisherigen Lösungen oder Anforderungen oft exakt das beschreiben, was eigentlich vom Benutzer gewünscht wird.
Beispiel gefällig? Heizungsventile kennt ja so ziemlich jeder. Üblicherweise sind die irgendwie zum Drehen und haben von 0-5 eine Skala drauf, wobei man eigentlich nie weiß, welche Zahl welche Temperatur bedeutet.

< Ein beliebiges Standard-Thermostat
Ein Erfordernis an ein Heizungsventil oder eine "Heizeinrichtung" allgemein lautet jedoch eher so:
"Der Benutzer muss wissen, welchen Wert er eingeben muss um eine gewünschte Raumtemperatur zu erreichen."
Daraus ergibt sich, wenn man genau ist, nicht die Anforderung
"Der Benutzer muss am System an einem Drehregler einen Wert von 0-5 einstellen können", sondern eher etwas wie "Der Benutzer muss am System die gewünschte Zieltemperatur eingeben können."

Was passiert, wenn man so eine Anforderung konsequent zu einem sogenannten "interaktiven System" weiterentwickelt, sieht man beispielhaft hier. Das System ist bezüglich der Temperaturmessung im Raum zwar noch nicht zu 100% ausgereift, aber ein gefühlter Quantensprung an "Mehrkontrolle" gegenüber einem regulären Heizungsventil. Denn sind wir mal ehrlich, wer kennt die Situationen nicht, in denen man wie ein Verrückter zwischen "2.5" und "4.5" am Heizungsventil hin- und herdreht.
Noch spannender wird es, wenn man den Nutzungskontext einer "Heizung" genauer analysiert. Dann stellt man schnell fest, dass es nicht darum geht, eine "Zieltemperatur einzustellen", sondern dass es "angenehm temperiert ist". Analysiert man diesen Gedanken weiter, könnte es z.B. mit einem "Wearable Computer" verbinden um anhand der Körpertemperatur und der Entfernung zum Haus die Heizung so anzuschalten, dass die Wunschtemperatur immer automatisch gehalten wird. Fahre ich also weg, fährt die Heizung so weit herunter, dass sie, wenn ich jetzt umdrehen würde, bei der Ankunft zu Hause wieder auf der "Wohlfühltemperatur" steht. Boom! Innovation. Etwas, das als neu oder mit "Wow"-Effekt wahrgenommen wird, weil es bestehende Prozesse drastisch vereinfacht, verbessert oder einfach völlig anders löst als bisher bekannt.
Das Seminar - "Usability in a nutshell"
Angefixt von dem Talk auf der Konferenz haben mein Kollege und ich uns also ein gutes halbes Jahr später im Mietwagen nach Richtung Köln auf den Weg gemacht. Dadurch, dass der Talk auf der Konferenz so gut war, haben wir uns auch direkt dazu entschieden, das Training ebenfalls bei Herrn Geis von der Firma ProContext durchzuführen. Bevor jemand fragt, ich kassiere hier keine Provision, ich bin einfach wirklich begeistert von den Inhalten und der Art der Vermittlung.

"Human centered design process"
Nach dem Check-In im B&B-Hotel Köln/Messe und einem sehr geschmeidigen Abendessen in einem mexikanischen Restaurant ging es am nächsten Morgen ausgeschlafen und frisch gestärkt mit dem Zug Richtung Innenstadt zum Konferenzhotel direkt am Kölner Dom.
Tag 1 -  Usability-Basics
Bevor in tatsächliche Übungen eingestiegen werden konnte, gab es erstmal eine ordentliche Portion Theorie. Denn bei der Herstellung gebrauchstauglicher Produkte gibt es eine Menge Dinge, die einem begegnen können, die sehr präzise eingeordnet werden müssen, um sie richtig zu deuten. Die ISO-9241 und die Seminarinhalte vermitteln uns genau diese Sprache, diese Begriffe mit denen es möglich ist, solche Themen und diffusen Konzepte konkret zu benennen und damit zu arbeiten.

Programmübersicht Tag 1
Themen waren unter anderem "Erfordernisse", "Anforderungen" und was deren Unterschied ist. Ein Erfordernis z.B. ist oft unbewusst, ein sogenanntes "implied need" und muss systematisch im Nutzungskontext erhoben werden. Eine Anforderung wiederum befriedigt bei Erfüllung ein Erfordernis und basiert auf diesem. An 2 Beispielen möchte ich das kurz exemplarisch für andere erläuterte Begriffe darlegen. Alles ausführen kann und möchte ich hier nicht, das würde a) den Rahmen sprengen und müsste ich euch das vermutlich beim Lesen in Rechnung stellen.
Erfordernis
Syntax: Die <Benutzergruppe>, muss XXX wissen / verfügbar haben, um YYY entscheiden / tun zu können.
Es gibt also immer eine Voraussetzung und einen Zweck, die im Erfordernis festgehalten sind, welches wiederum im Nutzungskontext verankert sein muss.
Ein Beispiel für eine Vorrichtung zum Garen von Eiern:
Anforderung
Syntax: Der Benutzer muss am System ZZZ
erkennen/überblicken können auswählen können eingeben können Daraus ergäbe sich für unsere Garvorrichtung folgende beispielhafte Anforderung:
Wie diese Anforderung jetzt technisch umgesetzt wird, ist an dieser Stelle bewusst offen gehalten. Ob eine grafische Anzeige, eine Push-Mitteilung auf das Smartphone (IoT ist ja in aller Munde momentan), eine Melodie oder was auch immer das "Beste" ist, wird im Anschluss im Test überprüft.
Des weiteren wurden die 7 Dialogprinzipien und ihren Auswirkungen auf die Gestaltung von Nutzungsschnittstellen thematisiert.
Am Ende des ersten Workshop-Tages wurden gemeinsam in Übungen aus Nutzungskontextbeschreibungen Erfordernisse und aufbauend darauf Anforderungen her- bzw. abgeleitet. Interviews und Nutzerbeobachtungen spielen dabei im Vorfeld eine entscheidende Rolle.
Der Tag war also schon gefüllt mit ordentlich Inhalt, sowohl qualitativ als auch quantitativ. Und es zeichnete sich nicht ab, dass das weniger werden sollte. Im Gegenteil.
Um die Inhalte gebührend zu verarbeiten und Platz für Neues zu machen, gönnten wir uns mit einem Teil der Truppe nach einem Besuch des Weihnachtsmarktes am Kölner Dom gemeinsam im "Früh am Dom" noch das ein oder andere Kölsch.
Tag 2 - Entwickeln und Testen von UI/UX-Lösungen
Noch leicht schwammig im Kopf vom Kölsch ging es mit der Bahn zurück zum Hauptbahnhof und von da aus ins Schulungshotel.
Wenn Tag 1 den Fokus darauf legte, die Basis zu legen und Erfordernisse und Anforderungen zu sammeln, war der Hauptinhalt von Tag 2, zu erkunden, wie man dieses Wissen jetzt in ein Produkt, oder besser, einen Prototypen bzw. eine evaluierbare Geschäftsidee überführt.
Der oben schon verlinkte "Menschzentrierte Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme" war die Basis, auf der der zweite Tag basierte. 
Nachdem man Erfordernisse identifiziert und Anforderungen hergeleitet hat, ist der nächste Schritt im Prozess, eine Designlösung zur Evaluierung zu erarbeiten. Auf gut deutsch: "Einen Prototypen zum Testen bauen."
Dafür gibt es natürlich verschiedene Dinge, die man beachten muss. Ein paar Begriffe, Konzepte und Informationen, die dazu gehören, will ich hier exemplarisch auflisten.

Kippschalter - Benutzung offensichtlich
Affordance -Aufforderungscharakter Der Grad der Affordance beschreibt, wie sehr ein Element in einer Nutzungsschnittstelle zu seinem korrekten Gebrauch auffordert. Einem Schalter ist z.B. recht deutlich anzusehen, dass man ihn umlegen kann. Ich habe allerdings auch schon Dimmschalter gesehen, die man zum Anschalten nach unten "streicheln" musste und zum Abschalten bzw. dimmen nach oben. Aus Usability-Sicht ein ziemlicher Griff ins Klo.
Intuitiv
Im Usability-Sprech spricht man von Intuitivität, wenn die Benutzung eines interaktiven Systems unabhängig von der Erfahrung, vom Wissen, von den Sprachkenntnissen und dem momentanten Konzentrationsgrad des Benutzers unmittelbar verständlich ist.
Das heißt in der Praxis, dass ein Geldautomat dann intuitiv ist, wenn man ihn am Ballermann als 16-Jähriger, der zum zweiten mal in seinem Leben Geld abhebt, grade bierbedingt 2,5 Promille intus hat trotzdem bedienen kann. Obwohl der Automat grade in "Spanisch" eingestellt ist. Leichter gesagt als getan also.
Mentales Modell
Unter einem "Mentalen Modell" versteht man die Vorstellung, die ein Mensch von der Umgebung, den Menschen und Dingen hat, mit denen er interagiert. 

Wasserhahn mit klassischer "blau - kalt, rot - warm"-Färbung
Das Mentale Modell von einem Wasserhahn ist bei den meisten Menschen so konzipiert, dass es einen Griff zum Starten des Wasserflusses und einen Schieberegler zum Einstellen der Temperatur gibt. Das wäre das "Systemmodell". Ein Mensch, der zum ersten mal einen Wasserhahn mit Berührungssensor benutzen möchte, wird vermutlich Probleme damit haben, wenn er bis dahin noch keinen Kontakt zu dieser Technik hatte.
Ein paar Jahre vorher gab es z.B. noch nicht mal den stufenloser Schieberegler am Mischer. So musste man noch manuell heißes bzw. kaltes Wasser aufdrehen, bis man die gewünschte Zieltemperatur erreicht hat. Moderne Systeme bieten hier (zumindest in der Dusche) oft schon eine  auf den Regelmechanismus geätzte Temperaturskala an, die die Benutzung erleichtert. 
Wichtig ist für das mentale Modell jedoch diese Aussage.
Joel Spolsky, Gründer von Trello und Mitgründer von Stack Exchange, hat dazu vor 17 Jahren(!) einen Blogpost geschrieben, der immer noch Relevanz hat. 
Neben diesen Konzepten wurde den "7 Dialogprinzipien" an diesem Tag erneut verstärkt Zeit gewidmet. Dazu habe ich in meinem letzten Blogbeitrag aber schon ausführlich etwas geschrieben.
Ein weiteres Thema waren verschiedene Gestaltungsrichtlinien, sogenannte "Styleguides" oder "Design Patterns". Hierbei handelt es sich um Vorgaben, wie z.B. ein Button, eine Tabelle oder der gesamte Checkout Vorgang in einer Webseite (das wäre ein Design Pattern) aussehen sollte. Die meisten großen Hersteller von Software bieten so etwas übrigens an. Auf der Homepage unseres Trainingsanbieters findet ihr dazu einer super Übersicht.
Nach einer kurzen Exkursion zur Gestaltung verschiedener Prototypen (z.B. Papierskizze, Storyboard, Wireframe, etc.) ging es zum Ende hin dann zum großen Thema "Evaluierung der Designlösungen", also dem Test der Prototypen. Diesem Kapitel, das unter anderem Fokusgruppen, Benutzerbefragungen und Usability Tests beinhaltet, werde ich mich aber aufgrund des Umfangs in einem gesonderten Blogbeitrag widmen.
Wir schlossen den Tag mit einer Übersicht über die verschiedenen Rollen im Usability Engineering Prozess, ein paar Übungsaufgaben und einem prall gefüllten Kopf für den morgigen Prüfungstag.
Tag 3 - Prüfung zur Zertifizierung zum "UXQB® Certified Professional for Usability and User Experience – Foundation Level (CPUX-F)"
Den Vormittag und den ersten Teil des Nachmittags wendeten wir am Mittwoch zur Aufarbeitung der Inhalte zum Überprüfen der Gestaltungslösungen (also Usability Testing und co.) auf. 
Am Nachmittag wurde es dann spannend. Die Prüfung stand an. Dazu folgende Rahmenbedingungen.
40 Fragen Zum Bestehen müssen 28 von 40 Punkten erreicht werden (70%) 75 Minuten Keine Hilfsmittel erlaubt Jede Frage hat 6 Antwortmöglichkeiten, bei denen eine "signifikant richtiger" ist als die anderen Gibt es nur eine richtige Antwort, gibt es einen Punkt für eine richtige und null Punkte für eine falsche Antwort Manche Fragen haben 2 oder 3 "signifikant richtigere" Antworten, wenn dies der Fall ist, geht es aber aus der Aufgabe deutlich hervor Gibt es mehrere richtige Antwortmöglichkeiten, gibt es für jede richtige Antwort 1/AnzahlMöglichkeiten Punkte. Für jede falsche Antwort gibt es 1/AnzahlMöglichkeiten Punkte Abzug. Die Gesamtpunktzahl kann aber nie negativ sein. Die Fragen wurden, soweit ich das beurteilen kann allesamt durch die Übungen und Beispiele im Training im Vorfeld abgedeckt. So habe ich es dann auch geschafft, stolze 87,50% zu erreichen. Die Schwierigkeit der Fragen war allerdings stark gemischt. So gab es von relativ einfachen Fragen wie "Bei welchen der folgenden Begriffe handelt es sich um Dialogprinzipien?", wo die Lösung einfach aufgrund der Namen recht simpel war bis hin zu sehr schwierigen Fragen, wo mehrere Lösungen tatsächlich richtig waren, aber eine eben ein "Stückchen richtiger" als die anderen eine große Durchmischung. Da ging es z.B. um eine Fehlermeldung in Form eines Fehlercodes nach einer Datumseingabe in einer Webseite und einen Vorschlag zur Verbesserung. Gegeben waren von der ausführlicheren Fehlermeldung hin zum "Tutorial" verschiedene Möglichkeiten. Die richtige war jedoch, die Datumseingabe durch eine Datumsauswahl zu ersetzen, um Tippfehler, die erst validiert werden müssen überflüssig zu machen. So einfach kann's gehen.
Alles in allem machbar, aber knackig.
Fazit
Meiner Meinung nach waren das drei sehr gelungene Tage und wohl investiertes Geld. Geld heißt hier 1.500€ zzgl. MwSt. für das Training und 300€ zzgl. MwSt. für die Prüfung. Eine Rückerstattung bei Nicht Bestehen gibt es hier selbstverständlich nicht.
Obwohl die Möglichkeit besteht, sich extern auf die Prüfung vorzubereiten und die Unterlagen dafür im Internet frei verfügbar sind, halte ich ein vorbereitendes Training für sehr wertvoll, um das Wissen im Kontext richtig einordnen zu können. Darüberhinaus hat man durch den Kontakt mit anderen Teilnehmern die Möglichkeit, sich über Praxiswissen und echte Anwendungsfälle direkt austauschen zu können, was in der Gruppe sehr wichtig war.
Ich gucke heute noch regelmäßig in meine Schulungsmappe und das im Training bzw. für die Prüfung erworbene Seminar hilft mir tatsächlich, im Alltag bessere Entscheidungen zu treffen, wenn es um Produkt- oder Prozessgestaltung geht. Und da ist egal, ob es sich um digitale Produkte handelt oder "welche zum Anfassen".
Wenn ihr Fragen habt, zögert nicht, hier zu kommentieren oder mir zu schreiben.
Gruß, euer "devopsdad" Patrick

In diesem Beitrag soll es um die Powershell im Allgemeinen gehen und sich an Benutzer mit grundlegenden Skriptingkenntnissen wenden.
Meine Erfahrungen im Umgang und dem ein oder anderen Tool.
Ich bin ein Freund der Powershell geworden, da man mit dieser Scripting Engine viele sich wiederholende Aufgaben schnell und vor allem dann auch fehlerfrei immer wieder erledigen kann. Sei es ein Passwort nach bestimmten Kriterien automatisiert erstellen, dem AD Account hinzufügen, das Flag für "Bei der nächsten Anmeldung Passwort ändern" setzen und einen vorgefertigten Passwortbrief ausdrucken. Oder Gruppenmitgliedschaften zwischen zwei AD Accounts übertragen. Alles was über viel Klickerei zu erreichen ist, kann man durch die Powershell eleganter lösen.
Im Grunde genommen bin ich nun so weit, dass ich alles, was ich auf Dateiebene oder im Bereich AD oder Exchange mehr als zwei Mal mache, versuche in der Powershell zu lösen. Im besten Fall wiederhole ich irgendwann noch einmal die Tätigkeit, oder führe eine ähnliche aus und muss das Skript nur ein wenig anpassen, oder im schlechtesten Fall habe ich wieder ein wenig mehr Übung im Skripten und das hilft natürlich bei den kommenden Aufgaben.
 
Erstmal ein paar allgemeine Überlegungen
 
ISE - Integrated Scripting Environment oder nicht ISE (Konsole) - das ist hier die Frage
 
Es gibt für mich keinen Grund der Konsole den Vorzug zu geben.
Hier ein paar Gründe:
Kopieren und Einfügen Dies ist in der Konsole nur mit der Maus und nicht mit Tastaturbefehlen möglich Bei mehrzeiligen Befehlen werden der Prompt und der Zeilenumbruch mit kopiert Ich kann durch das Kopieren und Einfügen der gleichen Zeile untereinander mit anschließenden editieren der einzelnen Zeilen mehrere ähnliche Syntax erstellen und dann einzeln testen und somit gut experimentieren Wenn ich bemerke, dass eine lange gepipte Verkettung von Befehlen zu komplex wird, kann ich diese recht einfach wieder zerpflücken und in z.B. eine Funktion wandeln IntelliSense Autovervollständigen mit einem kleinen Fenster neben dem Cursor In der Konsole nur CMDlets und Parameter mit Tab durchschaltbar Einfärbung der Codeelemente erhöht die Übersichtlichkeit Tippfehler werden schneller erkannt Befehls Add-on Reiter Ermöglicht schnellere und einfache Erstellung eines CMDlets mit den benötigten Parametern  
Add-Ons
Ein sehr schönes CMDlet ist für die Arbeit im AD ist NTFSAccess.
https://blogs.technet.microsoft.com/heyscriptingguy/2014/11/22/weekend-scripter-use-powershell-to-get-add-and-remove-ntfs-permissions/
ist von The Scripting Guys
Bei den Downloads die man aus dem Internet lädt, müsst ihr daran denken, vor dem kopieren, ausführen etc. die Eigenschaften des Downloads aufzurufen und ganz unten im allgemeinen Reiter bei dem Punkt Sicherheit den Button "Zulassen" zu drücken.
Ein besonderes Bonbon sind die Powershell ISESteroids von Powertheshell.com
Eins vorweg, die ISESteroids sind nicht kostenlos. Preise findet ihr auf Dr. Tobias Weltners Webseite http://www.powertheshell.com/isesteroids2-2/ordering-isesteroids/
Dr. Tobias Weltner ist ein Experte aus dem Team von IT-Visions (Dr. Holger Schwichtenberg). Dr, Schwichtenberg ist durch zahlreiche Publikationen, auch rund um die Powershell, bekannt. Es lohnt sich auf jeden Fall eins seiner Bücher zur Hand zu haben, sobald man mit der Powershell anfängt zu Skripten.
Aber nun zurück zu den Steroiden.
Um diese immer beim Start zu laden, müssen diese in die Profildatei geladen werden. Diese findet ihr unter dem Userverzeichnis\Dokumente\WindowsPowershell. Hier ändere ich noch die Farbe der Fehleranzeige von dem Blau in Weiß, da dies generell besser lesbar ist. Das macht ihr mit dem Eintrag (get-host).PrivateData.errorbackgroundcolor = "White"
Oder, sofern ihr die Steroids mit start-steroids schon geladen habt über die neue Leiste aufrufen.

Was die Steroids für mich mittlerweile unverzichtbar machen sind
Gaaaanz wichtig Eine Versionierung Einen Simulationsmode - hier muss man nicht nach jeder ausführbaren Zeile ein -Whatif kommen Die Möglichkeit aus dem Skript eine eigenständig laufende EXE zu machen Der Variablen Explorer - Dieser zeigt alle verfügbaren Variablen und deren Inhalt an Win Merge File Compare - Ist im Zusammenarbeit mit der Versioncontrol einfach gut um Unterschiede in den Skripten zu finden PSShaper - Zeigt was in dem Skript nicht den "best practice" entspricht  
Schon während des Skriptens erscheinen zahlreiche Hinweise, wenn man dabei ist einen Bock zu schießen und geben einem Möglichkeiten vor es zu verbessern. Diese Möglichkeiten werden dann bei Wunsch auch direkt umgesetzt,
Wenn man eine Klammer, egal welcher Art auch immer öffnet, erscheint gleich auch das entsprechende Gegenstück. Wem ging es noch nie so, dass man später die Klammern zählt und sucht ;-)
Ein paar Zeilen Code geschrieben und dann gedacht...das wäre auch eine gute Funktion. Hier ist nach dem Markieren des Codes mit einem Rechtsklick sofort alles erledigt sobald man sich für einen Namen für die Funktion entschieden hat und welche Variablen als Parameter übergeben werden sollen.
Vorher

Nachher

Durch einen weiteren Klick auf einem Knopf wird diese Funktion in ein Modul geschrieben oder einem Modul hinzugefügt.
Dies nur mal als einen kleinen Appetizer. In den kommenden Blogeinträgen kommt zu den Steroids bestimmt noch mehr.

 

In diesem Beitrag soll es um die Powershell im Allgemeinen gehen und sich an Benutzer mit grundlegenden Skriptingkenntnissen wenden.
Meine Erfahrungen im Umgang und dem ein oder anderen Tool.
Ich bin ein Freund der Powershell geworden, da man mit dieser Scripting Engine viele sich wiederholende Aufgaben schnell und vor allem dann auch fehlerfrei immer wieder erledigen kann. Sei es ein Passwort nach bestimmten Kriterien automatisiert erstellen, dem AD Account hinzufügen, das Flag für "Bei der nächsten Anmeldung Passwort ändern" setzen und einen vorgefertigten Passwortbrief ausdrucken. Oder Gruppenmitgliedschaften zwischen zwei AD Accounts übertragen. Alles was über viel Klickerei zu erreichen ist, kann man durch die Powershell eleganter lösen.
Im Grunde genommen bin ich nun so weit, dass ich alles, was ich auf Dateiebene oder im Bereich AD oder Exchange mehr als zwei Mal mache, versuche in der Powershell zu lösen. Im besten Fall wiederhole ich irgendwann noch einmal die Tätigkeit, oder führe eine ähnliche aus und muss das Skript nur ein wenig anpassen, oder im schlechtesten Fall habe ich wieder ein wenig mehr Übung im Skripten und das hilft natürlich bei den kommenden Aufgaben.
 
Erstmal ein paar allgemeine Überlegungen
 
ISE - Integrated Scripting Environment oder nicht ISE (Konsole) - das ist hier die Frage
 
Es gibt für mich keinen Grund der Konsole den Vorzug zu geben.
Hier ein paar Gründe:
Kopieren und Einfügen Dies ist in der Konsole nur mit der Maus und nicht mit Tastaturbefehlen möglich Bei mehrzeiligen Befehlen werden der Prompt und der Zeilenumbruch mit kopiert Ich kann durch das Kopieren und Einfügen der gleichen Zeile untereinander mit anschließenden editieren der einzelnen Zeilen mehrere ähnliche Syntax erstellen und dann einzeln testen und somit gut experimentieren Wenn ich bemerke, dass eine lange gepipte Verkettung von Befehlen zu komplex wird, kann ich diese recht einfach wieder zerpflücken und in z.B. eine Funktion wandeln IntelliSense Autovervollständigen mit einem kleinen Fenster neben dem Cursor In der Konsole nur CMDlets und Parameter mit Tab durchschaltbar Einfärbung der Codeelemente erhöht die Übersichtlichkeit Tippfehler werden schneller erkannt Befehls Add-on Reiter Ermöglicht schnellere und einfache Erstellung eines CMDlets mit den benötigten Parametern  
Add-Ons
Ein sehr schönes CMDlet ist für die Arbeit im AD ist NTFSAccess.
https://blogs.technet.microsoft.com/heyscriptingguy/2014/11/22/weekend-scripter-use-powershell-to-get-add-and-remove-ntfs-permissions/
ist von The Scripting Guys
Bei den Downloads die man aus dem Internet lädt, müsst ihr daran denken, vor dem kopieren, ausführen etc. die Eigenschaften des Downloads aufzurufen und ganz unten im allgemeinen Reiter bei dem Punkt Sicherheit den Button "Zulassen" zu drücken.
Ein besonderes Bonbon sind die Powershell ISESteroids von Powertheshell.com
Eins vorweg, die ISESteroids sind nicht kostenlos. Preise findet ihr auf Dr. Tobias Weltners Webseite http://www.powertheshell.com/isesteroids2-2/ordering-isesteroids/
Dr. Tobias Weltner ist ein Experte aus dem Team von IT-Visions (Dr. Holger Schwichtenberg). Dr, Schwichtenberg ist durch zahlreiche Publikationen, auch rund um die Powershell, bekannt. Es lohnt sich auf jeden Fall eins seiner Bücher zur Hand zu haben, sobald man mit der Powershell anfängt zu Skripten.
Aber nun zurück zu den Steroiden.
Um diese immer beim Start zu laden, müssen diese in die Profildatei geladen werden. Diese findet ihr unter dem Userverzeichnis\Dokumente\WindowsPowershell. Hier ändere ich noch die Farbe der Fehleranzeige von dem Blau in Weiß, da dies generell besser lesbar ist. Das macht ihr mit dem Eintrag (get-host).PrivateData.errorbackgroundcolor = "White"
Oder, sofern ihr die Steroids mit start-steroids schon geladen habt über die neue Leiste aufrufen.

Was die Steroids für mich mittlerweile unverzichtbar machen sind
Gaaaanz wichtig Eine Versionierung Einen Simulationsmode - hier muss man nicht nach jeder ausführbaren Zeile ein -Whatif kommen Die Möglichkeit aus dem Skript eine eigenständig laufende EXE zu machen Der Variablen Explorer - Dieser zeigt alle verfügbaren Variablen und deren Inhalt an Win Merge File Compare - Ist im Zusammenarbeit mit der Versioncontrol einfach gut um Unterschiede in den Skripten zu finden PSShaper - Zeigt was in dem Skript nicht den "best practice" entspricht  
Schon während des Skriptens erscheinen zahlreiche Hinweise, wenn man dabei ist einen Bock zu schießen und geben einem Möglichkeiten vor es zu verbessern. Diese Möglichkeiten werden dann bei Wunsch auch direkt umgesetzt,
Wenn man eine Klammer, egal welcher Art auch immer öffnet, erscheint gleich auch das entsprechende Gegenstück. Wem ging es noch nie so, dass man später die Klammern zählt und sucht ;-)
Ein paar Zeilen Code geschrieben und dann gedacht...das wäre auch eine gute Funktion. Hier ist nach dem Markieren des Codes mit einem Rechtsklick sofort alles erledigt sobald man sich für einen Namen für die Funktion entschieden hat und welche Variablen als Parameter übergeben werden sollen.
Vorher

Nachher

Durch einen weiteren Klick auf einem Knopf wird diese Funktion in ein Modul geschrieben oder einem Modul hinzugefügt.
Dies nur mal als einen kleinen Appetizer. In den kommenden Blogeinträgen kommt zu den Steroids bestimmt noch mehr.