Visual Studio Code Shortcut zwischen Terminal und Editor wechseln

Seit einiger Zeit beschäftige ich mich auch mit dem mächtigen VSCode Editor. Aus der ISE bin ich es gewohnt schnell zwischen Konsole und Editor zu wechseln, was in VSCode nicht so einfach war. 01_open_shortcutsNach einiger Zeit habe ich dann die entsprechenden Konfigurationspunkte gefunden.

 

 

 

 

 

 

02_display_shortcuts

In dem oberen Textfeld kann bequem nach Stichwörtern oder anderen Aktionen gefiltert werden (1). So kann auch dasTastenkürzel durch die Auswahl des Stiftes bearbeitet werden (2 u. 3). Müssen weiteren Befehle hinzugefügt werden, dann kann dies mithilfe der dazugehörigen json – Datei geschehen (4).

03_search_shortcuts_openjson  Die Tastenzuordnung erfolgt nach einem einfachen Schema und mit dem Schlüsselwort “when” können Abhängigkeiten definiert werden.

04_json_anpassen

Veröffentlicht unter Allgemein, Grundlage, Nice To Know, PowerShell, Scripting | Verschlagwortet mit , , , , , , , , , , , | Hinterlasse einen Kommentar

Debugging in PowerShell Studio 2017 – etwas mehr

Nachdem in meinem letzten Beitrag das Grundlegende Debugging mit dem PowerShell Studio 2017 gezeigt wurde, geht es diesmal um die weiteren Funktionen die PowerShell Studio im Bereich Debugging mit sich bringt. Im Breakpoint Menü befindet sich der “Edit Breakpoint” Menüpunkt, dieses Fenster beinhaltet alle gesetzten Haltepunkte, bzw. abhängige Haltepunkte. Eine praktische Übersicht und auch super um die Nachfolgenden Haltepunkte zu definieren.

breakpoint menu

 EditBPMenu

Variable Breakpoints

Bei der Auswahl von “Set Variable Breakpoint” öffnet sich ein Fenster bei dem es die Möglichkeit gibt Haltepunkte anhand von Variablen zu definieren. Dabei kann die entsprechende Variable ausgewählt werden und ob bei schreiben, lesen oder beiden Aktionen in den Debug Modus gewechselt werden soll.

Setvariablepreakpointvariablesetvariablebreakpointwriteread

Function Breakpoints

Bei “Set Function Breakpoint” öffnet sich auch ein Fenster in dem Funktionen als Haltepunkte definiert werden können. Das bedeutet, immer wenn diese Funktion aufgerufen wird, stoppt das Skript und wechselt in den Debugger. Im Auswahlfeld sind die im Skript selbst geschriebenen Funktionen zu finden. Es ist aber auch möglich andere Cmdlets anzugeben, welche zum Beispiel innerhalb von Funktionen aufgerufen werden. Eine praktische Sache, wenn Parameter überprüft werden müssen, welche übergeben werden.

setfunctionbreakpoint2 setfunctionbreakpoint1

Conditional Breakpoints

Am spannendsten finde ich jedoch die Conditional Breakpoints (Bedingten Haltepunkte). In den Fenstern zum Erstellen von Variable-, Function – Breakpoints gibt es auch den Action Bereich. In diesem Feld kann definiert werden, was bei dem Aufruf der Funktion, oder dem schreiben/Lesen der Variable ausgeführt werden soll. So können Logeinträge verfasst werden oder Bestimmte Ausgabetexte. Das Skript wechselt dabei nicht in den Debug-Modus sondern führt die Aktion aus. Wie kann man sich dies zu Nutze machen?

 

Meine Funktion ist recht einfach, beschreibt das Verhalten aber sehr gut. Ich möchte, dass es zu einem Stopp kommt, wenn in die Variable $txt geschrieben wird und $number den Wert 5 hat. Es muss also ein Variablen Haltepunkt auf die Variable $txt gesetzt werden. Immer wenn in die Variable geschrieben wird, soll geprüft werden ob $number = 5 ist. Mit dem Set Variable Breakpoint Kontext ist dies ein Kinderspiel.

conditionalBP1conditionalBP2conditionalBP3

Sollen nun 100 Server verarbeitet werden und bei dem 80 treten Probleme aus, muss man nicht 80-mal F5 drücken, sondern definiert so einen Bedingten Haltepunkt. Eine sehr coole Sache wie ich finde.

Euch Viel Spaß mit den Debug Möglichkeiten in PowerShell Studio

Veröffentlicht unter Grundlage, PowerShell Studio, Scripting | Verschlagwortet mit , , , , | Hinterlasse einen Kommentar

PowerShell Studio 2017 – Grundlagen Debugging

Debugging ist eines der wichtigsten Dinge, egal in welchen Editor gearbeitet wird. PowerShell Studio liefert hier einen großen Funktionsumfang.

zum Layout

In den Layouts die mitgeliefert werden ist eine Debug-Ansicht vorhanden, mir persönlich gefällt diese nicht, da sie nicht übersichtlich genug ist.

menu_layoutdebug_layout

Fast alle arbeiten mit mehr als einem Bildschirm und wenn ich intensiv mit Powershell Studio skripte entwickel, dann ist der Zweitbildschirm mit all mein Debug-Fenstern versehen.

own_debug_layout

INFO
Das Automatische Anpassen von Layouts kann man unter File -> Options -> Panels festlegen.

Zu den meist verwendeten Fenstern gehören sicherlich die Debug Console und das Variablen Fenster.

Beispiel

Das einfache Beispiel zeigt das rudimentäre Debuggen von Skripten.
Mit der Taste F9 können einfach Haltepunkte (Breakpoints) gesetzt werden, weiter Möglichkeiten zeigt das Untermenü Breakpoint im Reiter Run. Hier können auch alle Haltepunkte in einem Skript angezeigt werden, bei einem Komplexen Projekt ist das sehr hilfreich.

 

breakpoint_menu

set_breakpoint

Auch in PowerShell Studio startet der Debug Modus mit F5 oder durch das Debug Menü im Run Bereich. debug_button Wie zu erwarten sind auch die Laufzeitvariablen in dem Variablen Fenster zu finden und können untersucht werden. Auch lassen sich über die Debug Console wie gewohnt Befehle ausführen.

variablen_debug

So einfach ist es bestimmte Teile in seinem Skript besser zu Untersuchen. Dabei gibt es noch eine Menge weiterer Möglichkeiten, wie das Debuggen mehrerer Dateien oder Haltepunkte bei bestimmten Wert einer Variable und viele weitere.

Zum Beitrag

Veröffentlicht unter Allgemein, Grundlage, PowerShell Studio | 1 Kommentar

Sicherheitsberechtigungen von AD-Objekten kopieren

Ab und an kommt es vor, dass die Sicherheitsbestimmungen von Gruppen oder anderen AD-Objekten angepasst werden müssen. Für ein einzelnes Objekt mag das gehen, aber wenn dies für sehr viele umgesetzt werden muss, macht das per Hand keinen Spaß.

Am einfachsten ist es ein AD-Objekt so zu konfigurieren und diese Einstellungen dann zu kopieren. In diesem Beispiel soll die Kennung ‚sorglossu’ Ändern-Rechte auf Gruppen bekommen.

  1. Muster Berechtigungen erstellen
  2. Mithilfe von PowerShell die Berechtigungen auslesen

    Um den Active Directory Informationsspeicher auslesen zu können, muss der AD Provider bereitgestellt werden. Erst durch das laden des Active Directory Modules steht dieser zu Verfügung.

     

    Dadurch das die Informationen wie ein Laufwerk dargestellt werden, ist es möglich die bekannten Befehle darauf anzuwenden, wie eben Get-ACL.

     

    Mit einem kurzen Filter wird die gewünschte Berechtigung angezeigt.

     

    access_susisorglos_01

  3. Setzen der Berechtigungen auf andere AD-Objekte

    Nachdem die gewünschte ACL gefunden wurde, geht es daran diese auf andere Objekte anzuwenden. Vorher müssen noch ein paar Information ausgelesen werden

    Für die eindeutige Zuweisung wird die SID der Gruppe oder des Nutzers benötigt.

    access_susisorglos_02

    Weiterhin wird die ObjectTypeID der zu kopierenden ACL benötigt, welche durch das auslesen der ACL schon zu Verfügung steht. In dem Zusammenhang werden gleich die Berechtigungen mit gespeichert.

    Um die ACL zu erstellen, muss auf die Klasse ActiveDirectoryAccessRule zurückgegriffen werden. Mit dem folgenden Befehl, können sich die verschiedenen Überladungen angezeigt werden.

    ueberladungen

    Dann kann auch schon das ACL Objekt erstellt werden.

Info: Das Objekt $acl kann am jedes beliebige AD Object gebunden werden, was die Berechtigungen erhalten soll.

set_acl_01

Das Objekt mit den Zugriffsbrechtigungen muss nur noch der zuvor ausgelesen ACL hinzugefügt und dem Objekt (hier Gruppe BE_Hotline) gesetzt werden.

set_acl_02

test_acl_gui_01 test_acl_gui_02

4. Übersicht

 

Genauere Infos und ein weiteres Beispiel gibt es unter dem Link, der auch mir als Quelle für diesen Blog diente.

Wer das ganze als parametrisierte Funktion und der Möglichkeit mehrere Ziele anzupassen, findet das ganze Skript in der PS-Gallery :

https://gallery.technet.microsoft.com/Active-Directory-d53b8de2

 

Veröffentlicht unter Active Directory, PowerShell, Scripting | Verschlagwortet mit , , , , , | Hinterlasse einen Kommentar

Azure Datenbank anlegen und mit PowerShell oder Visual Code bearbeiten.

Wer Zugang zu einem SQL Server hat, sollte diesen auch nutzen. Bei der Arbeit mit PowerShell werden oft Listen oder Tabellen genutzt. Diese Informationen werden nicht selten in csv Dokumenten gespeichert. Mich stört daran, dass solche Tabellen nicht weniger werden und der Inhalt manchmal mehrere Hundert Einträge fasst. Wenn diese Dateien weg sind, hat man ein Problem. Mit einer Datenbank hat man wesentlich mehr Vorteile und meist braucht man sich um die Verfügbarkeit keine Gedanken machen. Noch weniger Gedanken um die Verfügbarkeit muss man sich machen, wenn die Datenbank in Azure bereitgestellt wird. Microsoft kann sich Datenverlust oder Verfügbarkeitsprobleme nicht leisten. Da Azure Datenbanken als Service bereitstellt, muss man sich um Sizeing der VM und die Installation des Servers keine Gedanken machen. Bei dem benötigten Datenbankmodell sieht es da etwas anders aus. Unterstützung gibt es auf der Azure Seite.

Datenbank erstellen

Als erstes ein paar Vorüberlegungen: Es wird ein Servername benötigt, dieser muss eineindeutig sein, da darüber die Datenbank von außen erreichbar sein wird. Weiterhin sollte man sich über einen Datenbanknamen im Klaren sein und über die Ressourcengruppe, die der Datenbank zugeordnet werden soll.

In diesem Beispiel ist der AzureAccount schon in die Shell geladen und die Ressourcengruppe befindet sich in der Variable $rg.

Im ersten Schritt wird der SQL Server erstellt. Um mit dem Server weiterarbeiten zu können und um das Ergebnis zu sehen, wird der Parameter OutVariable verwendet.

new_sql_server_outputIm zweiten Schritt kann nun auch schon die Datenbank erstellt werden. Auch hier gibt es verschiedene Editionen, Free sollte zum probieren ausreichen. Die weiteren Editionen, werden in der ISE intelisense mit aufgeführt.

azure_create_sqldb

Auch im Azure Portal wird die Neue Datenbank angezeigt.

azure_sql_portal

Mit der Datenbank Verbinden

    Über Visual Studio Code

Visual Studio Code ist ein plattformübergreifendes Tool, was mit verschiedenen Modulen erweitert werden kann. Einer dieser Extentions ist mssql. Mit dieser Erweiterung ist es sehr einfach, eine Azure Datenbankverbindung herzustellen.
Ich habe das Orginalbeispiel etwas auf meine Umgebung angepasst, den Post gibt es hier.

Als erstes muss die Extention installiert werden.

vsc_01_install_mssqlvsc_02_install_mssqlvsc_03_install_mssql

Nach einem Reload wird für ein neues Dokument (Strg + N) die Sprache auf SQL festgelegt (Strg+K, M).

Daraufhin werden automatisch die Sqltools von Microsoft heruntergeladen und installiert. Im Terminal von VS Code kann der Fortschritt verfolgt werden.

sql_db_ini_01

Sovierk zu den Vorbereitungen in Visual Studio Code, nun kann die Verbindung mit der Datenbank hergestellt werden. Die Visual Studio Code Erweiterung bietet die Möglichkeit Verbindungsprofile zu erstellen.

azure_sql_create_conprofile_01 azure_sql_create_conprofile_02 azure_sql_create_conprofile_03 azure_sql_create_conprofile_04 azure_sql_create_conprofile_05 azure_sql_create_conprofile_06 azure_sql_create_conprofile_07 azure_sql_create_conprofile_08 azure_sql_create_conprofile_09 azure_sql_create_conprofile_11

Es wird beim ersten Verbindungsversuch zu einem Fehler kommen. Da die Datenbank von überall aus erreichbar sein soll, müssen entsprechende Firewall Regeln definiert werden. Die Fehlermeldung zeigt auch die IP an, welche hierfür freigegeben werden muss.

Nachdem die Regel eingerichtet wurde, klappt ein erneuter Verbindungsversuch.

Zum Schluss noch ein SQL Test.

sql_query_01sql_query_02

    Über PowerShell

Um eine Verbindung mit der PowerShell herzustellen, ist es nötig den Connection String zu wissen. Diesen kann man kann einfach im Azure Portal finden. Dazu einfach zur SQL Datenbank gehen.

Am Ende ist es ein “einfacher” Aufbau des Scriptes Connection -> Command -> Abfrage / Datenverarbeitung.

 

Mit Visual Studio Community 2017

Wenn man sich bei Visual Studio mit seinem Azure Account angemeldet hat und ein neues Cloud Projekt startet, wird auch die angelegt Datenbank angezeigt.

visual_studio_sql

SQL ist gar nicht meine Stärke aber die Grundlagen sollte man beherrschen und in Verbindung mit Azure wird es in Zukunft noch sehr interessant werden. Größere aber auch kleine Datensets werde ich jetzt immer in Datenbanken speichern, auch wenn es nur zum Üben ist.

Veröffentlicht unter Azure, Cloud, DevOps, Scripting | Verschlagwortet mit , , , , , , | Hinterlasse einen Kommentar

PowerShell Netzwerkkommunikation mit IPSec schützen

IPSec

Internet Protocol Security ist ein Satz von Protokollen, welche unsicheren Netzwerkverkehr verschlüsseln soll. Es ist dabei egal um was für ein Protokoll es sich handelt, wie zum Beispiel FTP oder Telnet. Das tolle dabei ist, es ist egal ob es sich dabei um IPv4 oder IPv6 Netzwerke handelt. Bevor es zu der Einrichtung von IPSec via PowerShell kommt, wird noch ein bisschen Hintergrundwissen benötigt. Es gibt zwei verschiedene IPSec Modi, zum einen Tunnel Mode und zum anderen Transport Mode.

  • Tunnel Mode: Wird meist in Verbindung mit VPN in Verbindung gesetzt, hierbei wird ein Tunnel zwischen zwei Punkten aufgebaut. Dabei handelt es sich oft um zwei Router oder einen Router und ein VPN Client. Das Ziel vom Tunnelmode ist eine sichere Verbindung zwischen zwei Punkten über ein unsicheres Netzwerk herzustellen, wie  über das Internet.
  • Transport Mode: Diese Methode stellt eine End-zu-End Verschlüsselung zwischen zwei Hosts da. Dabei wird im Gegensatz zum Tunnel Mode der Paylod der Pakete verschlüsselt. Das ist vergleichbar, mit dem Aufruf einer HTTPS Webseite. Die Verschlüsselung besteht zwischen dem Host und dem Webserver. Dabei sind keine VPN’s oder Tunnel nötig.

Einrichten von IPSec

Wie zu erwarten wird die Transport Methode für die cichere PowerShell – Kommunikation eingerichtet. Die Einrichtung von IP,Sec erfolgt über die Advanced Firewall und über Gruppenrichtlinien, um die Verteilung besser zu steuern.  Es ist erstaunlich, wie einfach und schnell dies umgesetzt werden kann. Dabei ist es egal, ob es sich um einen oder um eine große Anzahl von Hosts handelt. Das Ziel ist es eine Gruppenrichtlinie mit den entsprechenden Firewall und IPSec Konfigurationen bereitzustellen, welche auf alle Computer in der Domäne ‘joinpowershell.de’ angewandt wird.

  1. Zu Beginn wird eine Remote Session auf den Domänen Kontroller hergestellt um einfacher mit den Gruppenrichtlinien zu arbeiten.

01_enter_pssession_dc

2.  Es wird eine neue Gruppenrichtlinie IPSec erstellt und da diese Richtlinie auf alle Clients angewandt werden soll, wird sie mit der Toplevel OU verlinkt.

02_create_gpo

3. Anschließend wird die IPSec Richtlinie erstellt und in die GPO eingetragen. Die Funktion New-IPSecRule sollte dabei etwas genauer betrachtet werden. Mithilfe dieses Befehls werden die Ports definiert auf welches IPSec angewandt werden soll, mit dem Parameter PolicyStore , dass die Regel in die GPO IPSec eingetragen werden soll. Wird dieser Parameter nicht definiert, so wird die Richtlinie nur lokal eingetragen. Bei der Umsetzung im eigenen Netzwerk sollte sich dieser Befehl noch etwas genauer angeschaut werden.

03_createIPSecRule

 

4. Die GPO ist soweit konfiguriert und es kann vom Management Server aus getestet werden, ob diese auch korrekt angewandt wird.

04_gpupdate

05_get_netipsecrule5. Zum Schluss wird eine Verbindung mit dem Domänen Controller hergestellt und die Verbindung untersucht. Die beiden Befehle  zeigen detaillierte Informationen über den Verbindungsstatus und das IP Protokoll 6 zeigt an, dass es sich um eine IPSec Verbindung  handelt.

06_check_ipsec

 

Das gute an diesem Beispiel ist, dass es sich leicht auf andere Szenarien anwenden lässt, wie anfangs erwähnt, zum Beispiel auf FTP oder Telnet Protokolle.

Veröffentlicht unter Allgemein, Configuration, DevOps | Verschlagwortet mit , , , , , , , , , , , , , , , | Hinterlasse einen Kommentar

Wer oft die PowerShell aus der Taskleiste Startet ist es bestimmt leid immer rechte Maustaste zu drücken und als Administrator auszuführen. Es gibt einen Einfachen weg dies als Standard zu setzen.

  • Eigenschaften der Windows PowerShell Exe aufrufem.

01_open_properties

  • Erweiterung unter dem Reiter Verknüpfungen aufrufen.

02_open_advanced_properties

  • Haken in der Als Administrator ausführen Check-box setzen.

03_select_admin

 

Wer die PowerShell Verknüpfung nicht in der Taskleiste hat, kann die PowerShell auch einfach über den Kontext des Startmenüs aufrufen. Achtung dies ist erst ab Windows 10 / Server 2016 möglich.

05_open_via_context

Publiziert am von Andreas Bittner | Hinterlasse einen Kommentar

Powershell Snippets in Sapien PowerShell Studio erstellen

Seit einiger Zeit versuche ich alle meine Funktionen auch mit einem Pester Testskript zu versehen. Dabei werden immer wieder die Funktion – allerdings nur mit anderen Parametern – aufgerufen, so auch in meiner jüngsten Funktion, zu welcher bald ein Blog kommen wird. Viele meiner Skripte erstelle ich mithilfe des PowerShell Studios. Im Folgenden wird die Konzeption der Snippets dargelegt.

  • Sinnvoll ist es, den Code schon bei der Hand zu haben, wobei noch keine Parameter vorhanden sein müssen. Später sind die Stellen, die mit Variablen versehen werden, einfacher zu finden.

    01_skript_without_params

  • In der Default – Ansicht befindet sich der Snippet Editor am rechten Rand. Wenn der Editor nicht eingeblendet ist, dann kann er unter dem Reiter Home-> Windows -> Panels aktiviert werden. In dem Snippetfenster werden nicht nur die eigenen, sondern auch die schon vorhandenen Textbausteine angezeigt.

02_snippets_right

03_snippets_panels

  • Nachdem das Symbol für ein neues Snippet ausgewählt wurde, muss zunächst der Name und Speicherort der Vorlagendatei angegeben werden. Im Folgenden öffnet sich ein neues Fenster, indem die Vorlage erstellt werden kann.

    04_new_snippet

     

    05_save_snippet

    06_new_snippet_window

     

  • Am einfachsten ist es, den schon vorhandenen Code in das Fenster zu kopieren und die entsprechenden Stellen durch Variablen zu ersetzen. Dafür sollte man die Stelle am besten markieren – mit rechter Maustaste auf Variables eine neue Variable hinzufügen und an die markierte Stelle klicken. Im unteren Fenster kann ganz einfach die Variable angepasst werden. Parameter sind immer an den eingeschlossenen Dollarzeichen zu erkennen.

07_raw_script08_add_parm

 

09_filled_snippet

 

 

 

  • Nach dem Speichern wird die Datei im User-Pfad angezeigt und kann entweder über eine definierte Tastenkombination, einen Doppelklick oder über die rechte Maustaste eingefügt werden. Darüber hinaus ist die Vorlage über die Default Tastenkombination mit strg+k zu finden.

10_saved_snippet

 

12_insert_with_srg+k

 

11_insert_snippet

  • Wenn die Vorlage eingefügt ist, kann nun wie gewohnt mit der Tabulatur Taste durch die einzelnen Parameter gegangen werden.

13_show_snippet

Vorlagen sind in PowerShell eine praktische Sache, sie sollten nur öfters genutzt werden.

Veröffentlicht unter Allgemein, DevOps, Entwicklung, Grundlage, PowerShell, PowerShell Studio, Scripting | Verschlagwortet mit , , , , , | Hinterlasse einen Kommentar

PSConf2017 | Show-ThirdDay

Freitag früh, man merkt, es werden auch heute weniger Leute. Was man auch versteht, denn nach zwei so tollen Tagen braucht man etwas Entspannung und einige kommen sicherlich noch. Nun worum ging es bei mir Heute?

Conatiner Windows / Linux

Meine erste Session beginnt mit den Erfahrungen von Thorsten Buz, den ich gestern schon in FileServer gehört hatte. Container ist für viele noch nicht relevant. Für die Zukunft sollte man sich dieses Thema mal etwas genauer anschauen. Denn für größere Unternehmen könnte das in der nächsten Zeit sicherlich interessant werden. In seiner Session nimmt er den Teilnehmer an die Hand und zeigt die Geschichte hinter Docker und die Zusammenhänge, aber auch Unterschiede, zu Windows Conatainer. Er gibt einen sehr gut einen roten Faden an die Hand, um sich mit Container zu beschäftigen und zu arbeiten.

Pester Tests

Auf der PSConf gab es einige Sessions, die sich mit Pester beschäftigten. Da ich mich etwas mehr zwingen muss, im Alltag Pester zu nutzen, habe ich mir auch diesen Vortrag angehört. Es wurden hier weniger Demos gezeigt, eher mehr Best Practice Beispiele. So zum Beispiel, wie Test aufgebaut werden sollten, was getestet werden soll, aber auch wie der Output aussehen soll. Denn es kommt nicht selten vor, dass solche Tests dem Vorgesetzen vorgelegt werden sollen und da sollten die Ausgaben einfach gehalten sein. Ein Vortrag für Einsteiger aber auch etwas Fortgeschrittene von einem sympatischen  Iain Brighton.

JEA

JEA Deep Dive in 45 Minutes war das Thema von Aleksandar Nikolic in meiner dritten Session. In einer Step by Step Demo stellte er in seiner Session vor wie JEA Endpunkte erstellt und administriert werden. Einsteiger sollten sich diese Session unbedingt anschauen und nacharbeiten und die Beispiele genau anschauen. Die Struktur dieser Demo ist super und wird sehr detailliert erklärt. Ein kleinen Vorgeschmack auf JEA gibt es  in meinem Blog JEA Just Enough Administration.

PowerShell Present and Future

Einer dieser Sessions, die man wahrscheinlich in den großen Saal hätte legen müssen, denn dieser Raum war mehr als voll. Was auch zu erwarten, denn es wurde über die Vergangenheit und die Zukunft von PowerShell gesprochen. Der Vortrag wurde von zwei PowerShell TeamMembern geleitet und Jeffrey Snower, sowie einige Top Speaker saßen im Publikum. Das Zeigt wie groß und interessant das Ganze ist. Für mich war es die letzte Session auf der Konferenz und soweit gut, weil diese den Kreis zur Keynote am Mittwochvormittag schloss. Denn es wurden wieder das Thema transitive Change aufgegriffen, neben dem, was sich Signifikantes in dem letzten Jahr getan hat.

last year

Viel interessanter sind aber die Sachen, die kommen werden:

  • PowerShell 6.0 / Open Source
  • Community Arbeit (Connect and Share your knowledge with others) ausbauen
  • Focus auf Hybrid und Cross Plattform (From any to any)
    • Extremer Focus auf Azure and Tools
    • PowerShell DSC
  • Transformation zu DevOps
    • Containers, Serverless
    • Continues Management as Code
  • PowerShell wird in einigen Linux Distros implementiert
  • “Continues Intelligence Managment” und “smart Remediation Automation”

roadmap

Natürlich konnten die Kollegen von Microsoft nicht alles verraten, aber so viel ist sicher, es wird interessant in diesem Jahr.

Abschließend noch ein paar Sätze zur PSConf2017. Ich hatte die Befürchtung, die Themen seien vielleicht zu ausgelutscht oder nicht aktuell genug. Durch Gesprächen mit anderen hat sich aber herausgestellt, dass solche Dinge wie Pester, DSC oder Hybride Cloud erst jetzt immer wichtiger und interessanter werden. Eins steht klipp und klar fest, man kann hierzu nicht stehen bleiben. Nicht als Unternehmen und erst recht nicht als Administrator.

 

Über Feedback von eurer Seite würde ich mich freuen. Für Themenvorschläge die euch interessieren bin ich natürlich offen.

Veröffentlicht unter Allgemein, PowerShell, PSConfEU2017, Scripting | Verschlagwortet mit , , , , , | Hinterlasse einen Kommentar

PSConf 2017 | Show-SecondDay

Das nicht alle nach dem gestrigen Abend heute früh erschienen, war schon fast zu erwarten. Aber dies kann man auch keinem verübeln, bei dem tollen Programm gestern und dem Ambiente. Mein Tag startet heute mit James O’Neill.

Good Shared PowerShell Module

Tools und Skripte zu teilen, egal ob mit Kollegen oder öffentlich, gehört in gewisser Weise zum Alltag. Doch auch wenn diese Lösungen nur für ein selbst sind, sollten sich an gewisse Regel und Best Practices gehalten werden. In dieser Stunde hat James vorgestellt, was wichtig ist um ein Skript / Module bereitzustellen. Hierzu gehören Dinge, die jedem Programmierer, DevOp oder Administrator klar sind, welche aber in 90 % der Fälle nicht gemacht werden. Dazu einige Beispiele aus seiner Session:

  • Name: Der Name einer Funktion oder eines Tools sollte immer verständlich sein, aber auch in Zeiten von Tab completion nicht all zu lang.
  • Einfach Halten: Die Skripte sollen einfach aber dafür Modular aufgebaut werden
  • Pester Test: Mit dem Ergebnis von Pestertests kann man ganz einfach zeigen, dass der eigene Code Funktioniert.
  • Hilfe: Hilfe ist einer der Dreh und Angelpunkte in Skripten und zu der Hilfe zählen vor allem auch Beispiele. Die Hilfe ist nicht nur für andere sehr wichtig, sondern auch für ein selbst. Grund ist, dass bei der Menge an Skripten die man schreibt und einige nur ein oder zwei Mal im Monat nutzt, man selbst die Syntax vergisst. Hier helfen solche Beispiele enorm. Doch die anderen Möglichkeiten der Hilfe sollten nicht vergessen werden. Es ist egal ob es sich dabei um Comment Base Help oder um ein Help xml File handelt, die Hilfe gehört einfach dazu. Die Hilfe ist zwar für den Anwender super, für den Kollegen, der den Code verstehen soll und diesen vielleicht verbessern soll hilft dies nicht viel.
  • Code Kommentieren: eine simple Möglichkeit seinen Code später wieder zu verstehen: Kommentare einbauen. Hier ist die Devise kurz und knapp. Ein Kommentar, aber auch die Synapsis sollten nicht viel länger als ein Tweet sein.
  • Konsistenz: Die Nutzer sind es gewöhnt für einen Parameter der einen Pfad angeben soll, den Parameter Path zu nutzten. Es ist nur sinnvoll, die vorhandenen Parameternamen zu nutzen. Die Nutzer kommen andernfalls durcheinander und dann nutzen die Solution nicht mehr.
  • Benutzerfreundlich: Neben den wiederkehrenden Parameternamen ist es auch wichtig, Ausgaben zu haben und einfach zu gestalten. So sollten Möglichkeiten wie WhatIf, Write-Progress und Write-Verbose auf jeden Fall mit genutzt werden. Aber auch eine gute Fehlerbehandlung und Parameter Validierung ist von großer Bedeutung.

Zusammenfassend ist zu sagen: Jeder weiß, dass diese Dinge beachten werden müssen, aber keiner macht es. Später kostet es mehr Kraft, Zeit und Geld, all diese Sachen nachzuarbeiten. Auch ich musste und muss mich manchmal dazu zwingen, genau diese Punkte stetig zu beachten.

conclutions

PowerShell Performance

Zwei PowerShell Performance Vorträge habe ich heute besucht. Gleiches Thema, (fast) unterschiedlicher Inhalt. Beginnen wir mit Staffan Gustafsson, Mitentwickler von Star Wars Battlefield 2. Er liebt die PowerShell und zeigt wie er mit großen Datenmengen umgeht und die Zeitunterschiede der einzelnen Möglichkeiten. Hier ein paar Beispiele, die sicher auch schon viele gesehen haben:

Bei ihm sagen eher die Bilder mehr aus, als den Code zu beschreiben.

Dies sind zwei Beispiele, einmal mit foreach und einmal mit get-childitem.

Gegen Ende der Veranstaltung hat man jedoch gemerkt, dass Staffan ein Entwickler ist, denn es ging immer mehr in .Net. Was sicherlich auch nötig ist um zu solchen Zeiten zu kommen.

Der zweite Performance Veranstaltung war von dem Amerikaner Jason Yoder, ein cooler typischer Amerikaner, der versucht das “lustige” europäische IT Publikum zu begeistern. Er hat durch viele Live Vergleiche auch die Unterschiede in den einzelnen Möglichkeiten dargestellt. So hat er die Unterschiede unter anderen in folgenden Punkten gezeigt:

  • Asynchrones- vs Synchrone Verarbeitung
  • $psItem vs. $_
  • Piplining vs. . Notation
  • Foreach vs. Foreach-Object
  • Like vs. -Eq
  • Contain vs. contains Methode

In allen Zeigte er dadurch, wieviel Zeit und Geld er dadurch einsparen konnte, was sich positiv auf seine Karriere auswirkte. Dies ist sicher auch eine Session welche ich mir im Nachgang nochmal anschauen werde.

Zu diesem Thema ist zu sagen, es ist enorm wichtig seinen Code gut und schnell zu entwickeln. Jedoch sollte auf die zu investierende Zeit geachtet werden und die Notwendigkeit der einzelnen Möglichkeiten, denn manchmal hat man die halbe Sekunde doch mehr Zeit.

FileServer

Thorsten Butz hält, meiner Meinung nach, mit die besten deutschsprachigen Vorträge. FileServer klingt zunächst etwas langweilig. Das war aber ganz und gar nicht der Fall. In seiner Session ging es primär darum einen File Server remote zu administrieren. Er stellte dabei dar, wie das die meisten Administratoren machen, aber, und das ist das Wichtige, auch einen besseren Weg. Das gute an diesem Beispiel ist, dass es leicht auf andere Szenarien übertragbar ist.

Die Kernfrage ist, wie kann man sein Leben vereinfachen? Die meisten nehmen RDP-Sitzungen für Remotes Arbeiten und den Windows Explorer um Freigaben zu erstellen. Probleme mit der Firewall? Kein Problem, meist wird dieser deaktiviert. Das sind einige Punkte bei denen er zeigt wie es anders geht. Ich möchte nicht die ganze Session wiederspiegeln, dafür fehlt mir im Moment das Know How. Aber in Stichpunkten kann man dies zusammenfassen:

  • Die alten Tools gehen immer noch sehr gut in Zusammenhang mit der PowerShell. Nachteil: Es werden keine Objekte zurückgegeben. Z.B. Net.exe, Whoami.exe.
  • Nano Server und Server Core werden immer präsenter und sind nicht für RDP Administration gedacht, bzw ist dies bei Nano gar nicht möglich.
  • Arbeiten mit dem Windows Server Manager ist unerlässlich
  • Nicht die Firewall deaktivieren: Remote Ports freigeben und dokumentieren.
    • Firewall Rules per GPO auf allen Fileservern bereitstellen
    •  Adm und admx Dateien sind dabei nicht immer die Lösung
    • Am besten eine Client Maschine nehmen, die Einstellungen vornehmen, exportieren und auf DC GPO Importieren. Wieso? Der GPO Datensatz wird nur mit den FileServer Resource Management Tools bereitgestellt, wo die Installation auf dem DC meist nicht erlaubt ist.

In den letzten 10 Minuten Zeigte Thorsten noch wie der Windows Explorer als Administrator aufgerufen werden kann. Hier hat er mehrere Möglichkeiten vorgestellt:

  1. Registry Wert entfernen (Pfad steht in seinen Präsentationsunterlagen)
  2. Den Explorer Als Backup Admin starten
  3. Eigene Gruppen nehmen und zu Domänen Administrator Gruppe hinzufügen, anstatt die Nutzer direkt zuzuordnen.

Leider war zu wenig Zeit um all seine Beispiele zu sehen. Durch seinen kurzen Überblick bin ich auf die Unterlagen gespannt und werde mir diese sicherlich etwas genauer anschauen.

Gruppenrichtlinienverwaltung

Meine letzte Session des Tages drehte sich um Gruppenrichtlienienverwaltung und dies natürlich mit PowerShell. Holger Voges hatte nicht viele Folien, was nicht schlimm war, denn es wurde viel mehr gezeigt. Er stellte nicht nur die Arbeitsweise der vorhandenen GPO PowerShell Tools vor, sondern auch seine Weiterentwicklungen. Dabei zeigte er Beispiele für Backup und Restore von GPO’s. Ein großes Thema war aber auch Reporting. Reporting und wie man mit diesen Ausgaben weiterarbeiten kann. Außerdem zeigte er viele Beispiele, wie man bestimmte GPO’s finden kann, z.B. anhand eines Registry Schlüssels oder ob diese für User oder Computer konfiguriert sind. Sein eigenes GPO Modul wird er in der nächsten Zeit in die Gallery laden. Es ist eine lohnenswerte Sache sich dies anzuschauen und vielleicht auch mitzuarbeiten.

Zusammenfassung von Tag Zwei: Viel Input, viel zu Lernen und viel zu Testen.

Veröffentlicht unter Allgemein, DevOps, Nice To Know, PowerShell, PSConfEU2017, Scripting | Verschlagwortet mit , , , , , , , , | Hinterlasse einen Kommentar