XML-Abfrage Ereignisanzeige
Die Filter für die Windows Ereignisanzeige (Eventlog) sind sehr mächtig geworden. Mit den standard Optionen in der grafischen Oberfläche kann man schon viel machen, aber leider nicht im Nachrichtentext filtern. Das geht auch mit XML Abfragen. Klicken Sie dazu zunächst einmal auf ein ähnliches Ereignis und klicken Sie dort die Detailansicht an. Dort wählen Sie XML View:
Dann erstellen Sie einen benutzerdefinierten Filter und wählen dort den Reiter XML. Setzen Sie das Häkchen bei Abfrage manuell bearbeiten. Wenn Sie bereits bei Filter Reiter Einstellungen gemacht haben, sind diese auch schon im XML hier vordefiniert. Haben Sie z.B. das Anwendungslog ausgewählt steht dort:
<QueryList>
<Query Id=“0″ Path=“Application“>
<Select Path=“Application“>*</Select>
</Query>
</QueryList>
Oben habe ich Sie den XML-View auswählen lassen. Warum? Dort sehen Sie, wie die jeweiligen Felder nach denen Sie suchen können benannt sind. Um nun also z.B. nach dem Benutzernamen zu suchen ergänzen Sie die XML Zeilen wie folgt:
<QueryList>
Id=“0″ Path=“Security“>
<Select Path=“Security“>*</Select>
*[EventData[Data[@Name=‘TargetUserName‚] and (Data=‘s‚)]]
</Select>
</Query>
</QueryList>
Selbstverständlich dürfen Sie das gerne weiter verkomplizieren:
*[EventData[Data[@Name=’SubjectUserName‘] and (Data=’abc‘ or Data=’123’)]]
Dies würde alle mit der Angabe abc oder 123 finden bei UserName finden.
Möchten Sie in mehreren Logs suchen:
<Select Path=“Security“>*[System[(EventID=’1234′)]]</Select>
<Select Path=“Application“>*[System[(EventID=’4321′)]]</Select>
Würde alle Ereignisse aus dem Eventlog Security mit der ID 1234 und alle Ereignisse aus dem Applicationlog mit der ID 4321 anzeigen.
Um die Filter in der PowerShell zu nutzen können Sie die XML-Abfrage genauso in einen String schreiben und mit Get-WinEvent abfragen:
$Query=@“
<QueryList>
Id=“0″ Path=“Security“>
<Select Path=“Security“>
*[EventData[Data[@Name=’TargetUserName‘] and (Data=’s‘)]]
</Select>
</Query>
</QueryList>
„@
$Evts=Get-WinEvent -log Security -FilterXPath $Query -maxevents 1000
Microsoft Outlook Configuration Analyzer Tool 2.11
Das Microsoft Outlook Configuration Analyzer Tool 2.1 führt eine Analyse Ihrer Outlook Profile durch und hilft bei Problemen.
WINSAT liefert „Mondwerte“
Wenn winsat zuverlässige Werte liefern würde, wäre es echt ein cooles Tool. Winsat ist ein Windows Bordmittel um auf der Kommandozeile Leistungsdaten von CPU, Festplatte und vielen anderen Dingen zu erfassen. Das habe ich doch gleich einmal an einem Einzelplatzsystem ausprobiert:
Hier fällt schon bei den ersten beiden Messungen auf, dass Winsat würfelt. Der erste Test war ein Lesezugriff der 17 Sekunden benötigt hat und dabei angeblich eine Transferrate von 128 MB/s (bitte vergeben Sie mir die Rundungsungenauigkeit 😉 ). Der zweite Test war ein Schreibtest mit derselben Datenmenge auf demselben Laufwerk. Der braucht wie erwartet länger, als der Lesetest nämlich 37 Sekunden, also 20 Sekunden mehr. Witzig daran ist, dass der Durchsatz dabei angeblich auf stolze 435 MB/s gestiegen ist. Eine Festplatte, die 4 x so schnell schreibt wie liest. Ich glaube ich sollte meinen PC patentieren lassen oder einem Museum übergeben. Das Beste daran ist, das er sogar auf 1464 MB/s hoch geht. Schade ist nur, dass die Werte wohl kaum der Realität entsprechen.
Systeminformationen von Windows auslesen
Mit der Freeware CW-Systeminfo können Sie viele Informationen Ihres Windows-Systems in Erfahrung bringen. Dazu zählen, CPU, Speicher, BIOS, aber auch z.B. den Windows Produkt-Key im Klartext u.v.a.m.
Pagerank durch mehr Geschwindigkeit verbessern
U. a. bewertertet Google die Geschwindigkeit mit der Websites ausgeliefert werden. Es gibt einen Haufen Verbesserungen um die Geschwindigkeit der Website zu steigern. Welches Tuningpotential in Ihrer Website steckt finden Sie unter:
https://developers.google.com/pagespeed
heraus. Um das CMS/Blogsystem Wordpress zu tunen schauen Sie in diesen Artikel.
Soll ich bei IIS 7.x den Usermode-, oder den Kernelmodecache aktivieren, oder beide?
Die Antwort lautet wie üblich: Es kommt ganz darauf an! 😉
Fakten: Kernelmodecache ist schneller als Usermodecache, da ein Übergang in den Usermode immer viel Zeit kostet! Wenn ein Webserver im Normalfall ca. 550/s Anfragen schafft, so werden daraus bei aktiviertem Usermodecache ca. 650/s, bei Kernelcache 950/s. Aktiviert man bei geht er knapp über 1000/s. Allerdings hat man dafür nicht immer genug Speicherreserven.
Des Weiteren ist es davon abhängig wie IIS mit der jeweiligen Website arbeitet. Wird von der Webanwendung mehr im Usermode gearbeitet, ist es sinnvoller den Usermodecache zu aktivieren, arbeitet Sie mehr im Kernelmode, natürlich lieber den Kernelcache. Dazu muss man allerdings wissen, wie die jeweilige Webanwendung tickt. Das verrät der folgende Powershell-Befehl:
Get-WmiObject win32_process | ? {$_.caption -eq "w3wp.exe"} | select commandline,usermodetime,kernelmodetime | fl
Ausgabe sind alle Workerprozesse vom IIS. Dabei wird als erstes angezeigt, welcher Applicationpool sich hinter dem Workerprocess versteckt und danach folgen die Zeiten die er sich im User und im Kernelmode aufhält. Anhand dieser Zahlen kann man sehr schön festlegen, welche Cacheart die sinnvollere für den jeweiligen Applicationpool und den damit verknüpften Websites ist. Zugegeben ,man hätte das ganze noch viel eleganter Lösen können am besten gleich mit der automatischen Cachekonfiguration. Aber das war eben mal so auf die Schnelle Quick & Dirty eben ;-).
Terminalserverprofilepath mittels Powershell abfragen
Benutzer aus dem AD (Active Directory) mit Powershell auszulesen ist nicht besonders schwierig. Alles was man dazu braucht ist entweder einen DC (Domänencontroller) oder einen Client mit installiertem AD-Modul für Powershell aus den RSAT (Remote-Server-Administration-Tools) und natürlich die Powershell Version 2.0 oder höher.
Mit dem Befehl get-aduser Benutzername erhält man aber nur einen kleinen Teil der Benutzereigenschaften. Wenn Sie mal richtig aufdrehen wollen (alle Eigenschaften haben) müssen Sie erst noch einmal etwas nachhelfen: get-aduser Benutzername -properties *. Leider ist der Pfad, den mal eventuell im Terminalserver bzw. Remotedesktopdienste -Profilepfad angegeben hat dort nicht wirklich auszulesen. Es gibt im LDAP zwar extra das Attribut msTSProfilePath doch legt Microsoft dort überhaupt nichts ab!!! Der Profilepfad ist im Attribut userParameters mit viel anderem Krempel leider codiert hinterlegt. Nichts desto trotz kann man hier wenigstens feststellen ob der TS Profilpfad beim Benutzer angegeben wurde, oder nicht. Das unten aufgeführte Script sollte weiter helfen. Wünschen Sie Verbesserungen/Anpassungen hinterlassen Sie einen entsprechenden Kommentar.
function SetTSProperties()
{
$ou = [adsi]"LDAP://ou=mytestou,dc=nwtraders,dc=com"
$user = $ou.psbase.get_children().find($userDN)
$user.psbase.invokeSet("allowLogon",1)
$user.psbase.invokeSet("TerminalServicesHomeDirectory",$hDirValue)
$user.psbase.invokeSet("TerminalServicesProfilePath",$ppValue)
$user.psbase.invokeSet("TerminalServicesHomeDrive",$hdValue)
$user.setinfo()
} #end SetTSProperties
function QueryTSProperties()
{
$ou = [adsi]"LDAP://ou=mytestou,dc=nwtraders,dc=com"
$user = $ou.psbase.get_children().find($userDN)
foreach($property in $aryTSProperties)
{
"$($Property) value: $($user.psbase.invokeget($Property))"
} #end foreach
} #end QueryTSProperties
$userDN = "CN=My User"
$hDirValue = "\\Hamburg\TSUsers\Home\TestUser"
$hdValue = "t:"
$ppValue = "\\Hamburg\TSUsers\Profiles\TestUser"
$aryTSProperties="allowLogon","TerminalServicesHomeDirectory",
"TerminalServicesHomeDrive","TerminalServicesProfilePath"
SetTSProperties
queryTSProperties
Anwendungsinstallation unter Windows überwachen
TrackWinstall kann eine Anwendungsinstallation unter Windows (ab W2k -> Windows 2000,XP,2003,Vista,7,2008) überwachen. Jegliche Änderungen die während der Installation am Dateisystem oder der Registry vorgenommen werden schreibt TrackWinstall in eine Protokolldatei.
Bin ich Admin?
Seit Vista stellt sich man sich bei Windows oft die Frage, ob man denn nun gerade ein vollwertiger Administrator ist, oder nicht. Das kann man mit dem Befehl whoami /groups herausfinden. Das kann u.U. ein Weilchen dauern (das Längste was ich einmal gewartet hatte waren 20 Minuten)!! Normaler Weise der unterste Gruppeneintrag gibt Aufschluss über die sog. Verbindlichkeitsstufe. Als „normaler“ Benutzer hat man in der Regel die Verbindlichkeitsstufe Mittel mit der SID S-1-16-8192. Als Admin mit vollwertigen Systemrechten hingegen Hoch und der SID S-1-16-12288. Testen können Sie das, wenn Sie als normaler Benutzer angemeldet cmd und Enter im Suchfeld (nicht im Ausführen-Feld!) des Startmenüs eintippen und dann den o.g. Befehl eintippen. Parallel können Sie den Vorgang noch einmal wiederholen, aber dieses Mal bestätigen Sie cmd nicht einfach nur mit Enter, sonder drücken dazu noch Strg+Shift. Wenn Sie es richtig gemacht haben, sollte die UAC anspringen und um Bestätigung bitten. Wenn Sie den Befehl whoami nun hier eintippen sollte im Gegensatz zur 1. Eingabeaufforderung Hoch herauskommen.
Programme oder Program Files?
Seit Windows Vista, macht NTFS schon recht seltsame Dinge. Wenn man so ganz normal auf Laufwerk C: schaut, stellt man fest, dass es dort einen Ordner Benutzer gibt. Stellt man unter Extras/Ordneroptionen auch versteckte und Systemdateien zur Anzeige ein, tauchen auf einmal auch Dokumente und Einstellungen und Dokuments and Settings auf, die früheren Speicherorte für Benutzerprofile. Besonders lustig wird es, wenn man dann eine Kommandozeile auf macht und dir auf Laufwerk C: eintippt, denn dann nennt sich der Ordner wieder anders nämlich Users. Ich glaube dämlicher hätten Sie es wirklich nicht anfangen können!
Zum Teil ist dafür die desktop.ini im jeweiligen Verzeichnis verantwortlich. Die sieht man natürlich auch erst, wenn man System und versteckte Dateien anzeigen lässt. Benennen Sie die Datei doch einfach (voller Admin notwendig) einmal um und schauen Sie wie sich der Ordner dann auch in der normalen Ansicht repräsentiert. Ist die Datei versehentlich gelöscht worden, können Sie einfach auf einem anderen System mit einem Texteditor schauen was da normaler Weise drin steht und erneut auf dem System mit der fehlenden desktop.ini ein solche anlegen oder einfach rüber kopieren. Das weckt natürlich Begehrlichkeiten da nun selbst drin rum zu basteln…tun Sie’s nicht – es sei denn Sie wollen einen Kollegen vernichten ;-).