Archive for the ‘Logging’ Category

Powershell und das Datum bei länderspezifischen Einstellungen

29 September 2018

Die ganzen Datumsfunktionen von Powershell beruhen auf .Net Funktionen. Eigentlich sollte länderspezifische Formatierungen heutzutage keine Rolle mehr spielen, aber je nachdem welche Vorgehensweise man wählt, kann einem das Thema auf die Füße fallen und einen staunend zurück lassen. Ich will hier nicht auf die Details eingehen, das haben schon andere gemacht. Ich möchte nur eine einfache Variante zeigen, mit der man sich helfen kann aus dem Dilemma rauszukommen.

Fangen wir konkret an. Gegeben sei ein beliebiges Datum

$d = Get-Date

Gibt man nun $d aus erscheint dieses

Samstag, 29. September 2018 11:11:01

alles in der korrekte Form, da Get-Culture

LCID             Name             DisplayName
—-             —-             ———–
1031             de-DE            Deutsch (Deutschland)

liefert. Soweit so gut.

Blöd wird es nur, wenn man die Variable $d ausgeben möchte und zwar nicht in der direkten sondern indirekten Form:

$d

Samstag, 29. September 2018 11:11:01

"$d"
09/29/2018 11:11:01

Wie aus heiterem Himmel wird das amerikanische Datumsformat verwendet, genauer gesagt die Culture-Invariant-Form.

Wie lässt sich das Dilemma lösen? Es gibt zwei Möglichkeiten. Eigentlich drei, aber die Dritte Möglichkeit manuell “yyMMdd” usw. anzugeben ist am wenigsten praktikabel, weil man sich da unnötige Abhängigkeiten schafft. Nun zu den zwei Varianten.

Entweder man gibt am Anfang bereits ein Format mit:

$d=get-date -format "G"
$d
29.09.2018 11:11:01
"$d"
29.09.2018 11:11:01

oder man gibt das Format bei der Ausgabe durch Umwandlung bei ToString() mit:

$d=get-date
$d
Samstag, 29. September 2018 11:11:01
"$($d.ToString("G"))"
29.09.2018 11:11:01

Weitere Infos zum Thema findet man hier: https://stackoverflow.com/a/37603732 und hier https://stackoverflow.com/a/30541917. Bei diesem Thema kommt dann noch schnell die ganze Geschichte mit den Cultures hoch: https://stackoverflow.com/questions/49866108/issue-with-english-non-us-culture, wo es auch bei Powershell Core 6.x immer noch offene Punkte gibt: https://github.com/PowerShell/PowerShell/issues/3831 und https://github.com/PowerShell/PowerShell/issues/3833.

Werbeanzeigen

Logging Komponenten bei Windows 10 Updates und Installationen

27 November 2017

Bei Windows gibt es mehrere setupact.log-Dateien. In diesen wird der komplette Update- bzw. Installationsprozess dokumentiert. Bei den Logeinträgen gibt es die sogenannten Logging-Komponenten. Eine Beschreibung von Microsoft https://docs.microsoft.com/en-us/windows/deployment/upgrade/resolve-windows-10-upgrade-errors#log-entry-structure nennt dabei diese Komponenten:

Kürzel Beschreibung
CONX compatibility information
MOUPG main upgrade component?
PANTHR ?
SP setup platform
IBSLIB Image-based Setup (Lib?)
MIG migration engine
DISM Deployment Image Servicing and Management
CSI Component Servicing Infrastructure
CBS Component-Based Servicing

Wie das immer so ist mit den Beschreibungen, enthält die Realität mehr Überraschungen parat. Wenn man ein aktuelles Windows 10 v1709 mittels dieses Scripts

Get-Content .\setupact.log | % {If ($_) { If ($_.Substring(0, 1)) {  If ($_.length -gt 48) { If ($_.SubString(19, 1) -eq ",") { $_.Substring(43, 6)}}}} }| sort -Unique | ? {$_.trim() -gt 0} | % {$_.trim()}

untersucht, dann kommen weitere Logging-Komponenten zum Vorschein:

Kürzel Beschreibung
DIAG diagnose?
DU Driver/device updates
IBS Image-based Setup
SYSPRP System Preparation

Lässt man obiges Script auf eine erfolgreiche Windows 10 Update-Installation los, wo sich die SetupAct.log in C:\Windows\Panther befindet, dann tauchen noch ein paar Komponenten mehr auf:

Kürzel Beschreibung
CMI  
DIAGER diagnose error?
SXS side by side?
TOOL  
UI user interface?

Hier nochmal alle bisher gefundenen Komponenten in einer Tabelle:

Kürzel Beschreibung
CONX compatibility information
MOUPG main upgrade component?
PANTHR ?
SP setup platform
IBSLIB Image-based Setup (Lib?)
MIG migration engine
DISM Deployment Image Servicing and Management
CSI Component Servicing Infrastructure
CBS Component-Based Servicing
DIAG diagnose?
DU Driver/device updates
IBS Image-based Setup
SYSPRP System Preparation
CMI  
DIAGER diagnose error?
SXS side by side?
TOOL  
UI user interface?

Die SetupAct.log kann man an verschiedenen Stellen finden, je nach Phase des Updatevorgangs. Hier die möglichen Verzeichnisse:

Phase Pfad
Down-Level $Windows.~BT\Sources\Panther
OOBE $Windows.~BT\Sources\Panther\UnattendGC
Rollback $Windows.~BT\Sources\Rollback
Pre-initialization (prior to downlevel) Windows
Post-upgrade (after OOBE) Windows\Panther

Für weitere Unternehmungen in Powershell hier die bekannten Komponenten:

$klc="CONX", "MOUPG", "PANTHR", "SP", "IBSLIB", "MIG", "DISM", "CSI", "CBS", "DIAG", "DU", "IBS", "SYSPRP", "CMI",
"DIAGER", "SXS", "TOOL", "UI"

und so kann man feststellen, ob man es mit neuen Komponenten zu tun hat:

Get-Content .\setupact.log | % {If ($_) { If ($_.Substring(0, 1)) {  If ($_.length -gt 48) { If ($_.SubString(19, 1) -eq ",") { $_.Substring(43, 6)}}}} }| sort -Unique | ? {$_.trim() -gt 0} | % {$_.trim()}| % {If (-not ($_ -in $klc)) {$_}}

Nicht schön aber selten ;–)

Raspberry Pi Raspbian Jessie und der Überlauf von /var/log/messages

13 Februar 2016

Hab ich mich eigentlich schon mal über die Flut an unnötigen Windows Ereignisanzeigeeintragungen beschwert? Nun so etwas gibt es auch bei Debian, hier speziell Debian Jessie auf einem Raspberry Pi.

Wenn man sich mittels

cat /var/log/messages

die LOG-Einträge anzeigen lässt, gibt es eine Vielzahl von LOG-Eintragungen mit dem Hiweis:

rsyslogd-2007: action ‚action 17‚ suspended, next retry is Sat Feb 13 20:28:26 2016 [try http://www.rsyslog.com/e/2007 ]

Auf der Seite www.rsyslog.com/e/2007 gibt es auch welche, die das Problem haben, scheint generell so zu sein. Dabei ist wichtig zu wissen, die Nummer 17 im obigen Beispiel kann auch eine andere Zahl darstellen und stellt letzten Endes den Konfigurationseintrag in der config-Datei dar.

Wenn man sich mittels

cat /etc/rsyslog.conf

die Einstellungen anschaut, dann taucht bei der Standardinstallation unten eine Zeile mit |/dev/xconsole auf. Genau hier liegt das Problem.

Um dies zu ändern, ruft man

sudo nano /etc/rsyslog.conf

auf und kommentiert die Zeilen ab daemon.*;mail.*;\ bis |/dev/xconsole mittels # aus. Anschließend muss man noch den rsyslog-Dienst neu starten:

sudo service rsyslog restart

Nun sollte die Log-Datei in Zukunft die wesentlichen Punkte zeigen.

Eigentlich könnte man das Problem auch lösen, indem man für die /dev/xconsole sorgt aber das darf jemand anderes machen…

Noch ein Hinweis: In der conf-Datei sind Dateinamen für die Log-Dateien angegeben. Dort findet man immer wieder die Angabe von – vor dem Dateinamen. Dies bedeutet, dass ein neuer Logeintrag nicht sofort auf die Festplatte geschrieben wird und somit im Falle eines Stromausfalls Eintragungen verloren gehen können: http://www.rsyslog.com/doc/v8-stable/configuration/actions.html#regular-file. Das Minus bedeutet nicht, dass keine LOG-Datei geführt werden soll.

Windowsupdate.LOG unter Windows 10 lesen

6 Dezember 2015

MS hat mal wieder ein Zwangsverbesserung angestoßen und damit vieles wieder komplizierter gemacht. Konnte man früher einfach die Windowsupdate.LOG-Datei aus C:\Windows im Notepad einsehen, so findet man nun den Hinweis:

Windows Update logs are now generated using ETW (Event Tracing for Windows).
Please run the Get-WindowsUpdateLog PowerShell command to convert ETW traces into a readable WindowsUpdate.log.

For more information, please visit http://go.microsoft.com/fwlink/?LinkId=518345

Ich kann mir den Grund schon denken, warum die Umstellung gemacht wurde, nämlich wegen Performance und der Dateifragmentierung vorzubeugen. Vor allem auf Windows IoT Geräten ist immer zu wenig Platz, also warum dann nicht ein bewährtes Format verenden, welches eh Log-Dateien im Zaum hält.

Als bekennender Powersheller hab ich auch kein Problem mit Commandlets, aber wenn dann weite Teile der daraus erzeugten Log-Datei dann so aussieht?

1601.01.01 01:00:00.0000000 1040  13164                 Unknown( 10): GUID=fceb5510-7e12-22d8-8d1b-e6a079483552 (No Format Information found).
1601.01.01 01:00:00.0000000 1040  13164                 Unknown( 26): GUID=464bbb57-7e12-b0a1-8d1b-e6a079483552 (No Format Information found).
1601.01.01 01:00:00.0000000 1040  13164                 Unknown( 10): GUID=fceb5510-d1b3-b0a1-23ef-338952442d14 (No Format Information found).

Wo ist hier der Informationsgehalt?

Wenn es nur Teile betrifft, kann man sich mittels dieses Aufrufs eine einfachere Update.Log erstellen:

Get-Content "$env:USERPROFILE\Desktop\Windowsupdate.log"|Select-String -Pattern "1601.01.01 01:00:00.0000000*" -NotMatch |Set-Content "$env:USERPROFILE\Desktop\Windowsupdate_Clean.log"

Damit erhält man die unsinnigen Fragmente ausgefiltert und die relevanten Daten in Windowsupdate_Clean.log gespeichert. Hier bei den Kommentaren lassen sich einige zum Thema aus: https://technet.microsoft.com/en-us/library/mt238376.aspx.

Leider hat auch Windows 10 V1511 das Problem mit den falschen bzw. unnötigen LOG-Einträgen.

Wer jetzt denkt, er wäre clever und könnte direkt die Inhalte aus den EWT-Dateien auslesen, denn schließlich gibt es ja noch die Funktion Get-WinEvent, welche EWT-Dateien lesen kann, wird ernüchtert feststellen, dass dem nicht so ist. Der Inhalt der mittels EWT erfassten Daten wird in Dateien mit der Endung .ETL gespeichert.

Beim Aufruf von z. B.

Get-WinEvent -Path C:\Windows\logs\WindowsUpdate\WindowsUpdate.20151206.160438.596.1.etl -Oldest

bekommt man genauso das belanglose Geschwafel wie in der erzeugten Windowsupdate.LOG-Datei. Ist das womöglich ein genereller Bug?

Ein weiterer Artikel zum Format und was man damit machen kann und wo auch auf den Symbolserver eingeht: http://blogs.technet.com/b/charlesa_us/archive/2015/08/06/windows-10-windowsupdate-log-and-how-to-view-it-with-powershell-or-tracefmt-exe.aspx.

Microsoft Hyper-V Server 2012 hält sich unnötig mit Loggingaufgaben auf oder wer hat vergessen den Benutzerzugriffsprotokollierungs-Dienst abzuschalten?

22 August 2013

Nachdem ich mich im letzten Blogeintrag schon über die Teredo-Eintragungen in der Eventlog gewundert hatte https://newyear2006.wordpress.com/2013/08/21/microsoft-hyper-v-server-2012-telefoniert-nach-hause-oder-warum-tauchen-auf-einmal-teredo-eintrge-in-der-log-datei-auf/, geht es nun gerade so weiter.

Bei den Application-Eventlogs gab es jede Menge Informationseinträge, hier exemplarisch einer davon:

EventID            : 327
MachineName        : HyperV
Data               : {}
Index              : 7586
Category           : General
CategoryNumber     : 1
EntryType          : Information
Message            : wmiprvse (3496) The database engine detached a database (1, C:\Windows\system32\LogFiles\Sum\SystemIdentity.mdb). (Time=0 seconds) 

                     Internal Timing Sequence: [1] 0.000, [2] 0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6] 0.015, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.016,
                     [11] 0.000, [12] 0.000.
                     Revived Cache: 0
Source             : ESENT
ReplacementStrings : {wmiprvse, 3496, , 1…}
InstanceId         : 327
TimeGenerated      : 21.08.2013 17:55:54
TimeWritten        : 21.08.2013 17:55:54
UserName           :
Site               :
Container          :

Innerhalb einer Sekunde finden sich mehrere Einträge wo einmal die SystemIdentity.mdb attached und anschließend wieder detached wird. Mal abgesehen davon, dass die Eventlog dadurch unübersichtlich wird:

7486 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7485 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7484 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7483 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7482 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7481 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7480 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7479 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7478 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7477 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7476 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7475 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7474 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7473 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7472 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7471 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7470 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7469 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7468 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7467 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7466 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7465 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7464 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7463 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7462 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7461 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7460 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7459 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7458 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7457 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7456 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7455 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7454 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7453 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7452 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7451 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7450 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7449 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7448 Aug 21 11:13  Information ESENT                         327 svchost (1696) The database engine detached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….
7447 Aug 21 11:13  Information ESENT                         326 svchost (1696) The database engine attached a database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity….

Stellt sich die Frage was steckt dahinter?

Bei der Suche nach SystemIdentity.mdb landet man dann irgendwann bei “User Access Logging” oder zu Deutsch “Benutzerzugriffsprotokollierung” http://technet.microsoft.com/en-us/library/hh849634.aspx. Mittels UAL lassen sich jede Menge Daten über den Rechner, Benutzer, Dienste, Rollen usw. sammeln und auswerten. Die NSA und Forensiker haben ihre helle Freude daran. Aber muss so ein Dienst auf einem Microsoft Hyper-V Server laufen? Ich denke nicht! Microsoft selber warnt sogar davor mit diesem Hinweis:

ImportantImportant
UAL is not recommended for use on servers that are connected directly to the Internet, such as web servers on an Internet-accessible address space, or in scenarios where extremely high performance is the primary function of the server (such as in HPC workload environments). UAL is primarily intended for small, medium, and enterprise intranet scenarios where high volume is expected, but not as high as many deployments of Windows Server 2012 that serve Internet-facing traffic volume on a regular basis.

Da ich einen Hyper-V Server als performancekritisch ansehe, sollte man also den Dienst abschalten. Dies erreicht man durch:

net stop ualsvc

netsh ualsvc set opmode mode=disable

oder per Powershell mittels:

Stop-Service ualsvc

Disable-Ual

Interessant bei dieser Geschichte ist mal wieder die geniale Namensgebung des Dienstes auf Deutsch: “Dienst für Benutzerzugriffsprotokollierung”. Das ist mal wieder so ein richtig beknackter Name, der mit Dienst anfängt, wo man nie draufkommt, ähnlich wie “Automatische Drahtlos…”. Pfeifen halt.

http://technet.microsoft.com/en-us/library/jj574126 beschreibt noch jede Menge Dinge, wie: was passiert, wenn der Dienst Probleme hat oder welche Powershell CmdLets für die Abfrage der Daten verfügbar sind. Es wird auch noch die Bedeutung des Verzeichnis \Windows\System32\Logfiles\SUM\ beschrieben und dass dieses auch gelöscht werden könnte.