Weisheiten - der Netz-Weise Blog

Zum Vergeben eines Laufwerksbuchstaben muß man zuerst einmal evaluieren, welchen Laufwerksbuchstabe frei ist. Es gibt eine Reihe Ansätze, aber dieser hier ist für Lernzwecke ganz interessant. Die folgende Funktion wandelt die Asciicodes der Buchstaben C (Ascii 67) bis Z (Ascii 90) in Buchstaben um. Die Buchstaben werden der Reihe nach in einer Foreach-Schleife mit Test-Path gegen die vorhandenen Pfade überprüft. Sobald Test-Path False zurück gibt, wird die Schleife per "break" abgebrochen und der gefundene Buchstabe zurück gegeben. 

Interessant in diesem Zusammenhang ist auch die Invertierung der Suche. Um beim letzten Buchstaben zu beginnen, wird einfach der Startbuchstabe auf Z gesetzt und die Auflistungsreihenfolge umgedreht ( $Counter..67 bzw. $Counter..90). Allerdings ist der Default-Wert für den Startbuchstaben auf C gesetzt, so dass eine Invertierung der Suche ohne setzen des Startbuchstabens normalerweise kein Ergebnis liefert. Eine Lösung bietet die automatische Variable $PSBoundParameter. Diese Variable wird automatisch erstellt, wenn beim Aufruf einer Funktion Übergabeparameter vom Benutzer verwendet werden. Die Methode Containskey() überprüft, ob ein Parameter vorhanden ist oder nicht. 

function get-freedrive

{

  <#

Die Windows-Powershell ist ein sehr mächtiges Werkzeug, und wie alle mächtigen Werkzeuge kann man Ihre Funktionen für gute wie für schlechte Dinge anwenden. Daher versuchen viele Unternehmen, die Ausführung von Powershell zu verhindern. Das die Ausführungsrichtlinie, die die Skriptausführung einschränken kann, kein echtes Hinternis ist, hat sich inzwischen herumgesprochen. Tatsächlich scheint der Stand der Dinge zu sein, dass man mit Windows Bordmitteln nur mit Applocker (ab Windows 7 Enterprise oder Windows 8.1 / Windows 10 Pro) einen ansatzweise hinreichenden Schutz vor der Ausführung von Powershell erreichen kann. Versuchen Sie aber gar nicht erst, mit Skriptregeln herum zu spielen - Skriptregeln verhindern das Ausführen von Skripten, aber nicht den Start von Powershell. Und da man in Powershell jedes Skript auch von Hand eingeben kann, erreicht man mit dem Verhindern von Skripten gar nichts. Man könnte jetzt noch argumentieren, dass lange Skripte nicht von Hand übertragen werden können, oder dass ein Hacker ohne physikalischen Zugriff auf den Server die Skripte nicht von Hand in die Konsole übertragen kann. Allerdings läßt sich Powershell auch manuell mit dem Parameter "-Command" starten. Und es ist sehr einfach, ein Skript von der Kommandozeile aus einzulesen und einfach über den Standard-Ausgabestrom an die Powershell.exe weiterzuleiten.

get-content c:\temp\meinSchadcode.txt | powershell.exe -command -

Hier fehlt im Übrigen nichts, es handelt sich in der Tat um einen Bindestrich hinter dem -Command. Der Bindestrich bewirkt, dass das auszuführende Kommando aus dem Ausgabestrom gelesen wird. Dadurch muß der Schadcode sich noch nicht einmal in einer .ps1-Datei befinden - Powershell.exe unterbindet die Ausführung von anderen Dateiendungen normalerweise.

Dank Docker gibt es in der aktuellen Preview von Windows 10 und in der Rosetta-Jubiläums-Ausgabe, die Ende Juli erscheint, endlich die Möglichkeit, virtuelle Maschinen in einem isolierten, privaten Netzwerk per NAT mit dem physikalischen Netzwerk zu verbinden, ohne eine Router-VM installieren zu müssen. Der NAT-Switch wurde notwendig, um per Docker bereitgestellte Anwendungen mit den Netzwerk zu verbinden. Und so richtet man einen NAT-Switch ein: 

Legen Sie zuerste mit Hyper-V einen neuen internen VM-Switch an. In früheren Versionen von Windows 10 gab es einen speziellen NAT-Switch, aber der ist zugunsten des internen Switches wieder gewichen:

$NatSwitch = New-VMSwitch -SwitchName Nat -SwitchType Internal

Als nächstes benötigen wir eine Gateway-Adresse für das interne Netzwerk, die wir an den Switch binden. Ein interner Switch legt automatisch auch eine interne virtuelle Netzwerkkarte an. An diese wird die Gateway-IP gebunden. Das folgende Script fragt zunächst den zum Switch gehörenden Netwerkadapter ab. Das passiert in zwei Schritten: Erst wird die virtuelle Repräsentation mit Get-VMNetworkadapter abgefragt, und dann wird die dazugehörige physikalische Netzwerkkarte abgefragt. Es handelt sich dabei um dasselbe Gerät, aber mit zwei unterschiedlichen Cmdlets abgefragt. Diesen umständlichen Weg gehen wir, weil get-Vmnetworkadapter uns den Interface-Index nicht zurück liefert, den wir benötigen, um das NAT-Netzwerk einzurichten: 

$natNetworkAdapter = Get-VMNetworkAdapter -ManagementOS -SwitchName $NatSwitch.Name
$networkAdapter = Get-NetAdapter | Where-Object -FilterScript {
     $_.deviceid -eq $natNetworkAdapter.DeviceId
}

Haben Sie schon einmal versucht, ein per Gruppenrichtlinien verteiltes Root-Zertifikat wieder zu entfernen? Wie sich herausstellt, ist das über das Zertifikats-Plug-In in der Management-Konsole gar nicht so einfach. Hilfe verschafft hier das Kommandozeilentools Certutil in Verbindung mit Powershell.

Certutil besitzt einen Parameter -delstore, mit dem man Zertifikate aus dem Store entfernen kann. Ruft man Certutil -delstore -? auf, so bekommtn man folgende Optionen angezeigt:

Optionen:

-enterprise -- Verwendet den Unternehmensregistrierungs-Zertifikatspeicher auf dem lokalen Computer
-user -- Verwendet HKEY_CURRENT_USER oder Zertifikatspeicher.
-GroupPolicy -- Gruppenrichtlinien-Zertifikatspeicher verwenden

Verwenden Sie die Option -GroupPolicy für Zertifikate, die per Gruppenrichtlinie verteilt wurden. Der richtige Speicher ist wichtig, da Certutil Ihnen sonst zwar Vollzug vermeldet, aber die Zertifikate nicht löscht. Weiterhin benötigen Sie den Thumbprint (Daumenabdruck oder Checksumme) des zu entfernenden Zertifikats. Den erhalten Sie über Powershell:

Das Anlegen einer virtuellen Maschine in Hyper-V geht sehr einfach. Hier zeige ich ein kleines Beispiel, dass eine Generation-2 VM anlegt, konfiguriert und ein ISO-Image zum Starten bereitstellt. 

Zuerst erzeuge ich ein Credential-Objekt, um das ISO-File für die VM aus einer Freigabe zu kopieren. Die Methode PSCredential der Klasse PSAutomation erzeugt uns dafür ein Credential-Objekt, das 2 Parameter benötigt: Den Benutzernamen und das Kennwort.

• $password = ConvertTo-SecureString -String "Passwort" -AsPlainText -Force
• $UserName = "Administrator"
• $adminCred = New-Object System.Management.Automation.PSCredential ($username, $password)

Als nächstes wird ein Ordner für das Iso angelegt:

$isoPath = mkdir D:\iso -Force

Es gibt in Powershell die Möglichkeit, nicht nur mit einfachen Wildcards zu suchen (*,?,...), sondern Powershell unterstützt an vielen Stellen auch Regular Expressions. Wem das nicht reicht, der kann sogar noch auf das .net-Framework zurück greifen, um Reguläre Ausdrücke zu suchen. Regular Expressions sind sehr mächtig, aber leider auch ziemlich komplex. Ein gutes Tutorial gibt es z.B. hier: http://www.regular-expressions.info/tutorial.html

Wenn man nicht regelmässig mit Regular Expressions arbeitet, gibt es von Sapien aber einen guten, kostenfreien Regex-Editor, der einem über die größten Hürden hilft. Hier eine kleine Einführung in die Community-Preview des Power Regex mit Download-Link (Eine Registrierung ist notwendig). Und noch eine gute Einführung in das Thema: Regular Expressions in Perl und Powershell

In Unix und MySQL werden Datumswerte oft als Timestamps angegeben. Ein Timestamp ist eigentlich ein Datums/Zeitwerte, der aber als Integer gespeichert ist und die Sekunden ab dem 1.01.1970 angibt. Diese Zeitzählung wird auch als "Epoch date" bezeichnet.

Die Umwandlung in einen Datumswert in Powershell ist eigentlich recht einfach, da uns Powershell alle zur Umrechung notwendigen Funktionen zur Verfügung stellt. Das Datum des 1.1.1970 liefert uns get-Date:

Get-Date '1/1/1970'

Get-Date liefert ein Objekt vom Type Datetime zurück. Alle Objekte vom Typ Datetime besitzen eine Reihe von Methoden für die Datumsmanipulation. Wir benötigen hier die Methode AddSeconds() zum Aufaddieren von Sekunden:

$Timestamp = 1464257993
(Get-Date '1/1/1970').AddSeconds($Timestamp)

Benutzereinstellungen in Office 365 kann über die Weboberfläche mühsam sein, da das Webinterface nicht unbedingt schnell ist. Außerdem möchte man eine große Anzahl von Änderungen auch ungerne per Hand eintickern. Aber zum Glück kann man in Office 365 ja alles über Powershell steuern. ;-) Im folgenden Beispiel zeige ich, wie man Adressbuch-Informationen in Exchange Online setzt, aber die meisten anderen Einstellungen lassen sich genauso leicht konfigurieren. 

Zuerst muß man den Microsft Online Services Anmelde-Assistenten für IT-Experten RTW (sprechen Sie das 10 mal hintereinander schnell aus) und das Azure Active Directory-Modul für Windows Powershell installieren. Anschliessend können Sie eine Powershell-Konsole öffnen und sich mit Office 365 verbinden:

# die Office 365 Anmeldedaten abfragen und speichern
$UserCredential = Get-Credential 
# Mit den Anmeldedaten eine Verbindung mit Microsoft Online (MSol) herstellen
Connect-MsolService -Credential $UserCredential 
# Jetzt eine Remote-Sitzung zu einem Server herstellen
$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $UserCredential -Authentication "Basic" -AllowRedirection
# Die Powershell-Befehle der Remote-Sitzung können auf den lokalen Rechner importiert werden
Import-PSSession -Session $ExchangeSession
# Alle User anzeigen
Get-User
# Und die Telefonnummer eines Users verändern
Get-User -Identity holger.voges | Set-User -Phone

Um eine Gruppe von Benutzern aus einer CSV-Datei heraus zu ändern, ist direktes Pipen der Daten aus dem csv-Datei, wie es mit den AD-Cmdlets seit Windows Server 2012 geht, leider nicht möglich. Hier behelfen wir uns mit einem kleinen Workaround. Gehen wir davon aus, dass wir eine csv-Datei mit Benutzerdaten haben, deren Inhalt ungefährt so aussieht:

"Name","Company","Phone"
"dummy.user","Netz-Weise","0511-16592599"
"holger.voges","Netz-Weise","0511-1659250"
"julia.voges","Netz-Weise","0511-16592512"

SQL-Server lassen sich mit Hilfe der SMO-Erweiterungen (Server Management Objects) des SQL-Servers per Powershell wunderbar verwalten. Einen ganzen Satz von Beispielen finden Sie z.B. auf unserer Website unter Dokus. Für den Einsatz von SMO muß SMO allerdings erst einmal installiert werden. Dies geschieht entweder bei der SQL-Server Installation, indem Sie unter der Feature-Auswahl "Client Tools SDK" auswählen, oder indem Sie von der Microsoft-Website aus dem Feature-Pack Download "SharedManagementObjects.msi" und "SQLSysCLRTypes.msi" herunterladen und installieren. Oder Sie bauen sich alternativ ein Powershell-Modul, dass die notwendigen dll´s enthält und von selbst nachlädt. Alles, was Sie hierzu benötigen, sind die beiden Downloads aus dem Feature Pack, und eine Powershell Modul-Datei. Hierfür bietet sich passenderweise eine Manifest-Datei (.psd1) an. 

Aber fangen wir von vorne an. SMO ist ein Feature, dass Microsoft eingeführt hat, um die Verwaltung von SQL-Servern aus dem .NET-Framework zu erleichtern. Anstatt über SQL-Befehle kann man per SMO programmatisch über Objekte auf den SQL-Server zugreifen. Und da man mit Powershell auf alles zugreifen kann, was das .Net-Framework zur Verfügung stellt, kann man natürlich auch SMO nutzen. Tatsächlich tun Sie das sogar bereits, wenn Sie mit der SQL-Server Konsole für Powershell (SQLPS) arbeiten, denn das besondere an dieser Konsole ist vor allem, dass beim Starten von SQLPS automatisch die SMO-Assemblies geladen werden. 

Unschön an SMO ist, dass auf jedem Rechner, auf dem Sie Ihre SQL-Server Powershell-Scripte laufen lassen möchten, SMO installiert sein muß. Allerdings läßt sich dieses Problem mit einem kleinen Trick umgehen, denn tatsächlich muß die SMO-Funktionalität gar nicht installiert werden - Sie benötigen nur die dll-Dateien, die die SMO-Funktionalität zur Verfügung stellen. Und die erhalten Sie, wenn Sie die beiden oben angegebenen msi-Pakete auf einem beliebigen Rechner installieren. Die SMO-Assemblies finden Sie nach der Installation standardmässig im Ordner %ProgramFiles% unter "Microsoft SQL Server\<Version>\SDK\Assemblies", wobei Version der internen Versionsnummer des SQL-Servers entspricht. Bei einer Standardinstallation von SMO für SQL Server 2014 wäre das also Beispielsweise:

C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\

Kopieren Sie den Ordner Assemblies. Weiterhin benötigen Sie die "Microsoft.SqlServer.SqlClrProvider.dll", an die allerdings nicht so einfach heran zu kommen ist. Sie ist im Global Assembly Cache installiert und wird standardmässig aus der Explorer-Ansicht gefiltert. Sie müssen den Filter deaktivieren. Starten Sie hierfür den Registieriungseditor und setzen Sie die folgenden Wert: 

Neulich in Azure - Sie wollen einen Strorage-Account löschen, aber er will einfach nicht verschwinden, obwohl die GUI meldet, der Job sei erfolgreich abgeschlossen? Nach einer genauen Untersuchung stellen sie fest, dass das System folgende Fehlermeldung schmeißt: Error: There is currently a lease on the blob and no lease ID was specified in the request.

Das Problem besteht darin, dass sich in dem Storage-Account noch vhd-Dateien befinden, deren VMs inzwischen gelöscht sind, was an Azure aber irgendwie vorbei gegangen ist. In meinem Fall war die Ursache vermutlich, dass ich die Objekte einzeln über Powershell gelöscht habe statt über die Web-GUI. Jedenfalls hat Azure noch eine Verbindung zwischen der VM, die nicht mehr existiert, und der vhd gespeichert und sperrt deswegen die Löschung der Daten. Lösen lässt sich das Problem auch nicht mit den Azure Powershell Cmdlets und dem Parameter Force. Stattdessen hilft AzureCLI weiter, ein Kommandozeilentool zur Verwaltung von Azure. Eine Anleitung zur Installation finden Sie bei Microsoft. 

Nachdem Sie AzureCLI installiert haben, starten Sie ein Konsole, Powershell oder cmd. Das Tool zur Verwaltung lautet einfach azure:

azure login
azure account set "Ihr Subscription-Name"
azure config mode arm
azure storage account list
azure storage account delete <Ihr Storage Account Name>

Azure config mode arm ist nur notwendig, wenn Ihr Account im Azure Resource Manager mode angelegt wurde. Ein sicheres Zeichen dafür, dass das nicht der Fall war ist, wenn Sie den account noch im alten Portal angelegt haben. Probieren Sie es einfach aus, wird Ihr Account ohne den Moduswechsel nicht angezeigt, geben Sie einfach azure config mode arm ein. Mit dem delete wird der Account sofort und ohne Meldung entfernt. Wie Mr. Spock sagen würde - faszinierend!