Evgenij Smirnov – IT Pro aus Berlin …because IT matters :)

Es ist kein wirklich neues Ergebnis, aber ich möchte es zur Erinnerung hier festhalten.

Wer sich in der Situation wiederfindet, hinter einem authentifizierungspflichtigen Proxy PowerShell-Module aus der Gallery (oder anderen externen PowerShellGet-Repositories) finden und installieren zu müssen, kann leider nicht darauf bauen, dass man den entsprechenden Cmdlets vermitteln kann, dass ein Proxy im Weg ist.

Stattdessen muss man die gesamte Sitzung zur Nutzung des Proxy befähigen. Das geht mit drei Zeilen Code, die man – je nachdem, wie das Verhältnis zwischen Komfort und ParanoiaSicherheitsbewuisstsein ausgeprägt ist – entweder als Skript aufruft oder in sein PowerShell-Profil schreibt. An Letzteres kommt man mit

Start-Process notepad.exe -ArgumentList $Profile.CurrentUserCurrentHost

oder, falls man VSCode im Standardpfad installiert hat, mit

Start-Process "C:\Program Files\Microsoft VS Code\Code.exe" -ArgumentList $Profile.CurrentUserCurrentHost

Das Profil ist übrigens getrennt für PowerShell.exe und PowerShell_ISE.exe – die Variable $Profile wird unterschiedliche Werte in den beiden hostspezifischen Eigenschaften „CurrentUserCurrentHost“ und „AllUsersCurrentHost“ haben.

Folgender Code gehört also ins Profil:

[system.net.webrequest]::defaultwebproxy = new-object system.net.webproxy('http://proxy.domain.net:3128')
[system.net.webrequest]::defaultwebproxy.BypassProxyOnLocal = $true

Je nachdem, ob der Proxy die PassThrough-Authentifizierung der Windowssitzung nutzt oder eine explizite Authentifizierung verlangt, muss der Aufruf noch durch

[system.net.webrequest]::defaultwebproxy.credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials

bzw.

[system.net.webrequest]::defaultwebproxy.credentials = New-Object PSCredential('proxyuser',('proxypassword' | ConvertTo-SecureString -AsPlainText -Force)) 

ergänzt werden.
Happy NuGetting!

Vor sieben Jahren habe ich mal hier beschrieben, wie man schnell alle User mit ausgeschalteter Rechtevererbung findet. Damals war das Quest AD-Modul (aus ActiveRoles) das Mittel der Wahl, welches mittlerweile nicht mehr (kostenlos) verfügbar ist. Hier ein Code Snippet, um das gleiche mit dem nativen AD-Modul des Windows Servers zu erreichen:

$users = Get-ADUser -LDAPFilter "(mail=*)"
foreach ($user in $users) {
    $adsu = [ADSI]"LDAP://$($user.DistinguishedName)"
    if ($adsu.PSBase.objectSecurity.AreAccessRulesProtected) {
        $user.DistinguishedName
    }
}

Das Zurücksetzen der Vererbung ist etwas komplizierter als bei Quest und benutzt den AD-Provider aus dem Modul:

$users = Get-ADUser -LDAPFilter "(mail=*)"
foreach ($user in $users) {
    $adsu = [ADSI]"LDAP://$($user.DistinguishedName)"
    if ($adsu.PSBase.objectSecurity.AreAccessRulesProtected) {
        $acl = Get-ACL "AD:\$($user.DistinguishedName)"
        $acl.SetAccessRuleProtection($false,$false)
        Set-ACL -ACLObject $acl -Path "AD:\$($user.DistinguishedName)"
    }
}

Man sollte im Hinterkopf behalten, dass bei Mitgliedern in Admin-Gruppen diese Änderung durch AD wieder zurückgerollt werden wird (Stichwort AdminSDHolder), und bei produktivem Einsatz vielleicht eine Prüfung einbauen.

Happy migrating!

Die Agenda des anstehenden User Group-Treffens am 21. März steht nun fest. Alle Details und Anmeldung wie immer auf Meetup. Es sind noch Plätze frei!

Das erste Treffen des Jahres 2019 findet am 21. März bei der COMPAREX AG in Berlin-Adlershof statt. Agenda steht noch nicht fest und wird in den nächsten Tagen aktualisiert. Vorträge, kurz oder lang, können noch eingereicht werden.
Alle Details und Anmeldung: https://www.meetup.com/de-DE/Windows-Server-User-Group-Berlin/events/259153636/

Ab heute (und bis zum 09.12.2018) können Vorträge für die PowerShell Konferenz 2019 in Hannover eingereicht werden: HIER.

Also los, Community – reicht eure Themen ein, Hannover wartet!

Am 01.09.2018 durfte ich auf der diesjährigen CIM Lingen einen Vortrag zum Thema „Running Scripts in the Enterprise“ halten. Ein Thema freilich für strategische Beratungen und lange Refactoring-Projekte, das ich versucht habe, in 45 Minuten zu pressen.

Dennoch konnte ich es mir nicht nehmen lassen, zwei Live Demos einzubauen, und da diese nicht in den Folien waren, poste ich die Code Snippets für Windows und Linux ebenfalls hier. Enjoy!

Demo 1: Konfiguration zu Beginn des Skriptes lesen

Sowohl in der Test- als auch in der Produktionsumgebung ist ein Webserver vorhanden, der auf den Namen https://simpleconfig.it-pro-berlin.de hört (da DNS in Test und in Prod aber voneinander unabhängig ist, löst sich dieser Name zu unterschiedlichen Maschinen auf). Dieser Server stellt die Datei config.xml mit dem folgenden Inhalt zur Verfügung:

<scriptconfig>
	<runglobal>true</runglobal>
	<sql dbserver="ciminfra.cim.it-pro-berlin.de" dbname="ScriptsDB" dbuser="confread" dbpasswd="confread">Production SQL Database</sql>
</scriptconfig>

Die Aufgabe lautet, den Wert von „runglobal“ auszuwerten und, falls er auf „true“ steht, mit den in der nächsten Zeile enthaltenen Verbindungsdaten zu einem SQL Server zu verbinden und aus der Tabelle „SETTINGS“ ddie Einstellung „ENVIRONMENT“ auszulesen. Die Tabelle enthält zwei Spalten: „settingname“ und „settingvalue“.

Hier ist die Lösung in PowerShell. Dieser Code funktioniert unverändert in Windows PS, PSCore auf Windows und PSCore auf Linux.

function Get-CIMConfig {
    $config_url = "https://simpleconfig.it-pro-berlin.de/config.xml"
    $res = $null
    try {
        $http_response = Invoke-WebRequest -Uri $config_url -TimeoutSec 10
        if ($http_response.StatusCode -eq 200) {
            $config = ($http_response.content)
            if ($config.scriptconfig.runglobal -eq "true") {
                $res = New-Object PSObject -Property @{
                    "dbserver" = $config.scriptconfig.sql.dbserver
                    "dbname" = $config.scriptconfig.sql.dbname
                    "dbuser" = $config.scriptconfig.sql.dbuser
                    "dbpasswd" = $config.scriptconfig.sql.dbpasswd
                }
            }
        }
    } catch {}
    $res
}

#Jedes Skript beginnt mit
$cc = Get-CIMConfig
if ($cc) {
    Write-Host "Ausführung gestattet..."
    $dbconnstr = "Server=$($cc.dbserver);Database=$($cc.dbname);uid=$($cc.dbuser);pwd=$($cc.dbpasswd)"
    $dbconn = New-Object System.Data.SqlClient.SqlConnection
    $dbconn.ConnectionString = $dbconnstr
    $dbconn.Open() | Out-Null
    $dbcmd = New-Object System.Data.SqlClient.SqlCommand
    $dbcmd.Connection = $dbconn
    $dbcmd.CommandText = "SELECT settingvalue FROM SETTINGS WHERE settingname='ENVIRONMENT'"
    $dbres = $dbcmd.ExecuteReader()
    $dbtable = New-Object System.Data.DataTable
    $dbtable.Load($dbres)
    Write-Host ("Aktuelle Umgebung: {0}" -f $dbtable.Rows[0]['settingvalue'])
}

In Produktion würde man natürlich noch ein wenig mehr Überprüfung und Logging einbauen, aber das ist der wesentliche Teil. Dieser Code benötigt keine externen Module oder Bibliotheken.
In VBS ist der Code etwas sperriger, macht aber was er soll und liefert das gewünschte Ergebnis:

strConfigURL = "https://simpleconfig.it-pro-berlin.de/config.xml"
Set wshShell = CreateObject("WScript.Shell")
strConfigLocal = wshShell.ExpandEnvironmentStrings("%TEMP%") + "\config.xml"
wshShell.Run("cmd.exe /C del /q " + strConfigLocal)

Set objHTTP = CreateObject("WinHttp.WinHttpRequest.5.1")
objHTTP.Open "GET", strConfigURL, False
objHTTP.Send
If objHTTP.Status = 200 Then
    Dim objStream
    Set objStream = CreateObject("ADODB.Stream")
    With objStream
        .Type = 1 'adTypeBinary
        .Open
        .Write objHTTP.ResponseBody
        .SaveToFile strConfigLocal
        .Close
    End With
    Set objStream = Nothing
End If

Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load(strConfigLocal)
Set colNodes = xmlDoc.SelectNodes("//scriptconfig/runglobal")
For Each objNode in colNodes
    runglobal = objNode.Text
Next
If runglobal = "true" Then
    Set colNodes = xmlDoc.SelectNodes("//scriptconfig/sql")
    For Each objNode in colNodes
        dbserver = objNode.Attributes.GetNamedItem("dbserver").Text
        dbname = objNode.Attributes.GetNamedItem("dbname").Text
        dbuser = objNode.Attributes.GetNamedItem("dbuser").Text
        dbpasswd = objNode.Attributes.GetNamedItem("dbpasswd").Text
    Next
    strDBConnStr = "Provider=SQLOLEDB;Data Source=" & dbserver & ";Initial Catalog=" & dbname & ";User ID=" & dbuser & ";Password=" & dbpasswd
End If
'WScript.Echo(strDBConnStr)
Set objDBConn = CreateObject("ADODB.Connection")
objDBConn.Open(strDBConnStr)
Set objRS = CreateObject("ADODB.Recordset")
objRS.Open "SELECT settingvalue FROM SETTINGS WHERE settingname='ENVIRONMENT'", objDBConn, 3, 3
objRS.MoveFirst
WScript.Echo("Aktuelle Umgebung: " & objRS.Fields.Item("settingvalue"))
objRS.Close()
objDBConn.Close()

Die Shell auf Linux (geht in POSIX und in BASH) braucht zwei externe Pakete, XMLLINT und FreeTDS, danach funktioniert es mit

#!/bin/sh
wget -q "https://simpleconfig.it-pro-berlin.de/config.xml" -O ~/config.xml
runglobal=$(xmllint --xpath "//scriptconfig/runglobal/text()" ~/config.xml)
if [ $runglobal = true ]
    then
        echo "Ausführung gestattet..."
        dbserver=$(xmllint --xpath "string(//scriptconfig/sql/@dbserver)" ~/config.xml)
        dbname=$(xmllint --xpath "string(//scriptconfig/sql/@dbname)" ~/config.xml)
        dbuser=$(xmllint --xpath "string(//scriptconfig/sql/@dbuser)" ~/config.xml)
        dbpasswd=$(xmllint --xpath "string(//scriptconfig/sql/@dbpasswd)" ~/config.xml)
        env=$(bsqldb -U $dbuser -P $dbpasswd -S $dbserver -D $dbname -i sico1.sql 2>&-)
        echo "Umgebung: " $env
fi

Die Datei sico1.sql könnte man natürlich dynamisch aus dem Skript generieren, für den Zweck der Demo ist sie aber statisch und hat den folgenden wenig überraschenden Inhalt:

SELECT settingvalue FROM SETTINGS WHERE settingname='ENVIRONMENT'

An der CMD-Shell schaut es natürlich etwas mau aus, dort hat man sich in der Vergangenheit ja immer wieder mit einer selbstgeschriebenen EXE beholfen. Man kann natürlich auch das o.g. VBS-Skript zu Begimn des CMD-Batchscripts bemühen.

Demo 2: Auf einen SYSLOG-Server schreiben

Einträge auf einem SYSLOG-Server erzeugen, das schaffen Skriptsprachen auch. PowerShell (auch Core) nutzt die System.Net-Klassen:

$syslog_server = 'ciminfra.cim.it-pro-berlin.de'
$Log_Message = 'PowerShell:TEST'
#0=EMERG 1=Alert 2=CRIT 3=ERR 4=WARNING 5=NOTICE  6=INFO  7=DEBUG
$Log_Severity = '1'
#(16-23)=LOCAL0-LOCAL7
$Log_Facility = '22'
# Calculate the priority
$Log_Prio = ([int]$Log_Facility * 8) + [int]$Log_Severity
$Sender = $env:COMPUTERNAME
#Time format the SW syslog understands
$TS = Get-Date -Format "MMM dd HH:mm:ss"
# Assemble the full syslog formatted message
$FullSyslogMessage = "<{0}>{1} {2} {3}" -f $Log_Prio, $TS, $Sender, $Log_Message
$FullSyslogMessage
# create an ASCII Encoding object
$Encoding = [System.Text.Encoding]::ASCII
# Convert into byte array representation
$ByteSyslogMessage = $Encoding.GetBytes($FullSyslogMessage)

$UDPCLient = New-Object System.Net.Sockets.UdpClient
$UDPCLient.Connect($syslog_server, 514)
$UDPCLient.Send($ByteSyslogMessage, $ByteSyslogMessage.Length)
$UDPCLient.Close()

VBS und CMD-Shell müssen hier, wenig überraschend, ohne externe Unterstützung passen, die BASH-Shell hingegen ist der absolute Champion (das gilt aber nicht für die POSIX-Shell):

#!/bin/bash
msg="Linux_bash:TESTLOG Definitive"
facility=21 #local5
severity=4 #WARN
prio=$((8 * $facility + $severity))
syslogserver="ciminfra.cim.it-pro-berlin.de"
hname=$(hostname)
ts=$(date "+%b %d %H:%M:%S")
syslogmsg="<$prio>$ts $hname $msg"
echo "$syslogmsg" > /dev/udp/$syslogserver/514

Folien von der CIM

Und hier die Folien zum Download:

Gestern hatte ich die Ehre, auf der CIM Lingen 2018 zu „Running Scripts in the Enterprise“ (was sonst?) zu sprechen. Bis dato hatte ich die CIM gar nicht auf dem Schirm gehabt, aber die Emsländer Community-Konferenz hat sich als eine ganz tolle Veranstaltung entpuppt. Trotz einer ordentlichen Größe von 300 Teilnehmern ist die Atmosphäre eines User Group-Treffens unverkennbar vorhanden. An dieser Stelle nochmals vielen Dank an das Orga-Team und natürlich an die Sponsoren, zu denen sowohl mein jetziger als auch mein ehemaliger Arbeitgeber gehören.

Ich habe einige tolle Menschen kennengelernt und einige bisher nur aus dem Online-Geschehen bekannte endlich in Person getroffen. Etwas traurig war es zu sehen, dass langjährigen MVPs und absoluten Grundsteinen der deutschen Microsoft-Community die Auszeichnung mit der Begründung „too little cloud content“ entzogen wurde. Schämt euch, Microsoft! Ihr werdet schon sehen, was ihr davon habt.

Nächstes Jahr soll die (nunmehr 15.) CIM an zwei Tagen stattfinden – 13. + 14.09.2019 (save the date!) und über acht Tracks gehen. Es sind 50 Sessions angekündigt, es ergeben sich also rechnerisch, abzüglich der Opening und der Closing Keynote, drei Slots pro Tag in jedem Track. Somit hätte jeder Slot voraussichtlich eine Länge, die einen deutlich tieferen Einstieg in das jeweilige Thema erlaubt. Drückt mir die Daumen – das wäre genau mein Ding, denn diesmal bin ich etwas aus der Zeit geraten und musste am Ende des 45-minütigen Slots ganz schön hetzen.

Also: auf zur nächsten CIM: #cimlingen #communityrocks

Ich habe ja schon des öfteren über Eigenarten von Sammlungen aller Art in PowerShell berichtet. Heute ein Beispiel aus der Active Directory-Administration.

Nehmen wir einfach mal an, wir haben ein mehrwertiges Attribut und wollen zu diesem einen zusätzlichen Wert hinzufügen. Für diese Beispiel nehme ich msExchExtensionCustomAttribute1, da kann man nichts kaputt machen.

Set-ADUser john.doe -Replace @{msExchExtensionCustomAttribute1=@("A","B","C")}
$user = Get-ADUser john.doe -Properties msExchExtensionCustomAttribute1
$a1 = $user.msExchExtensionCustomAttribute1
Write-Host "Unser Attribut msExchExtensionCustomAttribute1:"
$a1.GetType()
$a1

Nun wollen wir zu $a1 ein viertes Element hinzufügen. IntelliSense in ISE bietet folgendes an:

Auch wenn’s bei nativen PowerShell-Arrays nicht funktioniert, ist Add doch vielversprechend. Probieren wir’s aus:

$a1.Add("D")
Write-Host "`r`nNach dem Add:"
$a1.GetType()
$a1

liefert

Sieht doch super aus, richtig? Der Typ ist derselbe, alle vier Elemente sind wie erwartet da. Nun bleibt also die neue Sammlung zurück in das Attribut zu schreiben und das Ergebnis zu überprüfen:

Set-ADUser john.doe -Replace @{msExchExtensionCustomAttribute1=$a1}
Get-ADUser john.doe -Properties msExchExtensionCustomAttribute1

Doch das Ergebnis ist leider nicht ganz das, was wir erwartet haben:

Das soeben beschriebene Attribut ist leer. Hmmm.

Machen wir das gleiche Spiel und nehmen statt der Methode .Add das PowerShell-eigene Anfügen:

$a1 += "D"

so ist das Ergebnis wie erwartet:

Der alles entscheidende Unterschied ist anscheinend, dass die Operation += die ADPropertyValueCollection in ein System.Array konvertiert. Und dieses wird offenbar von Set-ADUser korrekt interpretiert, sein nativer Datentyp hingegen nicht!

Happy updating!

Das nächste Treffen (Q2/2018) der WSUG-B findet am Donnerstag, dem 24.05.2018 bei der COMPAREX AG in Berlin-Adlershof. Details und Anmeldung über Meetup.com: https://www.meetup.com/de-DE/Windows-Server-User-Group-Berlin/events/250092212/

Haben wir uns das nicht alle schon mal gewünscht – eine ordneltiche Hilfe zu den zahlreichen Kommandozeilen-Befehlen? Jetzt, wo man schon dachte, nun ist PowerShell da und es kommt keine CMD-Doku mehr, hat Microsoft sich einen Ruck gegeben und die folgende coole PDF rausgebracht: https://www.microsoft.com/en-us/download/details.aspx?id=56846

Happy commandlining!