Ziel ist es, die aktuellste Version Adobe Reader auf allen Computern eines AD Netzwerks zu verteilen. Es handelt sich um die Version 11.0.10 (Update 13.3.2015), die speziell angepasst (deutsche Sprache, keine EULA, paar Features deaktiviert) installiert werden soll. Da ich bei diesem Prozess auf verschiedenste Fehler und Probleme stieß, werde ich die Verteilung hier detailliert erläutern.

Seit 2010/2011 gibt es ja den Hintergrundupdater in Adobe Produkten. Eigentlich gehören Verteilungen dieser Art also der Geschichte an. Jedoch kann es trotzdem notwendig werden, wenn erstmal eine Basis geschaffen werden muss, weil beispielsweise kein einheitlicher Standard des Produkts installiert ist. Einige haben Version X, andere Version Y, einige PCs haben die Software nicht einmal installiert. In diesem Fall ist ein komplettes Rollup inklusive Cleaning, also Deinstallation aller Versionen vor der Verteilung, sinnvoll und empfehlenswert.

Wie üblich gibt es mehrere Herangehensweisen, bei Adobe habe ich im Laufe der Jahre folgende Methode als sicherste empfunden:
Installer laden -> AIP lokal erstellen -> Patches slipstreamen -> mit Customization Wizard anpassen -> mit Orca optimieren -> Verteilen,
wobei der Verteilen-Punkt je nach Produkt und Situation natürlich zwischen Script oder GPO Installation unterschieden wird.
Das hier sagt Adobe zu den „Best Practices“.

Schritt 1: Installer laden

Adobe bietet für ihre Produkte teilsweise 2 verschiedene Downloadseiten an. Die typisch einfache Seite und die Seite für Administratoren, hier am Beispiel vom Reader (bei Acrobat ist das ebenfalls so).
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-installerIhr braucht natürlich das komplette Paket: 11.0.0 Basis plus aktuellstes Update, am besten in der MUI Variante.
Für die Pro’s auch ohne viel Schickschnack via FTP.

Schritt 2: AIP erstellen

Falls die Grundversion (z.B. 11.0.0) eine .zip Datei war, entpackt diese. Geht per CMD in diesen Ordner und führt den Befehl

msiexec /a "AcroRead.msi"

Der Installer startet, installiert am besten lokal, C:/Reader11/ oder so. AIP fertig!

Schritt 3: Patches integrieren

Geht per CMD in den Ordner des Updates und führt den Befehl aus:

msiexec /a "C:\Reader11\AcroRead.msi" /p "AdbeRdrUpd11004_MUI.msp"

(ihr müsst natürlich Pfade und Dateinamen entsprechend anpassen…)
Der grafische Installer für den Patch erscheint, durchklicken, fertig. Verfahrt so mit allen Patches, wenn ihr mehrere habt. Für gewöhnlich lässt sich aber das aktuellste Update auf die Basisversion anwenden, mehr dazu steht auf der Detailseite des Updates bei den „Installation Instructions“ („This update requires that Adobe Reader 11.0 MUI or later is installed on your system.“).
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-update-slipstream

Schritt 4: mit dem Customization Wizard anpassen

Wie bei Acrobat kann man auch den Reader mit dem Adobe Customization Wizard anpassen:
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-customization-wizard
EULA deaktivieren, Sprache wählen, Deinstallation alter Versionen aktivieren, paar Online Features deaktivieren, Shortcuts anpassen, tobt euch aus und speichert das Ergebnis als MST Anpassungsdatei ab.

Fertig, ihr habt jetzt eine geupdatete AIP Installation, C:/Reader11. Die könnt ihr auf das Netzlaufwerk schieben. Dazu die gerade erstellte MST. Beides zusammen könnt ihr nun Verteilen. Entweder via GPO Softwareinstallation oder per Script. Letzteres bevorzuge ich aus Gründen der Funktionalität.
Kommen wir also zum letzten Schritt.

Schritt 5: Verteilung via Script

Hier wird es nochmal spannend.
Das Installer-Script
– hat einen Clientfilter, kann also einzelne Rechner zulassen oder ignorieren
– räumt alte Reader Installationen auf (Version 9 und 10) – siehe Acrobat & Reader Cleaner Tools
– besitzt umfangreiche Logging-Möglichkeiten
reagiert auf die Fehlercodes 1618 (Installer Prozess wird gerade verwendet), 1602 (Installation vom Nutzer abgebrochen) und 1603 (Installationsfehler) mit einem Retry nach 5 Minuten

Update: 28.07.2015 Version 11.0.12, getestet und läuft.

@echo on & Color 9f & setlocal
set wd=\\server\Deployment\Software\Reader
set log=%wd%\reader-log.txt
set readerEL=999
set retry=0
set forcecleanup=yes
REM:: ******************
set version=11.0.12
REM:: ******************

REM:: Clientfilter: nur die Computer aus der allowedPCs.txt dürfen installieren
::for /f %%f in (%wd%\allowedPCs.txt) do if "%computername%"=="%%f" goto start
::goto end

REM:: Clientfilter: die Computer aus der deniedPCs.txt dürfen nicht installieren
for /f %%f in (%wd%\deniedPCs.txt) do if "%computername%"=="%%f" goto end

:start
if not exist %wd%\deploy\%version%\complete md %wd%\deploy\%version%\complete
if exist %wd%\deploy\%version%\complete\%computername% goto end

if "%forcecleanup%"=="yes" goto cleanup
goto install

:cleanup
echo %date% %time:~0,8% - %computername% deinstalliert alle Reader Versionen... >> %log%
REM:: uninstall all reader versions
start /w %wd%\cleaner\reader-cleaner-9.exe /silent /product=1
start /w %wd%\cleaner\reader-cleaner-10-above.exe /silent /product=1
echo %date% %time:~0,8% - %computername% hat alle Reader Versionen deinstalliert... >> %log%
goto install

:install
echo %date% %time:~0,8% - %computername% startet die Installation... >> %log%
start /w msiexec /i "%wd%\deploy\%version%\AcroRead.msi" /qn TRANSFORMS="%wd%\deploy\%version%\AcroRead.mst"
set readerEL=%errorlevel%

if %readerEL%==1618 goto retry REM:: msiexec process in use, installation already in progress
if %readerEL%==1602 goto retry REM:: user canceled installation
if %readerEL%==1603 goto retry REM:: fatal error, some use it for "already installed" (eg. java)
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%... >> %log%
if %readerEL%==0 md %wd%\deploy\%version%\complete\%computername%
goto end

:retry
if %retry%==1 goto retryfailed
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%, retry in 5min... >> %log%
set retry=1
ping localhost -n 300 > nul
goto install

:retryfailed
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%, retry failed, end >> %log%
goto end

:end
endlocal
exit

Damit das Script funktioniert, braucht ihr allerdings eine spezielle Ordnerstruktur. Ich skizziere sie mal eben schriftlich, ggf. mit Dateien:
Reader\cleaner\reader-cleaner-10-above.exe (Cleanup Tools, umbenannt)
Reader\cleaner\reader-cleaner-9.exe (Cleanup Tools, umbenannt)
Reader\deploy\[version](die in der Batch als Variable gesetzt wird)\[Dateien: AIP,.mst,usw]
Reader\deploy\[version]\complete\

Wenn ihr also in der Batch beispielsweise die Version 11.0.04.63 verteilen wollt, tragt die Version in Zeile 11 so ein und der Ordner lautet:
Reader\deploy\11.0.04.63\
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-deploy-dir

Hier ein Beispielausschnitt der Logdatei:
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-logfile

Probleme mit der Sprache?

acrobat-multilanguage-testsIst das Produkt trotz Anpassung nicht auf Deutsch? Das Problem hatte ich auch und habe einige Stunden mit verschiedensten Tests an der MST, der setup.ini und den MSI Parametern verbracht. So richtig klar wurde mir das alles nicht, ich habe nun aber einige Anpassungstipps, die das Sprachproblem beheben sollten. Lest vorher nochmal die paar Infos des Admin Guides zu den Sprachen, das erleichtert das Verständnis der folgenden Punkte.

Also, MSI in Orca laden, über Transform -> „Apply Transform“ die angepasste MST des Customization Wizards laden und ab in die Property Tabelle.
(Das ginge übrigens auch über den Customization Wizard -> Direct Editor)
Schaut hier nach folgenden Schlüsseln und passt diese ggf. an, um die deutsche Sprache einzustellen:

Propertyalter Wertneuer Wert
ProductLanguage10331031
ISLANGFLAGen_USde_DE
ProductCode{AC76BA86-7AD7-FFFF-7B44-AB0000000001}{AC76BA86-7AD7-1031-7B44-AB0000000001}

(zum Product Code lest bitte den Admin Guide)
Speichert diese Anpassungen über Transform -> Generate Transform am besten in einer seperaten MST.

Editiert dann die setup.ini vorsichthalber, sodass sie nur noch die deutsche Sprache und die neue Transorm enthält:
adobe-reader-scriptbased-deployment-mst-changes-cleaning-logging-setup-ini

[Product]
msi=AcroRead.msi
Languages=1031
1031=German (Germany)	
CmdLine=TRANSFORMS="AcroRead-deu.mst"

Installiert dann den Reader entsprechend dem oben gezeigten Script, dann sollte die Installation die Anpassungen der MST beinhalten und auf deutsch sein.

Kürzer, schneller, härter

Die richtigen Pro’s werden bei den ersten Schritten den Kopf schütteln, „das geht ja alles viel einfacher, schneller, in weniger Schritten“ usw.
Ja, man kann die Anpassungen, AIP und Patches mit viel weniger Schritten abarbeiten. Der Admin Guide hat an vielen Stellen diese komplizierteren Schritte beschrieben.
2 Beispiele:
Gleich am Anfang nach dem Download per Customization Wizard die Version angepasst und dann direkt diesen Befehl genutzt:

msiexec /i AcroRead.msi PATCH="AdbeRdrUpd11001.msp; AdbeRdrSecUpd11002.msp" TRANSFORMS="AcroRead.mst"

Damit wird der angepasste Reader installiert und daraufhin mit den Patches versehen. Mehrere Patches lassen sich wie gezeigt aneinanderreihen, die Pfade sollte man lieber noch ergänzen; habe ich der Übersicht wegen weggelassen.
Oder: alternativ kann man ohne Anpassung auch die wichtigsten Eigenschaften direkt bei der Installation mit den Property-Parametern setzen:

msiexec /i AcroRead.msi PATCH="AdbeRdrUpd11004_MUI.msp" LANG_LIST=de_DE SUPPRESSLANGSELECTION=1 REMOVE_PREVIOUS=YES EULA_ACCEPT=YES SYNCHRONIZER=NO

Die CMD Möglichkeiten beim Erstellen des AIP und der Installation sind vielfältig, aber benötigen auch weit mehr Expertise.
Außerdem machen sie die Fehlersuche viel komplizierter, sollte es während eines 1-Liner zu einem Fehler kommen.
Ich war deswegen immer der Freund von ausführlichen Schritt-für-Schritt Herangehensweisen. Entscheidet selbst.

Viele komplexere Windows Installationen werden von .msi Installern durchgeführt. Diese MSI Datenpakete sind oftmals datenbankähnliche Datenstrukturen, die Informationen und Dateien für eine Installation bereithalten. Der Vorteil dieser Installer ist, dass sie sich, im Gegensatz zu .exe Dateien, einsehen und anpassen lassen. Änderungen an MSI Daten können direkt in der MSI, oder als extra Datei in Form einer .mst Datei, abgespeichert werden. So kann eine Grundinstallation in verschiedenen Formen, also eine .msi mit verschiedenen .mst Anpassungen, ausgeliefert werden.

Mit dem kleinen (retired) Microsoft Tool Orca (Parameter) lassen sich nicht nur .msi Dateien anpassen, sondern auch bestehende .mst Dateien anwenden und analysieren.

orca-msi-editor-standard

Über den Menüpunkt Transform kann man nun neue Änderungsdateien erstellen und speichern oder bestehende laden. Das ist besonders praktisch wenn man eine .mst nicht selber erstellt hat und nachsehen möchte, was konkret verändert wurde.
Beispiel: Adobe Produkte, wie z.B. der Reader oder Acrobat Professional, werden für gewöhnlich vor der Verteilung im Unternehmen mit dem Tool „Adobe Customization Wizard“ angepasst. Dieses Tool erstellt mit den gewünschten Anpassungen (Sprache, Pfad, Serial usw.) eine fertige .mst Datei, mit der man die Verteilung starten kann. Mit Orca kann man nun vorher diese .mst Datei laden und nachsehen, ob soweit alles stimmt.

orca-msi-editor-mst-transform-file-view

Im Fenstertitel sind die verknüpften .msi und .mst Dateien vermerkt, in der Oberfläche sind angepasste, hinzugefügte und entfernte Daten grün markiert. Nützlich, was?

Ich komme später nochmal darauf zurück, in welchen Fällen das besonders sinnvoll sein kann 😉

Ziel ist es in einer beliebigen Datei – der Inhalt sollte aber schon irgendeine Art von Text sein – scriptgesteuert Text oder Zeichen suchen und ersetzen zu können; und zwar ohne Installation von Tools wie grep/sed sondern nur mit dem Script.
Eine pure Batch-Lösung halte ich für zu riskant, da Batch mit zu vielen Sonderzeichen Schwierigkeiten hat. Statt dessen greifen wir auf ein einfaches .vbs Script zurück.

Für Einsteiger: VBS (Visual Basic Script) Scripts sind Batch Scripts sehr ähnlich. Es ist praktisch nur Text in einer Datei mit der Dateiendung .vbs. Ausgeführt werden .vbs Scripts mit folgendem Code aus der CMD heraus, ggf. mit Parametern:

cscript //nologo script.vbs "parameter1"

zeichen-einfachen-text-suchen-ersetzen-vbs-batch-vbs-execution
VBS Scripts, im Vergleich zu Batch, laufen allerdings etwas stabiler, liefern notfalls Fehlermeldungen und bieten auch mehr Features. An dieser Stelle nutzen wir also diese Vorteile aus.

Hier der Code für ein einfaches .vbs Script zum Auslesen einer Datei, Suchen und Ersetzen 3 verschiedener Zeichen/Texte und Schreiben in eine andere Datei:

Set objFSO = CreateObject("Scripting.FileSystemObject")
Const ForReading = 1
Const ForWriting = 2

' Datei öffnen und Text einlesen und schließen
Set objFile = objFSO.OpenTextFile("test.html", ForReading)
strText = objFile.ReadAll
objFile.Close

' Änderungen am Inhalt
strNewText = Replace(strText, """", "'")
strNewText = Replace(strNewText, "lang='de'", "lang='en'")
strNewText = Replace(strNewText, "Hannes Schurig", "Max Mustermann")

' Neue Datei erstellen mit neuen Inhalten füllen
set resultFile = objFSO.CreateTextFile("test-neu.html", true)
resultFile.WriteLine strNewText
resultFile.Close

Relativ straight forward. Hier ein Beispielresultat:
zeichen-einfachen-text-suchen-ersetzen-vbs-batch-simple-script

Für eine bessere Handhabung lässt sich nun dieses Script optimieren. Die Eingabe- und Ausgabedatei könnte man parametirisieren. Wenn immer nur 1 Sache ersetzt werden soll, sich diese aber während der Scriptlaufzeit ändert oder erst währenddessen entschieden wird, könnte man auch diese Daten als Parameter übergeben.

Hier der Code für ein komplexeres .vbs Script:

Set objFSO = CreateObject("Scripting.FileSystemObject")
Const ForReading = 1
Const ForWriting = 2
' Parameter einlesen
inputFile = WScript.Arguments(0)
outputFile = WScript.Arguments(1)
searchText = WScript.Arguments(2)
replaceText = WScript.Arguments(3)

' Datei öffnen und Text einlesen und schließen
Set objFile = objFSO.OpenTextFile(inputFile, ForReading)
strText = objFile.ReadAll
objFile.Close

' Änderungen am Inhalt
strNewText = Replace(strText, searchText, replaceText)

' Neue Datei erstellen mit neuen Inhalten füllen
set resultFile = objFSO.CreateTextFile(outputFile, true)
resultFile.WriteLine strNewText
resultFile.Close

Hier das Resultat:
zeichen-einfachen-text-suchen-ersetzen-vbs-batch-complex-script

Eigentlich recht easy. In meinem nächsten Beitrag werden ich dieses Script nutzen um mit Batch dynamische HTML Reports zu erstellen. Wait for it!

In eigener Sache möchte ich heute kurz den Dienst servercheck24.de unter die Lupe nehmen. Der Dienst ist einer von vielen kostenpflichtigen Server Monitoring Diensten, kann sich in dem Preissegment aber sehen lassen. Im Gegensatz zu vielen Server Monitoring Anbietern hat Servercheck24 gleich 3 Preismodelle und ist somit für viele Anwendungsbereiche geeignet. Es gibt zwar leider kein kostenloses Angebot (was ich definitiv empfehlen würde), eine 14-tägige Testphase kann jedoch einen guten Einblick in die Features geben.
Ich habe mir das mal angesehen.

Coolerweise haben die Betreiber von servercheck24.de direkt nach der Veröffentlichung meines Tests einige angemerkte Stellen ausgebessert und mich informiert. Entsprechende Stellen habe ich im Beitrag angepasst.

Die Registrierung ist schnell gemacht und unkompliziert. Nach der Registrierung bekommt man direkt einen Überblick über die Features. Der „Server“ Menüpunkt ist natürlich die erste Station; hier kann man seinen ersten Server erstellen, bzw. dessen Überwachung. Die Eingabe einer URL ist erforderlich und ein Name wird vergeben.

Vorher: Die Eingabe kann anfangs knifflig werden. Meine ersten Versuche mit http:// am Anfang schlugen direkt fehl, egal welche Kombinationen ich probierte. Viel Hilfe gibt es beim Eingeben auch nicht, so eine Art Formatbeschreibung wie www.[name].[tld] hätte mir ja gereicht. Die URL Eingabe soll nämlich ohne Protokoll sein, nur www. am Anfang. Etwas ungewöhnlich aber verständlich, denn erst im nächsten Schritt wird erst das Protokoll gewählt, dass überwacht werden soll.
Nachher: Die Eingabe der URL sollte problemloser verlaufen, seit dem nun ein kleiner Hinweis unter dem Eingabefeld auf das Format hinweist.
serverueberwachung-uptimechecks-und-mehr-servercheck24-url-neu

serverueberwachung-uptimechecks-und-mehr-servercheck24-overview serverueberwachung-uptimechecks-und-mehr-servercheck24-protocols

Die Protokolle, die man überwachen kann, sind zahlreich. HTTP(S), SSH, FTP, DNS, Mailsprotokolle, TCP, PING, MYSQL, Domains, da ist alles wichtige mit dabei. Von normalen HTTP Abfragen bis hin zu stark modifizierten HTTPS Requests mit Suchbegriffen, Login Credentials, User-Agents, modifiziertem Header und POST Parametern ist da alles einstellbar. Die Möglichkeiten reichen also auch tief in interne, abgesicherte Webbereiche.

Vorher: Traurig: sowohl bei der Eingabe als auch in der Übersicht wird das Passwort der Login Credentials als Klartext dargestellt. C’mon, r’lly? Wenn ein

type="password"

im Eingabefeld schon zu viel Code ist, möchte ich nicht wissen wie die Passwörter in der Datenbank gespeichert sind. Unbedingt ändern!
Nachher: Die Passwörter werden nun maskiert angezeigt, so wie es sich gehört. Die erhöhte Sicherheit wird hoffentlich in der gesamten Programmierung des Dienstes so angestrebt wie bei den Textfeldern.
serverueberwachung-uptimechecks-und-mehr-servercheck24-password1-neu serverueberwachung-uptimechecks-und-mehr-servercheck24-password2-neu

Nach der Eingabe erscheint die Übersicht der Einstellungen, mit den Einstellungen für die Benachrichtigung und den Kontakten, die Benachrichtigungen erhalten sollen. Benachrichtigungen können entweder als E-Mail oder als SMS rausgehen, abhängig vom Status der Webseite. Eine Pager Nachricht ist ebenfalls möglich, sollte jemand noch einen Pager haben.
serverueberwachung-uptimechecks-und-mehr-servercheck24-new-http-pro-server serverueberwachung-uptimechecks-und-mehr-servercheck24-server-overview

Vorher: Leider scheinen SMS bisher nur in den USA möglich zu sein, deutsche Mobilfunkbetreiber sucht man vergeblich.
Nachher: Zugegeben, an dieser Stelle habe ich vermutlich nicht aufmerksam genug geschaut. Die Landesvorwahl +49 für Deutschland ist vorhanden und enthält auch die größeren hiesigen Netzbetreiber. Neu ist jetzt, dass sowohl beim Erstellen eines Accounts als auch beim Bearbeiten von Kontakteinstellungen automatisch die passende Landesvorwahl ausgewählt wird. Ich musste also +49 nicht einmal auswählen; das geschieht jetzt automatisch. Es funktioniert alles problemlos, TOP!
serverueberwachung-uptimechecks-und-mehr-servercheck24-sms serverueberwachung-uptimechecks-und-mehr-servercheck24-sms2

Weitere Protokolle und Server sind schnell erstellt und die eigene Weblandschaft in wenigen Minuten zur Überwachung konfiguriert. Dabei werden alle Protokolle eines Servers in eine „Gruppierung“ gesteckt. Ein neuer Server ist mit seinen Protokollen eine neue Gruppe. Mehrere logisch zusammengehörige Server zu einer Gruppe oder Art Kategorie zusammenzufügen geht leider nicht.
Für die Übersicht aller Server gibt es sowohl eine ausführliche und eine kurze Version.
serverueberwachung-uptimechecks-und-mehr-servercheck24-short-overview serverueberwachung-uptimechecks-und-mehr-servercheck24-detailed-overview

Zwei weitere nette Features sind der grafische Verlauf und der Auswertungsversand.
Ersteres zeigt den Status eines Servers in einem bestimmten Zeitraum grafisch an. Leider lassen sich hier nicht mehrere Protokolle oder Server in eine Grafik packen. Die Daten lassen sich in typische Dateiformate exportieren. Und die Auswertungen sind konfigurierbare regelmäßige Reports per E-Mail.
serverueberwachung-uptimechecks-und-mehr-servercheck24-daily-report serverueberwachung-uptimechecks-und-mehr-servercheck24-grafic-status

Fazit? Servercheck24 bietet ein recht angenehmes Preis-Leistungs-Verhältnis. Wer nicht viele Seiten zu überwachen hat kann mit 5€/Monat schon alle Features nutzen, mit einem 10 Minuten Intervall allerdings. Ich habe mal nach der Konkurrenz gesehen und nur sehr wenige (und auch wenig brauchbare) kostenlose Angebote, dafür aber auch viele recht teure Angebote gefunden.

Vorher: Wenn Servercheck24 jetzt noch die paar Kinderkrankheiten (ich glaube der Dienst ist erst vor ca 2, 3 Jahren online gegangen) ausbessern kann, sehe ich große Chancen in dem Markt.
Nachher: Innerhalb von 1 Tag haben die Entwickler einige Punkte ausgebessert und ich habe das Gefühl, dass in diesen Dienst noch sehr viel Energie fließen wird. Hut ab, Daumen hoch, go for it!

Interessiert? Einfach für einen Tarif registrieren und den Testzeitraum nutzen.

Mit einem PowerShell Script möchte ich alle Login/Logoff basierten Events eines Computers auflisten und gut lesbar in eine Textdatei schreiben. In meinem konkreten Fall filtere ich nur das Entsperren heraus.

Hier das PowerShell Script:

# Connects to the security eventlog of a remote computer and retrieves successful login events ( event ID 528 ) and what type of login took place 
# Information about login types found at http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=528 
# 
# 22.09.2009 Konráð Hall 
# 2013 - edited by Hannes Schurig for newer systems (vista/7/server 2k8) and filter in german/english
cls

"Starte Tool..."
 
$events =  Get-EventLog -ComputerName Hannes-PC -LogName "Security" -newest 1000 | Where { $_.eventid -eq 4624 }

# english: $logonTypeText = "Logon Type:    "
# german:
$logonTypeText = "Anmeldetyp:			"

"Starte Eventverarbeitung..."

foreach ($event in $events) {
    
    if (($event.message | Select-String $logonTypeText+"2")){ 
        "LogonType 2 (Interactive Login);"+ $event.TimeGenerated.DateTime + ";" +$event.UserName >> "C:\logins.txt"
    } <#
    if (($event.message | Select-String $logonTypeText+"3")){ 
        "LogonType 3 (Network Login)    ;"+ $event.TimeGenerated.DateTime + ";" +$event.UserName >> "C:\logins.txt"
    } 
    if (($event.message | Select-String $logonTypeText+"4")){ 
        "LogonType 4 (Batch Login)      ;"+ $event.TimeGenerated.DateTime + ";" +$event.UserName >> "C:\logins.txt"
    } 
    if (($event.message | Select-String $logonTypeText+"5")){ 
        "LogonType 5 (Service Login)    ;"+ $event.TimeGenerated.DateTime + ";" +$event.UserName >> "C:\logins.txt"
    } #>
    if (($event.message | Select-String $logonTypeText+"7")){ 
        "LogonType 7 (Computer Unlocked);"+ $event.TimeGenerated.DateTime + ";" +$event.UserName >> "C:\logins.txt"
    } <#
    if (($event.message | Select-String $logonTypeText+"8")){ 
        "LogonType 8 (Network Cleartext Login);"+ $event.TimeGenerated.DateTime + ";" +$event.UserName >> "C:\logins.txt"
    } 
    if (($event.message | Select-String $logonTypeText+"9")){ 
        "LogonType 9 (NewCredentials)   ;"+ $event.TimeGenerated.DateTime + ";" +$event.UserName >> "C:\logins.txt"
    } 
    if (($event.message | Select-String $logonTypeText+"10")){ 
        "LogonType 10 (RDP Login)       ;"+ $event.TimeGenerated.DateTime + ";" +$event.UserName >> "C:\logins.txt"
    } 
    if (($event.message | Select-String $logonTypeText+"11")){ 
        "LogonType 11 (Cached Credentials Login);"+ $event.TimeGenerated.DateTime + ";" +$event.UserName >> "C:\logins.txt"
    } #>
}

original script by Konrad Hall

Das, ursprünglich von Konrad Hall stammende, Script habe ich etwas angepasst. In Zeile 9 muss der gewünschte Computername eingefügt werden.

Um die Funktionsweise zu verstehen sollte man in Erfahrung bringen welche verschiedenen Anmeldeereignisse und Anmeldetypen es gibt und welche EventIDs sie haben. Es gibt unterschiedliche EventIDs in XP/Server<2k3 und Vista/7/Server>2k3.
Ein Beispiel: erfolgreiche Anmeldungen werden mit der EventID 528 in Server 2k3 und mit 4624 in Server 2k8 geloggt.
tecchannel schreibt zu den vielen IDs auch noch etwas.
Mit ultimatewindowssecurity.com lässt sich das aber überblicken. Meine Beispiele beziehen sich auf Windows 7.

Wenn man sich alle Events des Security Logs anzeigen lässt, ist das eine ganze Menge:
anmeldeereignisse-mit-PowerShell-auslesen-all-events

Es kommt also drauf an, was man loggen möchte. Dann kommt es drauf an, welche EventIDs dieses Event auslöst. Daraus bastelt man sich den EventID Filter.
Mit

| Where { $_.eventid -eq 4624 }

(528 bei XP/2k3) am Ende des Befehls filtere ich erfolgreiche Anmeldungen heraus:
anmeldeereignisse-mit-PowerShell-auslesen-all-logins-4624

Das gleiche geht bei Abmeldungen mit der EventID 4634 (538 bei XP/2k3):

| Where { $_.eventid -eq 4634 }

oder eine Art Range Filter für Login und Logoff:

| Where { $_.eventid -ge 4624 -AND $_.eventid -le 4634 }

anmeldeereignisse-mit-PowerShell-auslesen-logins-and-logoffs

Nun sind also alle Events gefiltert. Diese werden dann in dem Script ab Zeile 17 noch einmal gefiltert. Hier kommen die Anmeldetypen ins Spiel. Diese sind aber bei allen Windows Versionen gleich.
Beispiel: „Normale“ Anmeldungen haben den Typ 2, Netzwerkanmeldungen 3, Entsperren die 7.

An dieser Stelle könnt ihr das Script beliebig anpassen um nur einen oder bestimmte Anmeldetypen zu filtern.
In dem Beispielscript oben sind alle Anmeldetypen bis auf den normalen („interaktiven“) Login auskommentiert. Hier 2 Beispiellogs für Entsperrungen und Entsperrungen+Logins:
anmeldeereignisse-mit-PowerShell-auslesen-logs
Achtung! Auf englischen Systemen müsst ihr die Kommentierung von Zeile 11 und 13 vertauschen, da sonst die Filterung Exceptions schmeißt. Ich habe das ja schon soweit vorbereitet.

Mit diesen Grundlagen könnt ihr beliebig in den Computerlogs (es gibt ja nicht nur die Security Logs) lesen, filtern, exportieren und mehr.

Ich sah letztens ein nettes Video über Curiosity’s Kameras und eine Stelle fand ich sehr verblüffend:
wie macht der Mars Rover solche Fotos?

Definitiv ein Selbstportrait des Rovers. Wie wurde es gemacht? Der Rover stellt ja nicht mal eben so ein Stativ mit Kamera auf den Marsboden, stellt den Selbstauslöser ein und positioniert sich brav.

Nein, dieses Foto wurde mit einem der Arme des Rovers gemacht. Dass dieser Arm auf dem Foto nicht zu sehen ist, wurde mit einem ziemlich cleveren Verfahren erreicht:
http://www.tubechop.com/watch/1256728

Ziel ist es ein Git Repository in ein anderes, leeres Git Repository zu kopieren, inklusiver aller Daten wie z.B. der History. Also das Kopieren / Klonen / Duplizieren eines Repositories inklusive aller Infos. Es reicht also nicht den Ordner nur zu kopieren und in das neue Repository zu pushen, damit hätte dieses Repository nur 1 Commit, nicht aber alle Daten übernommen.

Hier die Abfolge der Schritte:

  1. Das alte Repository „old-repo“ auf der Festplatte auf den aktuellsten Stand bringen; logisch
  2. Einen Ordner für das neue Repository anlegen; der Name des Ordners sollte dem Namen des neuen Repositories entsprechen
  3. Den Inhalt des Ordners „old-repo“ in den Ordner „new-repo“ kopieren
  4. Git Bash in „new-repo“ starten bzw. diesen Ordner in der Bash aufrufen
  5. Git origin neu setzen, Ziel ist das neue Repository:
    git remote set-url origin git@[Server IP/URL]:new-repo
  6. Neuen Master Stand pushen:
    git push origin master

Hier ein Video der Vorgehensweise: