Azure Root Cause Analysis kurz RCA

18 Dezember 2014

Wieder was dazu gelernt. Nach dem gestrigen Artikel http://newyear2006.wordpress.com/2014/12/17/microsoft-azure-ausfall-von-vms-storage-und-weiteren-diensten-am-18-11-2014-bzw-19-11-2014/ bin ich heute noch über den Begriff RCA gestolpert. RCA steht für Root Cause Analysis. Muss man sich merken, denn darüber werden in Zukunft die Azure Probleme dargestellt und näher analysiert. Der Blogeintrag ist gestern irgendwie an mir vorbei oder war noch nicht erschienen. Auf jeden Fall wird alles nochmal deutlich beschrieben: http://azure.microsoft.com/blog/2014/12/17/final-root-cause-analysis-and-improvement-areas-nov-18-azure-storage-service-interruption/

Schade ist nur, dass im Blogeintrag Verbesserungen in der Kommunikation angekündigt werden, ohne konkret eine offizielle Twitteradresse oder alternative Seite zu nennen.

Microsoft Azure Ausfall von VMs, Storage und weiteren Diensten am 18.11.2014 bzw. 19.11.2014

17 Dezember 2014

Alles strebt in die Cloud aber was, wenn die Cloud bockt? Microsofts Azure hatte am 18. bzw. 19.11.2014 einen größeren Ausfall. Dabei ging es nicht um Sekunden, Minuten oder Stunden, nein es ging um teilweise zwei Tage!

Hier der Link zum Blogeintrag: http://azure.microsoft.com/blog/2014/11/19/update-on-azure-storage-service-interruption/. Die Sache war sogar so heftig, dass auch Kunden ohne Wartungsvertrag sich an Microsoft wenden durften.

Hier eine tiefergehende Erläuterung des Vorgangs von Mark Russinovich: http://channel9.msdn.com/posts/Inside-the-Azure-Storage-Outage-of-November-18th.

Was mich an der Sache stört, ist, dass davon auf heise.de nichts zu hören war. Es handelt sich ja nicht um einen kurzen Ausfall sondern war mit zwei Tagen ja schon heftiger. Hier gibt es keinen Newseintrag, wenn man sich den Zeitraum vom 18./19. November anschaut: http://www.heise.de/suche/?q=azure&search_submit=Suchen&rm=search&channel=newsticker. Stellt sich die Frage, hat es keiner bemerkt oder durfte nicht berichtet werden? Andere Newsseiten haben darüber berichtet: http://www.computing.co.uk/ctg/news/2382347/microsoft-azure-suffers-huge-outage-affecting-websites-and-office-365.

Wenn man die Abhängigkeiten von Office365 in Bezug auf Azure kennt, dann sollte doch da eine kritische Masse erreicht worden sein oder nicht? Der Link bei www.computing.co.uk spricht zumindest von Problemen mit Office365.

Auf jeden Fall war das perfide an der Sache, dass die offizielle Azure-Statusseite http://azure.microsoft.com/en-us/status/#current über mind. drei Stunden nicht den tatsächlichen Status der Azure Cloud wiedergegeben hat, sondern dass alles OK wäre. Auch von der Statusseite abhängige APIs waren davon betroffen. Dies wird im Channel9 Video von Mark Russinovich auch nochmal angesprochen. So verstehen sich dann auch die teilweisen harschen Reaktionen im Kommentarbereich des Azure-Blogartikels. Da sind Stunden mit der Fehlersuche verbracht worden, weil die Statusanzeige ja grün war, also liegt das Problem woanders. Aber wo? Und wie kann man als kleine IP-Adresse in der Riesenwolke etwas nachvollziehen bzw. debuggen? Da wird der fähigste Administrator kalt gestellt. Aber das ist unsere Zukunft!

Ich zitiere hier einen Kommentar zum Vorgang, der die Probleme schön illustriert:

ripvannwinklera month ago

Blah blah blah. As others have said:

1. The dashboard inaccurately reflected service status nearly the entire time. A status dashboard should not be a publicity mechanism. If it doesn’t work, fix it. You suck.

2. The outage should have NEVER been rolled out across data centers like it was. I don’t care if infrastructure designs required it – you messed up.

3. I have clients seriously questioning our decision to use Microsoft Azure. It’s upon Microsoft’s head to make this right. BS explanations do nothing to rectify lost time and money or compensate my clients. That falls on me, and as a customer, what reason could I possibly have to trust Azure not to let it happen again in the future?

This is NOT ENOUGH. If you think it is, maybe we should just throw in the Azure towel now?

So ein Ausfall stellt sich dann (gelbe Markierungen von mir) in der Historie der Azurestatusseite als

11/19

Multiple Azure Services – Multiple Regions – Partial Service Interruption

From 19 Nov, 2014 00:52 to 04:40 UTC a subset of customers using Storage, Virtual Machines, SQL Geo-Restore, SQL Import/export, Websites, Azure Search, Azure Cache, Management Portal, Service Bus, Event Hubs, Visual Studio, Machine Learning, HDInsights, Automation, Virtual Network, Stream Analytics, Active Directory, StorSimple, Azure Site Recovery and Azure Backup Services in North Europe, Japan East and Japan West experienced connectivity issues. This incident has now been mitigated.

11/19

Multiple Azure Services – Multiple Regions – Partial Service Interruption

From 19 Nov, 2014 00:52 to 05:10 UTC a subset of customers using Storage, Virtual Machines, SQL Geo-Restore, SQL Import/export, Websites, Azure Search, Azure Cache, Management Portal, Service Bus, Event Hubs, Visual Studio, Machine Learning, HDInsights, Automation, Virtual Network, Stream Analytics, Active Directory, StorSimple, Azure Site Recovery and Azure Backup Services in East US 2, South East Asia and East Asia experienced connectivity issues. This incident has now been mitigated.

11/19

Websites – West Europe – Advisory (Limited Impact)

Starting at 19 Nov 2014 00:52 UTC a subset of customers using Websites in West Europe may have experienced partial service degradation. Engineering reported as mitigated at 11:45AM UTC and continued to monitor until 12:45 PM. This issue is now mitigated.

11/19

Storage – West Europe – Partial Service Interruption

From 19 Nov, 2014 00:52 to 09:15 UTC a subset of customers using Storage in West Europe may have experienced intermittent connectivity issues. This incident has now been mitigated. Further information is available to potentially impacted customers through the Azure Management Portal – http://manage.windowsazure.com

11/19

Application Insights – Multi-Region – Advisory

From 19 Nov 2014 at 01:00 to 12:34 UTC, Application Insights customers using the Azure Preview Portal (portal.azure.com) experienced higher than normal data latency. Please visit the Visual Studio Online blog at http://blogs.msdn.com/b/vsoservice/archive/2014/11/19/issues-with-application-insights-services-11-19-mitigating.aspx for additional information. This incident has now been mitigated.

11/19

Virtual Machines – North Europe – Advisory

This issue is now mitigated for North Europe. We continue to investigate and address issues impacting a limited subset of Virtual Machines customers in West Europe. A subset of customers may see their VMs in continual "Start state”, and limited subset of customers may have difficulty in connecting to their VMs. Potentially impacted customers are advised to continue to visit the Management Portal http://manage.windowsazure.com for more frequent regional details.

usw. dar. Im letzten Statuseintrag sogar ganz ohne Stundenangabe. Der Phantasie darf freien Lauf gelassen werden, wie lange eine VM ausfallen konnte.

Kommen wir zum wahrscheinlich wichtigsten Punkt: Wie kann man die Cloud testen? Ein Datacenter kann man evtl. noch nachbilden und ein Testdatacenter aufbauen um kritische Infrastrukturupdates prüfen zu können. Aber wie kann man die Cloud, welche sich global ausbreitet, testen? Ist doch einfach, man nehme eine zweite Erde für Testzwecke…

Wenn Maus und Tastatur an einem Windows Rechner nicht mehr reagieren

14 Dezember 2014

Ein Kunde hatte ein Problem mit seinem Windows 7 Rechner. Das interessante daran war, dass Tastatur und Maus nicht mehr funktionierten, wenn Windows hochgefahren war. Er hatte die Passworteingabe beim Hochfahren deaktiviert, so dass der Rechner immer bis zum Desktop bootete. So konnte man schon beobachten, dass alles sauber geladen wurde nur am Ende war keinerlei Maus und Tastatureingabe möglich. Der Mauszeiger konnte nicht einmal bewegt werden.

Der Rechner konnte problemlos durch drücken des Ausschaltknopf sauber heruntergefahren werden. Die Maus und Tastatur konnten an anderen Ports eingesteckt werden und es erschien die Meldung, dass Treiber installiert werden und dass das Gerät nun benutzt werden kann. Jedoch war dies nie möglich.

Bei weiteren Versuchen stellte es sich heraus, dass auch eine PS/2-Tastatur nicht funktionierte. Ein generelles Hardwareproblem konnte aber ausgeschlossen werden, da Maus und Tastatur problemlos unter WindowsPE oder im BIOS funktionierten. Ein weiterer Aspekt war, dass Multimediatasten wie E-Mail, Calculator usw. einer Multimediatastatur auch funktionierten.

Ein Starten des Rechners im abgesicherten Modus brachte leider auch nichts.

Also alles neu installieren? Nein.

Zwei Dinge helfen:
Die Verwendung der erweiterten Startoptionen und Aufruf von Computer reparieren. http://windows.microsoft.com/de-de/windows/advanced-startup-options-including-safe-mode#1TC=windows-7. Hier kann man die Systemwiederherstellung aufrufen, damit ein früherer Zustand aktiviert werden kann, der funktionierte – soweit vorhanden.

Die zweite Lösung wäre das entfernen von Kaspersky Maus und Tastaturtreibern. Dazu musste man nur in der Registrierung unter Upperfilters nach klkbdflt und klmouflt suchen und diese entfernen. Detailliert hier beschrieben: http://support.kaspersky.com/general/products/10663#block7. Diese Lösung funktionierte, weil der Kunde davor versucht hatte Kaspersky zu installieren und dabei scheinbar etwas schiefgegangen war. Hat man die Kaspersky-Treiber entfernt, stehen nur noch kbdclass und mouclass in der Registrierung. Übrigens muss man nicht zwingend die Kaspersky Rescue Disk verwenden, sondern kann auch mit einem WinPE oder Windows Bootmedium booten und die Registrierungseinträge darüber ändern.

Für Powershell .Net Framework Tracing aktivieren

13 Dezember 2014

Manchmal ist nicht klar warum etwas nicht funktioniert. Da Powershell stark auf das .Net Framework angewiesen ist, kann man auch dessen Trace-Möglichkeiten nutzen, um eine tiefergehende Fehleranalyse zu ermöglichen. Hilfreich ist das Tracing z. B. in Verbindung mit der Netzwerkkommunikation.

Unter .Net kann man das Netzwerktracing wie in diesem Artikel beschrieben aktivieren: http://msdn.microsoft.com/en-us/library/ty48b824(v=vs.110).aspx. Damit der Trace-Mitschnitt in Powershell aktiviert werden kann, muss die in der betreffenden Powershellversion die Datei Powershell.exe.config angelegt, bzw. bearbeitet werden. Dabei ist von Bedeutung, ob man mit Powershell 32-Bit oder 64-Bit arbeitet. Zum Thema Powershell 32-/64-Bit siehe hier: http://newyear2006.wordpress.com/2012/06/20/prfen-ob-eine-powershell-sitzung-in-einer-32bit-oder-64bit-prozess-umgebung-luft/.

Kurz: Unter einem 64-Bit System findet man die 64-Bit Powershell-Version unter C:\WINDOWS\SYSTEM32\WINDOWSPOWERSHELL\V1.0 und die 32-Bit Powershell-Version unter C:\WINDOWS\SYSWOW64\WINDOWSPOWERSHELL\V1.0. Auf einem reinen 32-Bit-System ist der Pfad wieder wie bei der 64-Bit Fassung.

Wenn man nun also seine Powershell.exe.config, die so aussieht

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

   <system.diagnostics>

        <sources>

            <source name="System.Net">

                <listeners>

                    <add name="System.Net"/>

                </listeners>

            </source>

            <source name="System.Net.Sockets">

                <listeners>

                    <add name="System.Net"/>

                </listeners>

            </source>

        </sources>

        <switches>

            <add name="System.Net" value="Verbose" />

            <add name="System.Net.Sockets" value="Verbose" />

        </switches>

        <sharedListeners>

            <add name="System.Net"

                type="System.Diagnostics.TextWriterTraceListener"

                initializeData="System.Net.log"

                />

        </sharedListeners>

        <trace autoflush="true" />

    </system.diagnostics>

</configuration>

im Verzeichnis C:\Windows\System32\WindowsPowershell\V1.0\ angelegt hat, kann man anschließend Powershell starten. Wichtig, die Einstellungen wirken sich erst aus, wenn eine neue Powershell.exe gestartet wird.

Man bekommt nun in der Datei System.Net.Log die Trace-Daten gespeichert. Die System.Net.Log wird in dem Verzeichnis der Powershell.exe gespeichert.

Möchte man die Trace-Möglichkeit in Powershell-ISE nutzen, muss man natürlich die Datei Powershell_ise.exe.config bearbeiten.

Das Format der Trace-Daten ist kurz hier angerissen: http://msdn.microsoft.com/en-us/library/46fcs6sz(v=vs.110).aspx.

Lambdas in Powershell

5 Dezember 2014

Ein sehr guter Artikel wie man Lambdas in Powershell nachbilden kann: http://www.powershellmagazine.com/2013/12/23/simplifying-data-manipulation-in-powershell-with-lambda-functions/

Im Prinzip wird ein einfacher Scriptblock verwendet. Der im Artikel beschriebene Ansatz verwendet gleichzeitig den ab Powershell 3.0 verfügbaren Abstract Syntax Tree um Parameter der übergebenen Lamda-Ausdrücke zu prüfen. Der Call-Operator & erlaubt dann das Ausführen der Lambda-Ausdrücke.

Fehlermeldung von Windows Fax und Scan wegen fehlendem Faxkonto bei Druck über Faxserver

26 November 2014

Bekommt man an einem Windows Client beim Druck über einen Faxserver folgende Fehlermeldung an den Latz geknallt:

—————————

Windows-Fax und -Scan

—————————

Sie müssen erst ein Faxkonto erstellen, um Faxe mit dem ausgewählten Drucker senden zu können. Suchen Sie nach "Computer zum Senden und Empfangen von Faxen einrichten" in Hilfe und Support", um weitere Informationen zu erhalten.

—————————

OK  

—————————

 

So kann man sich behelfen, indem man zunächst bei Windows Fax und Scan im Menü unter Extras->Faxkonten den bestehenden Eintrag entfernt. Anschließend das Programm zumachen und noch bei Drucker und Faxgeräten den betreffenden Druckertreiber, der fürs Faxen über den Server eingerichtet war, über “Gerät entfernen” loswerden.

 

Nun wieder über Windows Fax und Scan über das Extra-Menü Faxkonten aufrufen, Hinzufügen anklicken und “Verbindung mit einem Faxserver im Netzwerk herstellen” auswählen. Dann den Servernamen eingeben usw. Danach sollte es ohne obige Fehlermeldung klappen.

Windows Azure Pack Ressourcen

23 November 2014

Die wohl umfassendste Seite zum Thema Windows Azure Pack, es wird kein Thema ausgelassen. Dadurch ist es generell eine der umfassendsten Seite zu Microsoft Azure Themen.

http://social.technet.microsoft.com/wiki/contents/articles/20689.the-windows-azure-pack-wiki-wapack.aspx

Fehlende Cmdlets in Powershell durch Polyfills nachbilden

17 November 2014

In der HTML5-Welt sind Polyfills ein fester Begriff. Es geht um das Nachrüsten von Funktionen, die in bestimmten Browsern nicht vorhanden sind. Die Definition stammt von Remy Sharp einer der Größen in der HTML5/Javascript-Welt https://remysharp.com/2010/10/08/what-is-a-polyfill.

Was hat das mit Powershell zu tun? Auch in Powershell haben wir das Problem, dass Microsoft es wegen Menpowerproblemen oder strategischen Gründen nicht geschafft hat, Cmdlets aus Windows 8 zurückzuportieren für Windows 7. Ein Beispiel ist Rename-Printer. http://technet.microsoft.com/en-us/library/hh918360.aspx. Oder ein neues kommendes Cmdlet ist Expand-Archive aus Windows 10, welches sicher auch auf alten Windows Versionen benötigt wird.

Polyfills, sogenannte Drop-in Polyfills, wie im Buch “Building Polyfills” von Brandon Satrom definiert, prüfen, ob eine bestimmte Funktion vorhanden ist, wenn diese fehlt, wird diese nachimplementiert. Ist die Funktion bereits vorhanden, so wird die bestehende native Funktion verwendet. In Powershell kann man genau dieses verhalten nachbilden.

Zunächst muss man herausfinden, ob ein bestimmtes Cmdlet verfügbar ist. Zunächst sollte dazu das zugehörige Modul geladen werden. Als zweites sollte dann mittels Get-Command abgefragt werden, ob das betreffende Cmdlet vorhanden ist.

Die Prüfung, ob Rename-Printer vorhanden ist, sieht z. B. so aus:

if (-not (Get-Command Rename-Printer -ErrorAction SilentlyContinue))
{
       # Rename-Printer ist nicht vorhanden
}

Wichtig dabei ist der Parameter –ErrorAction SilentlyContinue, der dafür sorgt, dass wenn das Cmdlet nicht vorhanden ist, keine Fehlermeldung erscheint.

Wie könnte nun ein konkreter Nachbau von Rename-Printer aussehen? Früher hatte man so etwas über WMI gelöst, demzufolge kommen diese Zeilen dem Ziele nahe:

$Filter = "Name=’$($Name)’"
$prn = Get-WMIObject Win32_Printer -Filter $Filter
$res = $prn.RenamePrinter($NewName)
#res.ReturnValue -eq 5 wenn Access Denied, bei 0 OK

Nun möchte man ja aber im Skript konkret das Cmdlet Rename-Printer nutzen, ohne jedesmal per if-Abfrage in Erfahrung zu bringen, ob das Cmdlet vorhanden ist oder ob die alternative Implementierung aufgerufen werden soll. Dazu definiert man in einem Scriptblock das fehlende Cmdlet und führt diesen über den & Call-Operator aus.

$polyfill = {Function Rename-Printer() {"Ersatz für Rename-Printer"}}
&  $polyfill

Wenn man nun unter Windows 7 versucht diesen Aufruf auszuführen passiert nichts, denn Rename-Printer wird nicht gefunden, da die definierte Funktion nur in einem reduzierten Scope zu sehen ist. Um dieses Problem zu lösen, verwendet man explizit den globalen Scope:

$polyfill = {Function Global:Rename-Printer() {"Ersatz für Rename-Printer"}}
&  $polyfill

Nach diesem Aufruf steht nun Rename-Printer zur Verfügung.

Nun gilt es nur noch obige Dinge zu kombinieren, dann erhält man folgendes Cmdlet Polyfill für Powershell um z. B. Rename-Printer nachzubauen:

# Rename-Printer geht nur unter Win8 oder höher, benötigt Admin-Rechte

if (-not (Get-Command Rename-Printer -ErrorAction SilentlyContinue)) {

# damit die Function verfügbar wird, muss sie mittels & ausgeführt werden und mit dem Scope global: versehen werden

&{

Function global:Rename-Printer ($Name, $NewName) {

$Filter = "Name=’$($Name)’"

# anstatt Name doch DeviceID?

$prn = Get-WMIObject Win32_Printer -Filter $Filter

$renres = $prn.RenamePrinter($NewName)

# renres.ReturnValue == 5 wenn Access Denied, bei 0 erfolgreich

}

}

}

Als Template kann man dieses Skelett sehen:

if (-not (Get-Command CmdletName -ErrorAction SilentlyContinue)) {
  &{ Function global:CmdletName ($Parameter) {
             # CmdletName – Nachbau
        }
    }
}

Durch Powershell Polyfills erreicht man bessere und schönere Skripte, da nur zu Beginn notwendige evtl. nicht vorhandene Cmdlets nachgebaut werden müssen. Ein Skript, welches unter Windows 8 läuft, kann somit ohne umschreiben auch direkt auf Windows 7 laufen. Selbst wenn später ein Update doch noch die Unterstützung für das betreffende Cmdlet auf Windows 7 bringen sollte, so wird automatische das dann nativ zur Verfügung stehende Cmdlet verwendet.

VirtualBox Probleme mit 64-Bit Gast und das Ding mit dem Client-Hyper-V

31 Oktober 2014

Als bekennender Hyper-Vler bin ich über ein Problem gestoßen. Es ging darum eine virtuelle Maschine zu haben, über die man problemlos auf den USB Port losgehen kann. Leider ist da Hyper-V auch in aktuellen Ausprägungen nicht so der Bringer. Also nimmt man einen anderen VM-Host, wie in diesem Fall VirtualBox von Oracle: https://www.virtualbox.org/.

Nach der Installation war es aber nicht möglich ein 64-Bit Gastsystem aufzusetzen. Nach dem üblichen Überprüfen der BIOS-Einstellungen, damit auch die nötigen Virtualisierungseinstellungen aktiv waren, funktionierte es immer noch nicht. Dann diesen Artikel gelesen: https://forums.virtualbox.org/viewtopic.php?f=1&t=62339. Aha Hyper-V! Aber der läuft doch gar nicht!?!?

PS C:\Windows\system32> Get-Service -DisplayName *hyper*

Status   Name               DisplayName
——   —-               ———–
Stopped  vmicguestinterface Hyper-V-Gastdienstschnittstelle
Stopped  vmicheartbeat      Hyper-V-Taktdienst
Stopped  vmickvpexchange    Hyper-V-Datenaustauschdienst
Stopped  vmicrdv            Hyper-V-Remotedesktopvirtualisierun…
Stopped  vmicshutdown       Hyper-V-Dienst zum Herunterfahren d…
Stopped  vmictimesync       Hyper-V-Dienst für Zeitsynchronisie…
Stopped  vmicvss            Hyper-V-Volumeschattenkopie-Anforderer
Stopped  vmms               Hyper-V-Verwaltung für virtuelle Co…

PS C:\Windows\system32>

Dann Hirn eingeschaltet und an BCDEdit erinnert, dass es dort zig Einstellmöglichkeiten zum Hyper-V gibt. http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202(v=vs.85).aspx.

OK, dann mal nachgeschaut:

bcdedit /enum

Dabei wurde folgendes ausgegeben:

Windows-Startladeprogramm
————————-
Bezeichner              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 8.1
locale                  de-DE
inherit                 {bootloadersettings}
recoverysequence        {4b6f8314-5573-15e4-b299-de2a5ae3ac48}
integrityservices       Enable
recoveryenabled         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4b6f8312-5575-15e4-b299-de2a5ae3ac48}
nx                      OptIn
bootmenupolicy          Standard
hypervisorlaunchtype    Auto

Ja alles klar. HypervisorLaunchtype steht auf Auto und sollte entweder nicht da sein oder auf Off stehen.

Hier wird beschrieben wie man einen weiteren Eintrag im Bootmenü generieren kann: http://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx

Dadurch kann man beim Rechnerstart auswählen, ob der Hyper-V Hypervisor aktiviert werden sein soll oder nicht.

Entscheidend dabei sind:

C:\>bcdedit /copy {current} /d "No Hyper-V" 
The entry was successfully copied to {ff-23-113-824e-5c5144ea}.

C:\>bcdedit /set {ff-23-113-824e-5c5144ea} hypervisorlaunchtype off
The operation completed successfully.
Dadurch wird ein weiterer Eintrag ins Bootmenü geschrieben. Die GUID
ff-23-113-824e-5c5144ea sieht aber bei jedem anders aus. Es stellt nur
eine eindeutige Kennung dar.

Da aktuelle Rechner recht schnell beim Booten sind, hilft ein weiterer BCDEdit Befehl in Zukunft den richtigen Eintrag beim Start automatisch auszuwählen:

bcdedit.exe /bootsequence {ff-23-113-824e-5c5144ea}


shutdown.exe /r /t 0 /f

Damit wird der Rechner mit dem neuen Bootmenüeintrag gestartet.

Man könnte dies nun über Powershell automatisieren aber der BCD WMI Provider hat so scheinbar seine Tücken: https://social.technet.microsoft.com/Forums/scriptcenter/en-US/18094085-781f-4649-8ff8-331388097911/how-to-get-boot-configuration-data-bcd-information-out-of-wmi-with-powershell?forum=ITCG

Sich schnell über die Zuverlässigkeit eines Rechners informieren mittels des Verlauf der Zuverlässigkeitsüberwachung

23 Oktober 2014

Seit Windows Vista bereits gibt es die Zuverlässigkeitsüberwachung. Für Commandliner kann der Status so aufgerufen werden:

control  /name "Microsoft.ActionCenter" /page pageReliabilityView

Hier ein Beispielbild was angezeigt werden könnte:

image

Interessant dabei sind die roten umkreisten X-Eintragungen. Diese sind auf unterschiedlichen Ebenen. Doch was hat die jeweilige Ebene für eine Bedeutung?

Die oberste Ebene stellt Probleme mit Anwendungen dar. D. h. jedes mal wenn eine Anwendung abstürzt und nicht regulär beendet wird, erfolgt dort ein Eintrag.

Die Ebene darunter stellt Probleme von Windowskomponenten dar, wie z. B. Bluescreens.

Die nächste Ebene darunter stellt ganz einfach dar, wenn Windows einfach abgeschaltet wurde. D. h. Strom weg oder den Ausschalter länger als 4 Sekunden gedrückt.

Zusammenfassend gilt:

Ebene Symbol Bereich
1 Kritisch Anwendungsprobleme
2 Kritisch Windowsprobleme (Bluescreen, Treiber etc.)
3 Kritisch Stromausfall oder Freeze
4 Warnung Warnungen z. B. über fehlgeschlagene Updates
5 Info Informationen z. B. erfolgreiche Updates

Übrigens kann man auf die Zuverlässigkeitsdaten auch per Powershell und WMI zugreifen: http://newyear2006.wordpress.com/2009/12/14/powershell-windows-7-zuverlssigkeitsabfrage-grafisch-dargestellt/


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.