PowerShell: Schweizer Taschenmesser für alle

PowerShellVöllig unstrittig: Egal ob Bash, Cmd oder PowerShell – es gibt nicht selten Situationen, in denen geht es ohne Kommandozeile schlicht und ergreifend nicht weiter.
Gelegentlich - glücklicherweise zunehmend seltener - wird man trotzdem noch vor die Frage gestellt, was denn nun der Sinn der PowerShell sei, habe man doch alle Möglichkeiten mit der guten, alten Cmd. Dem Aufgeklärten fallen sofort Schlagworte wie objektorientiert und .NET Framework aus dem Gesicht, doch für einen echten Mehrwert reicht das noch nicht ganz. Gerade wenn die PowerShell von Softwareentwicklern beworben wird, schalten ambitionierte Endanwender auch gerne mal in den “brauch-ich-doch-nicht-Modus”, da das Handwerkszeug zu überdimensioniert erscheint, doch ist es das ganz und gar nicht.

Ein paar Beispiele, die mir mit der Zeit sehr ans Herz gewachsen sind und die das Potential haben, das Tagewerk eines jeden Keyboard-Junkies etwas zu erleichtern, kurz und knapp zusammengetragen:

#1 Get-ChildItem: Wer sucht, der findet

Dateien suchen… irgendwo auf der Platte hatte ich sie aber wo? Alles was im Index steckt - wie z. B. Dateien in der Bibliotheken oder dem Home-Folder - ist unproblematisch aber wie finde ich schnell und verlässlich Dateien, die irgendwo in den Untiefen des Systems liegen?
Das dir-Command (genau wie ls) an der PowerShell ist eigentlich ein Alias für das Commandlet Get-ChildItem. Entscheidend ist der Parameter -Recurse, der das Commandlet instruiert in allen erreichbaren Ordnern in/unterhalb des aktuellen Ordners zu suchen. Der Parameter -Filter hilft beim Eingrenzen der gesuchten Dateien.

ls -Recurse -Filter "*.log"

Ist zudem noch der Inhalt der per Get-ChildItem gesuchten Dateien interessant, so hilft die Übergabe der Ergebnisse an Select-String.

ls -Recurse -Filter "*.log" | Select-String "Exception"

#2 In alten DOS-Tools stets Standard: Datei-Attribute modifizieren

Möchte man z. B. das Erstellungsdatum oder das Änderungsdatum von Dateien anpassen, so führte in Prä-PowerShell-Zeiten der Weg gerne über eine hastig improvisierte Konsolenanwendung, welche man bis zum nächsten Einsatz gleich wieder verlegt hatte oder gar über ein Stück zwielichtige Freeware. Mit System.IO.File und einem Einzeiler ist man hier schneller am Ziel.

[IO.File]::SetLastWriteTime("C:\config.sys", (New-Object DateTime 1992, 1, 1))
[IO.File]::SetCreationTime("C:\config.sys", (New-Object DateTime 1992, 1, 1))

#3 Ausgabe in einer Tabelle sortieren und filtern ohne Umwege über Excel

Alles, was im Konsolenfenster passiert, bleibt im Konsolenfenster. Zumindest die Struktur bei tabellarischer Ausgabe kommt leider bei Copy&Paste abhanden. Möchte man mit den Daten weiterarbeiten, schafft hier das Commandlet Out-GridView Abhilfe, welches ein separates Tool zur tabellarischen Darstellung einer jeden PowerShell-Ausgabe startet; hier am Beispiel der letzten 10 Einträge aus dem Eventlog.

Get-EventLog Application -Newest 10 | Out-GridView

#4 Prüfsummen: MD5- oder SHA-Hash schnell berechnet

Nicht nur um zu prüfen, ob eine Datei sich gegenüber einem früheren Zeitpunkt verändert hat, sondern auch um diverse vorkompilierte Binaries aus der OpenSource-Gemeinde auf ihre Authentizität hin zu prüfen, kommt man an MD5 und SHA-Hashes kaum vorbei. Ungünstig nur, wenn man kein Tool zur Hand hat, in welches man den jüngst erworbenen Download stopfen kann. Der Security.Cryptography-Namespace des .NET Framework mit seinen Crypto Service Providern ist hier eine geeignete Anlaufstelle.

# MD5 
[BitConverter]::ToString((New-Object Security.Cryptography.MD5CryptoServiceProvider).ComputeHash((New-Object IO.FileInfo("C:\Windows\write.exe")).OpenRead())).Replace("-","").ToLower()
# SHA
[BitConverter]::ToString((New-Object Security.Cryptography.SHA1CryptoServiceProvider).ComputeHash((New-Object IO.FileInfo("C:\Windows\write.exe")).OpenRead())).Replace("-","").ToLower()

#5 Es wird Zeit: Ticks und Timestamps

Häufig in Log-Dateien und Debugger-Ausgaben anzutreffen – Zeitstempel, die nicht auf den ersten Blick zielsicher im Kalender zuzuordnen sind. Mit einigen Bordmitteln bzw. statischen Methoden des .NET Typs DateTime kommt man den unterschiedlichsten Zeitangaben schnell auf die Schliche.

# Ticks in Datum/Zeit konvertieren 
[DateTime] 634539233533222331
# Datum/Zeit in Unix-Timestamp konvertieren
(([DateTime]::Now) - (New-Object DateTime 1970, 1, 1).ToLocalTime()).TotalSeconds
# Unix-Timestamp in Datum/Zeit konvertieren
(New-Object DateTime 1970, 1, 1).ToLocalTime().AddSeconds(1393023440)

In 20 Jahren vom Organizer zum Smartphone

Waren vor 20 Jahren die heute so omnipräsenten, elektronischen Gadgets eher Randprodukte für den rastlosen Außendienstmitarbeiter, so findet man sie heute in jeder Hosentasche mit einem Vielfachen des damaligen Leistungs- und Funktionsumfangs. Ursprünglich als bessere Taschenrechner mit geringer Speicherkapazität und gewöhnungsbedürftiger Ein- und Ausgabe anstatt Ringbuchplanern genutzt, waren sie neben den Mobiltelefonen nicht minder einer der Wegbereiter für das mobile Internet.

Adressdatenbanken sowie reine PDAs sind nahezu ausgestorben und Smartphones als auch Tablets erfreuen sich größter Beliebtheit. Inzwischen gibt es nur noch wenig, was die kleinen Kisten nicht können. Handy-Kameras mit Pixel-Formaten von DSLRs, 4G-Datenübertragung, WLAN, Bluetooth, NFC, GPS, Social Media Integration, Media-Streaming und Browser, die ihren Desktop-Kollegen das Wasser reichen können, lassen die ursprünglich essentiellen Grundfunktionen wie PIM und Telefonie in den Hintergrund treten.

20 Jahre und ein Nachmittag mit dem Kopf im Technikschrank sollen Grund genug für mein ganz persönliches Resümee‎ sein:

Privileg DB50; Pocket Office CE64; Scall XTS; CasioPocket Viewer PV-100; Philips Nino 210; Siemens S35; Nokia 7110; Casio EM 500G; Nokia7650; HTC PM10A (MDA compact); Asus P750; Samsung Omnia II; Samsung Omnia 7; NokiaLumia 925

…und sie funktionieren alle noch – bis auf den Scall, mangels Service, der 2002 offiziell von eMessage/E*Cityruf eingestellt wurde.

Hier die Übersicht der Geräte:

Hersteller Modell Jahr Betriebssystem Speicher
(MB)
CPU Takt
(MHz)
Privileg DB50 1994 Unbekannt < 1 1
Unbekannt Pocket Office CE64 1996 Unbekannt < 1 4
Scall XTS 1997 Unbekannt - -
Casio Pocket Viewer PV-100 1998 Casio PVOS 1 20
Philips Nino 210 2000 Windows CE 2.11 8 75
Siemens S35 2000 Unbekannt < 1 -
Nokia 7110 2002 Nokia OS Series 40 < 1 -
Casio EM 500G 2003 Windows CE 3.0 16 150
Nokia 7650 2004 Symbian OS 6.1 4 104
HTC PM10A (MDA compact) 2006 Windows CE 4.21 64 416
Asus P750 2008 Windows Mobile 6.0 64 520
Samsung Omnia II 2010 Windows Mobile 6.5 8.192 800
Samsung Omnia 7 2011 Windows Phone 7 16.384 1.000
Nokia Lumia 925 2013 Windows Phone 8 16.384 1.500

Entwicklung von CPU und Speicher mobiler Geräte

Hyper-V Server 2012 beklagt fehlenden RPC-Dienst

Workgroup-Umgebung, ein Hyper-V Server 2012, Standalone, verwaltet von einem Windows 8 Client mit Hilfe des Hyper-V MMC Snap-Ins: Alles funktioniert problemlos.

Von einem Tag auf den nächsten, ohne Änderungen am Setup, meldet das MMC Snap-In, dass der RCP-Dienst auf dem Server nicht erreichbar/verfügbar sei: “Cannot connect to the RPC service on computer ‘HOSTNAME’. Make sure your RPC service is running.”

Das Rätsels Lösung…
Die Ursache war das abgelaufene Kennwort des lokal auf dem Hyper-V Server erstellten Benutzerkontos, welches zur Verwaltung des Servers verwendet wurde.
Der einfachste Lösungsansatz wäre das Ablaufen des Kennworts für dieses Konto zu deaktivieren. Da es sich jedoch um eine Core-Installation handelt, galt es das Problem ohne GUI-Verwaltungstools sondern per PowerShell und WMI zu lösen.

# get all local user accounts 
$localUsers = Get-WmiObject -Class Win32_UserAccount -Namespace "root\cimv2" -Filter "LocalAccount='$True'"
# index 2 is the hyper-v management user identified in $localUsers 
$localUsers[2].PasswordExpires 
# --> True
$localUsers[2].SetPropertyValue("PasswordExpires", $false)
$localUsers[2].PasswordExpires 
# --> False

SharePoint-Berechtigungsstufe kopieren und einschränken

Die Erstellung neuer Berechtigungsstufen (SPRoleDefinition) und vollständiger Definition der Standardberechtigungen (SPBasePermissions) mittels PowerShell ist in wenigen Zeilen Code erledigt. Geringfügig komplexer wird es, will man anhand einer Vorhandenen eine neue Berechtigungsstufe erstellen und lediglich einen einzigen Berechtigungssatz entziehen.
Sicher wäre es ein Einfaches eine neue Berechtigungsstufe unter Aufzählung aller zu gewährenden Rechte anzulegen… gilt es dabei jedoch die bereits definierten Berechtigungen einer Rolle als Vorlage zu verwenden oder eine relativ weitgehend berechtigte Rolle zu erstellen, kommt man mit diesem Ansatz nur über Umwege ans Ziel.

Da die einer Rolle zugewiesenen Berechtigungen in der Berechtigungsstufe als Bitmaske gespeichert werden, ist ein bitweises XOR das Mittel der Wahl: Mit Hilfe des PowerShell-Operators -bXor kann eine einzelne Berechtigung von der vorgegebenen Berechtigungsmaske abgezogen werden.

# open the desired website
$spWeb = Get-SPWeb "URL-to-SharePoint-Web"

# get the originating role definition from the website using the name of the role definition
$spRoleDefAdmin = $spWeb.RoleDefinitions["Vollzugriff"]

# create the new role definition from the template specified above
$spRoleDefAdminReduced = New-Object Microsoft.SharePoint.SPRoleDefinition ($spRoleDefAdmin)

# just some naming stuff
$spRoleDefAdminReduced.Name = $spRoleDefAdmin.Name + " ohne Benutzermanagement"
$spRoleDefAdminReduced.Description = $spRoleDefAdmin.Description.Replace(".", "") + " ohne Benutzermanagement."

# first check, if permission is included in new role definition…
if ($spRoleDefAdminReduced.BasePermissions -band [Microsoft.SharePoint.SPBasePermissions]::ManagePermissions)
{
    # …if so, subtract permission by a bitwise OR (exclusive) operation
    $spRoleDefAdminReduced.BasePermissions = ( $spRoleDefAdminReduced.BasePermissions-bxor [Microsoft.SharePoint.SPBasePermissions]::ManagePermissions )
}

# add the new role definition to the desired website
$spWeb.RoleDefinitions.Add($spRoleDefAdminReduced)

Im Beispiel wird die Berechtigungsstufe “Vollzugriff” (FullMask) als Vorlage für die neue Rolle verwendet, welcher anschließend die Berechtigung “Berechtigungen verwalten” (ManagePermissions) entzogen wird.

DotNetNuke-Wording

Einige Begriffe rund um das CMS und deren Bedeutung - ganz besonders im Wechsel zwischen Englisch und Deutsch – haben Potential für Verwirrung zu sorgen.

Die logischen Zusammenhänge des Systems im Kontext der Funktionen sowie der wichtigsten Begriffe soll der nachfolgende “Spickzettel” versuchen zu erklären…

DNN-Terms

DotNetNuke – Begrifflichkeiten

 

DNN-Begriff DNN-Begriff  (Deutsch) Beschreibung Speicher
Portal Webseite Ein Portal repräsentiert eine eigenständige Webseite mit eigenem Benutzerverzeichnis, eigenen Alias-Namen (Hostheader; z.B. http://www.mein-dnn.de) und eigenen Seiten (Pages). Das System kann mehrere Webseiten parallel verwalten.

Ebenfalls wird je Portal ein eigenständiger Dateibereich/Ordner innerhalb der DNN-Webanwendung erzeugt, der ausschließlich für das jeweilige Portal und deren Benutzer und nicht Portalübergreifend zur Verfügung steht.

DB
Page Seite Seiten dienen der Strukturierung einer Webseite (Portal). Sie können in beliebiger Anzahl zu einer Webseite hinzugefügt werden und können mehrere Modul-Instanzen aufnehmen, die in den durch das Skin verfügbar gemachten Layoutbereichen (Panes) angeordnet werden können. DB
Module Modul Ein Modul ist eine eigenständige kleine .NET-basierte (Web-)Anwendung, die innerhalb von DotNetNuke auf CMS-/Host-Ebene installiert werden kann und auf Seiten (Pages) in beliebiger Anzahl als Modul-Instanz mit jeweils eigenständigen Konfigurationsdaten eingebunden werden kann.

Ferner ist es möglich das System um eigene Module zu erweitern, die in den .NET-Sprachen C# oder VB entwickelt werden können. DotNetNuke stellt dabei eigene Klassenbibliotheken bzw. eine API bereit, die den Zugriff auf die interne Organisation des CMS zulässt.

Das Konzept der Module wurde im CMS vollständig für die internen Funktionen verwendet. Es gibt zahlreiche freie Module, die ursprünglich mit der Standardversion ausgeliefert wurden und nun separat (für die freie Community-Edition) von CodePlex nachgeladen und installiert werden müssen.

Module werden im System als Erweiterung (Extension) verwaltet.

DB
(Inhalt)
+
FileSystem
(Code/Res.)
Skin Seitenlayout Ein Skin definiert eine Gestaltungsvorlage für Seiten (Pages), welche auf Host-Ebene oder auf Webseiten-Ebene als Erweiterung installiert werden kann.

Es können beliebig viele Skins installiert werden, wobei ein Skin mehr als eine Seitenvorlage enthalten kann. Ebenfalls kann ein Skin Ressourcen-Dateien wie separate CSS-, JavaScript- und/oder Bild-Dateien enthalten.

Im Skin sind der Seitenaufbau, das Layout, die Platzhalter bzw. Layout-Bereiche (Panes) definiert und es können zur Integration von Basisfunktionen Skin-Objekte referenziert werden.

FileSystem (Code/Res.)
SkinObject - Ein Skin-Objekt ist ein Modul für Skins, welches kleinere Funktionen im Skin übernehmen kann (z.B. Navigation, Copyright-Notiz oder die Breadcrumb-Navigation). FileSystem (Code/Res./
Config)
Container Modulrahmen Der Container ist das Pendant zum Skin, jedoch nicht zur Verwendung mit der Seite (Page) sondern ausschließlich für Modul-Instanzen.

Modulrahmen können in das Bereitstellungspaket eines Skins integriert werden und gehören dann direkt zu einem Skin dazu.

FileSystem (Code/Res.)
Pane (Layout-)Bereich Ein im Skin definierter Platzhalter, in welchem eine Modul-Instanz hinterlegt werden kann. FileSystem
(in der Skin-Definition)

Ribbons für WPF in .NET 4.5

Mit der jüngsten Framework-Erweiterung darf der geneigte WPF-Entwickler unter anderem endlich auch direkt ohne zusätzliche Toolkits auf die gängigen Ribbon-Controls zurückgreifen. Leider fehlen die Steuerelemente im Visual Studio 2012 derzeit noch im “Werkzeugkasten”, so dass man diese separat mit Hilfe eines Verweises auf System.Windows.Controls.Ribbon hinzufügen und anschließend im XAML-Code von Hand tippen muss. Im Designer jedoch werden sie unmittelbar angezeigt, auch wenn dort die Bearbeitungs-/Auswahlmöglichkeiten nicht vorhanden bis begrenzt vorhanden sind.

Dennoch lassen sie die Ribbons recht intuitiv und funktional einsetzen, so dass mit dem Ausprobieren der neuen Features unmittelbar eine überarbeitete Version von YAWLT entstanden ist, welche abermals als freie Alpha-Version bei SkyDrive heruntergeladen werden kann

HINWEIS: Wer das Tool auf einem System ohne .NET 4.5 ausführen möchte, sei gewarnt. Der Microsoft Download-Link auf das 4.5er Framework ist offenbar nicht auf dem aktuellen Stand. Der korrekte Link auf den Download der Laufzeitumgebung des .NET Framework 4.5 lautet: http://www.microsoft.com/de-de/download/details.aspx?id=30653.

Yet Another WorkLoad Tracker

YAWLT ist der Prototyp einer Anwendung zur Aufgabennachverfolgung. Die Vereinfachung der Leistungs-/Aufwandserfassung und speziell die Nachverfolgung der Aufgaben in verschiedenen Team- und Kollaborationsplattformen stehen dabei im Vordergrund.

Die Anwendung unterstützt verschiedene Ansätze der Aufgabenerfassung, so dass man unabhängig von externen Systemen ebenfalls lokale Aufgabenlisten führen und verwalten kann. Eine Sammlung von Aufgaben kann als separate Datei gespeichert werden, so dass man diese mit YAWLT z.B. auf Basis von Themen und/oder Projekten getrennt durch mehrere Dateien nutzen kann. Darüber hinaus besteht ebenfalls innerhalb einer solchen Aufgabensammlung die Möglichkeit Gruppierungen zur thematischen Trennung zu verwenden – die sogenannten Data Connectors.

Bei der Verwendung von Data Connectors mit Bindung an ein externes System erweitert sich der Funktionsumfang von YAWLT, so dass nicht nur Aufgaben lokal in Dateien verwaltet werden können, sondern der Abruf sowie das Speichern von Aufgaben aus bzw. in das jeweilige externe System möglich ist. Von Vorteil ist dabei, dass pro Aufgabensammlung nicht nur ein Data Connector genutzt werden kann sondern beliebig viele unterschiedlicher Typen. So ist es zum Beispiel möglich, zu einem Projekt eine Aufgabensammlung zu pflegen, deren zu bearbeitenden Aufgaben verteilt in einem Dynamics CRM System, zwei verschiedenen SharePoint Systemen und parallel dazu noch eigene Aufgaben, die nicht in externen Systemen erfasst sind, geführt werden.

Aktueller Funktionsumfang

  1. Allgemein
    • Laden und Speichern von Aufgabensammlungen als Datei (*.wtt)
    • Laden und Speichern von Aufgaben aus externen Systemen
    • Parallele Pflege von Aufgaben aus mehreren unterschiedlichen externen Systemen
    • Verwaltung von Aufgaben über die Aufgabenliste
    • Kombinieren von Aufgabensammlungen durch Importfunktion
    • Übersichtliche Darstellung von zu bearbeitenden Aufgaben im Arbeitsbereich
    • Pausieren von Aufgaben bei Trennung der Session oder beim Sperren des Bildschirms
  2. Unterstützte externe Systeme (Data Connectors)…
    • Outlook lokal
    • Microsoft Dynamics CRM 4.0
    • Microsoft Dynamics CRM 2011 (Installation von WIF erforderlich!)
    • SharePoint 2010

“YAWLT.zip”

QUELLE: Skydrive

GRÖßE: 1,51 MByte

DATUM: 17.10.2012

Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.