Abgelegt unter: Erkenntnisse | Tags: Error500, IIS, ReportingPoint, SCCM, Server2008R2
Wie ich im letzten November geschrieben habe, aktualisieren immer mal wieder Anwendungen auf neue Versionen. Wenn derartige Deployments von Anwendungsupdates alle Child-Sites betreffen, steuern wir diese aus unserer Central Site. Und damit auch die Administratoren der Child-Sites bequem kontrollieren können, welche ihrer Clients noch nicht aktualisiert wurden, wollte ich diesen einige vorkonfigurierte Reports zur Verfügung stellen. „Vorkonfigurierte Reports?“
Die meisten Reports werden ja mit irgendwelchen Parametern aufgerufen, so z.B. auch der Report „Computers with specific software registered in Add Remove Programs“, den ich zu diesem Zwecke herangezogen habe. Dieser Report will nun mit Parametern für den „Software Title“ (d.h. den Namen, unter welchem die Software eingetragen ist) und die auszuwertende Collection aufgerufen werden. Und diese Werte jedesmal nachzuschlagen, finde ich noch ziemlich mühsam, denn gerade beim „Software Title“ muss der exakte Wert angegeben werden, ansonsten der Report ein leeres Ergebnis liefert. Hat man nun den gewünschten Report erhalten, lassen sich noch die Spalten wunschgemäss sortieren. Dann findet man in der Adresszeile des Browsers die genaue URL, welche diesen Report generiert, d.h. irgendwas in der Form:
http://<siteserver>/SMSReporting_<sitecode>/Report.asp?ReportID=92&displayname=<genaue%28!%29%20Bezeichnung%20der%20Software>&CollID=<collection>&SortRs1Col=1&SortRs1Dir=1
Kennt man diese URL, lässt sich der entsprechende Report jederzeit wieder mit den aktuellen Daten neu generieren, ohne dass man wieder umständlich die passenden Parameter zusammensuchen muss. Und diese URL lässt sich also als Lesezeichen im Browser ablegen, oder – wie ich das vorgesehen hatte – auf einer Intranetseite verlinken. Und so suchte ich alle notwendigen URLs zusammen, erstellte die Intranetseite, testete erfolgreich alle Links und kontaktierte einen unserer Admins einer Childsite, damit er sich das mal ansehen möge. Doch am anderen Ende der Telefonleitung blieb die grosse Freude aus. Stattdessen hiess es nur: „Aehemm…. ich erhalte da bloss einen Error 500!“
Bei mir funktionierten immer noch alle Links perfekt, beim Kollege Child-Site-Admin jedoch nicht. Sogleich vermutete ich ein Rechteproblem, denn bei uns haben alle Child-Site-Admins ausschliesslich Adminrechte für ihre eigene Site und bloss ein Leserecht für die Central-Site und alle anderen Sites. Doch die Rechte in SCCM waren korrekt vergeben; auch nach mehrmaligem Nachkontrollieren kam ich zum Schluss, dass der Kollege alle benötigten Rechte haben müsste, um die Reports abrufen zu können. Doch irgendwas klemmte da noch immer…
Doch dann fiel mir ein: „Error 500!“. Das bedeutet ja üblicherweise nicht „Access denied“, sondern „Internal Server Error“! Also warf ich mal einen Blick in das Webserver-Protokoll und wurde da tatsächlich fündig:
Error 500: ASP_0178_:_80070005|Server.CreateObject_Access_Error
Nach längerer Suche fand ich dann eine Diskussion über ein Problem „Error accessing reporting services – DCOM“ in den Microsoft Technet Foren. Als Lösung wird dort die Deaktivierung der „User Account Control“ vorgeschlagen, was ich allerdings nicht unbedingt tun wollte. Doch im letzten Beitrag schrieb der Benutzer „EddieAdams“:
I was having the exact same problem but solved it by adding ‚Authenticated Users‘ to the local ‚SMS Reporting Users‘ group on the SCCM Server.
Das war ein einfacher Lösungsvorschlag, den ich sofort umsetzte. Doch der Kollege sah weiterhin bloss „Error 500!“
Also suchte ich weiter und stiess dann auf den Artikel „Error message when you try to use the SMS Web Reporting Tool: „Server object error ‚ASP 0178 : 80070005′““ in der Microsoft Knowledge Base. Dieser beschreibt exakt das angetroffene Problem, bezieht sich zwar explizit auf den Server 2003 SP1, führte aber auch unter Server 2008 R2 zur Lösung:
This problem occurs because the following conditions are true:
- You are a member of the SMS Reporting Users security group on the Windows Server 2003 SP1-based computer that is acting as the SMS site server.
- You are not a member of the local Administrators group on the Windows Server 2003 SP1-based computer that is acting as the SMS site server.
In this case, the DCOM permissions are locked down on the Windows Server 2003 SP1 site server.
Genau dies trifft im vorliegenden Fall zu: Mein Kollege Child-Site-Admin ist zwar nun Mitglied der Gruppe „SMS Reporting Users“, seit ich dort „Authenticated Users“ hinzugefügt hatte, doch ist er keineswegs lokaler Administrator unseres Central-Site-Servers. Und so setzte ich die im Artikel beschriebene Anleitung um:
- Log on to the Windows Server 2003 SP1 computer that is acting as the SMS site server by using an account that has administrative permissions.
- Click Start, click Run, type dcomcnfg, and then click OK.
- In the Component Services MMC snap-in, expand Component Services, expand Computers, right-click My Computer, and then click Properties.
- In the My Computer Properties dialog box, click the COM Security tab.
- Under Launch and Activation permissions, click Edit Limits.
- In the Launch Permission dialog box, make sure that the Everyone group has Remote Launch and Remote Activation permissions.
- In the Component Services MMC snap-in, expand My Computer, expand DCOM Config, right-click SMS_Reporting_Point, and then click Properties.
- In the SMS_Reporting_Point Properties dialog box, click the Security tab. Under Launch and Activation Permissions, select Customize, and then click Edit.
- In the Launch Permission dialog box, make sure that the SMS Reporting Users local group has following permissions:
- Local Launch
- Remote Launch
- Local Activation
- Remote Activation
Component Services -> SMS_Reporting_Point Properties -> Launch and Activation Permissions
Und tatsächlich: Nun können auch die Administratoren unserer Childsites die von mir vorbereiteten Reports auf dem Central Site Server abrufen!
Abgelegt unter: Erkenntnisse | Tags: Bluescreen, Harddisk Failure, KB307545, LSASS, RecoveryConsole, SATA, WindowsXP
Ein Besitzer eines Notebooks vom Typ HP Pavilion dv9000 meldete sich bei mir und fragte nach Hilfe: Er könne Windows nicht mehr starten, stattdessen erscheine die Meldung, dass die Festplatte überprüft werden müsse. Lasse er dies zu, beginne die Festplattenüberprüfung, bliebe jedoch kurz darauf stehen, worauf stundenlang nichts mehr geschehe. Breche er die Festplattenüberprüfung ab, erscheine kurz darauf eine Meldung mit weisser Schrift auf blauem Grund:
STOP: c0000218 {Registrierungsdatei fehlgeschlagen} Die Registrierung konnte die Struktur(datei): \SystemRoot\System32\Config\SOFTWARE oder ihr Protokoll oder ihre Alternative nicht laden
Rasch war diese Beobachtung reproduziert und nach einer kurzen Suche fand ich den Microsoft KB-Artikel 307545, der genau diese Meldung beschreibt. „Das Problem scheint bekannt, die Reparaturanleitung ist in der Microsoft Knowledge Base zu finden“, sagte ich, „also nix wie los!“
Die vom Benutzer mitgelieferte Windows-CD wurde eingelegt, von dieser gebootet und bei der entsprechenden Dialogmeldung mit „R“ die Wiederherstellungskonsole gestartet. Aber oha:
Es konnten keine installierten Festplattenlaufwerke gefunden werden.
Stellen Sie sicher, dass alle Festplattenlaufwerke eingeschaltet und richtig mit dem Computer verbunden sind, und dass alle Hardwareeinstellungen für die Festplatten korrekt sind. Hierzu können Sie beispielsweise ein Diagnose- oder Installationsprogramm des Herstellers ausführen.
Die Installation kann nicht fortgesetzt werden. Drücken Sie die F3-Taste, um die Installation abzubrechen.
Hoppla! Ist die Festplatte derart komplett hinüber, dass sie nicht einmal gefunden wird? Nein, da es sich um ein HP Pavillion dv9000 (genauer gesagt das Modell „dv9097ea“) handelt, sind darin SATA-Disken eingebaut. Und mit SATA-Disken kann die Installationsroutine von XP von Haus aus nicht umgehen, weshalb eine entsprechende Treiberdiskette benötigt wird. Und genau diese war natürlich nicht vorhanden…
Also war ein Besuch auf der Homepage von Hewlett-Packard fällig, wo ich nach dem passenden Treiber suchte: Aber nix da, das Modell „dv9097ea“ ist unbekannt: „Wir konnten Ihr Produkt nicht finden“. Doch nach einem expliziten Wechsel zur Homepage „Schweiz – Deutsch“ von HP konnte dann das fragliche Gerät tatsächlich lokalisiert werden und der passende Treiber „für den „Intel SATA AHCI-Controller“ lokalisiert werden. Flugs lud ich auf meinem Desktopsystem, das unter Windows Vista läuft, das Treiberpaket „sp32478.exe“ herunter, kramte mein altes USB-Floppy hervor und suchte nach einer leeren Diskette.
Das Treiberpaket wurde entpackt und die Generierung der Treiberdiskette gestartet. Doch kurz darauf durfte ich auf meinem Vista-System eine weitere Fehlermeldung bestaunen:
„Windows Error N.5Â Zugriff verweigert“.
Nach einer längeren Suche fand ich in einem Forum folgenden Hinweis:
When you load up the WinImage file (the exe for creating disk image) make sure you run it without having a floppy in the drive. It will search, and come back with floppy not found. Now insert the floppy disk, and click retry. And voila, it writes the image to the disk!!!!
Tatsächlich: Auch wenn dieser Tipp ziemlich auf den ersten Blick ziemlich abstrus erschien, klappte auf diesem Weg die Erstellung der Diskette. Allerdings nicht im ersten Versuch, denn ich musste ziemlich suchen, bis ich in meinem Fundus noch eine Diskette fand, auf welche sich das Image tatsächlich extrahieren liess. Tja, „neue 3.5-Zoll-Disketten“ ist nichts, was bei mir noch im Dutzendpack herumliegen würde…
Nun ging es also zurück ans Notebook, diesmal bewaffnet mit USB-Floppy und passender Diskette. Auf diese Weise bekam ich nun den benötigten SATA-Treiber eingebunden und konnte nun auf dem Gerät die Wiederherstellungskonsole starten. Und schon stand ich vor der nächste Hürde: „Wie lautet das Administrator-Passwort“?
Rasch waren drei Fehlversuche erreicht und das Gerät startete neu. Nach einigen weiteren, zeitaufwendigen Extrarunden stellte sich dann heraus, dass das Administrator-Passwort schon dasjenige war, welches der Benutzer ursprünglich vermutete, allerdings war dessen Aussage „besteht nur aus Kleinbuchstaben“ ziemlich falsch.
Endlich konnte ich also loslegen und führte die Befehle aus, die im Microsoft KB-Artikel 307545 im Abschnitt 1 unter Punkt 5 dokumentiert sind. Funktionierte fast alles bestens, doch beim allerletzten Befehl brach der Kopiervorgang der Datei „C:\windows\repair\default“ mit einer Fehlermeldung ab. Tja, aber glücklicherweise wurde ja mit dem ersten Set von Befehlen ein Backup der Dateien erstellt, welches ich dann sofort zurückkopierte.
Aber da war ich wieder am Anfang angelangt: Beim Startversuch wurde die Festplattenüberprüfung gestartet, welche weiterhin kurz nach dem Start hängenblieb. Brach man diese ab, wurde man sogleich mit einem Bluescreen bestraft. Aber immerhin wusste ich nun, dass ich drei Sätze der Registrierungsdateien hatte: Die defekten Registrierungsdateien in „C:\windows\system32\config“, die unbrauchbaren in „C:\windows\repair“ und eine Kopie der defekten in „C:\Windows\tmp“. Was nun?
Ich startete wieder die Wiederherstellungskonsole und versuchte, dort „chkdsk.exe“ auszuführen, doch auch in der Wiederherstellungskonsole blieb chkdsk bei 26% hängen und machte nicht mehr weiter. Also versuchte ich es mit einer Reparaturinstallation. Diese startete problemlos, bis zum Punkt „Festplatte wird überprüft“. Dass diese Prüfung bei 26% hängenblieb, und die Reparaturinstallation nicht mehr weitermachen wollte, wunderte mich schon fast nicht mehr.
Tja, da war ich ziemlich ratlos. Die Anleitung im Microsoft-KB-Artikel war nicht umsetzbar, chkdsk.exe blieb andauernd hängen, die Reparaturinstallation funktionierte auch nicht. Was konnte ich noch tun? War wirklich die Festplatte hinüber?
Mehr zufällig schaute ich mal noch in den BIOS-Einstellungen herum und entdeckte da die Option „Native SATA-Support“, die auf „enabled“ stand. So änderte ich diese auf „disabled“ und startete das Gerät neu. Wiederum wurde beim Starten von Windows die Festplattenüberprüfung angemahnt, und – siehe da! – diese blieb nicht mehr hängen. Unzählige Meldungen der Art „Fehler im Index … der Datei … werden berichtigt“ und weitere Meldungen ratterten vorüber, dann war die Festplattenprüfung abgeschlossen, Windows startete durch und…
… die nächste Fehlermeldung war auf dem Bildschirm zu lesen:
Lsass.exe: „Einem Dienst oder einer Funktion wurde ein ungültiger Parameter übergeben“.
Die Recherche förderte einzig zu Tage, dass man sich doch bitte schön an den eingangs zitierten Microsoft KB-Artikel 307545 halten solle. Einfach die fünf Registrierungsdateien wieder aus dem Repair-Verzeichnis ins Config-Verzeichnis kopieren, dann würde es schon wieder gehen. Tat es aber im vorliegenden Falle nicht, denn egal wieviele Male die Dateien noch kopierte: Auch mit frisch aus dem Repair-Verzeichnis kopierten Dateien gabs erneut den LSASS-Fehler, diejenigen im TMP-Verzeichnis waren von Anfang an defekt und weitere Kopien gabs schlicht und einfach nicht.
Hier war nun das Ende der Fahnenstange erreicht, denn diese Lsass-Fehlermeldung tauchte nun auf, egal was ich versuchte: Normaler Windows-Start, Start im abgesicherten Modus, Start im abgesicherten Modus (nur Eingabeaufforderung). Selbst beim Versuch, eine Reparaturinstallation durchzuführen, tauchte die LSASS-Fehlermeldung nach dem ersten Neustart auf, mit welchem vom textbasierten Setup in die graphische Oberfläche gewechselt wird, worauf die Reparaturinstallation abbrach. Tja: Die weisse Fahne wurde gehisst, eine Neuinstallation war trotz allen Reparaturversuchen fällig!
Fazit:
Manchmal hat man einen Microsoft KB-Artikel vor sich, bei dem man davon ausgeht, dass er exakt zum aktuellen Problem passt:
- Die beschriebene Fehlermeldung passt exakt,
- der Artikel passt zum vorhandenen Betriebssystem,
- die beschriebene Lösung scheint sinnvoll zu sein.
- und Erinnerungen im Hinterkopf lassen vermuten, dass man derartige Probleme doch schon früher mehrfach und erfolgreich auf exakt diese Art und Weise gelöst hat.
Frohen Mutes startet man also mit der Reparatur. Und dann kommt doch alles anders…
Epilog:
Nach einer Neuinstallation von Windows XP habe ich die Festplatte – es handelt sich um eine Western Digital WD3200BEVT (d.h. nicht um die Platte, mit welcher das Notebook von HP ursprünglich ausgeliefert wurde) – mit der Windows-Version der „Western Digital Data LifeGuard Diagnostics“ (die DOS-Version bzw. das bereitgestellte ISO-Image wollten sich auf keine Art und Weise starten lassen) auf vorhandene Probleme untersucht:
Test Option:Â Â Â QUICK TEST
Model Number:Â Â Â WDC WD3200BEVT-00ZAT0
Unit Serial Number:Â Â Â WD-WX80A89X….
Firmware Number:Â Â Â 01.01A01
Capacity:Â Â Â 320.07 GB
SMART Status:Â Â Â PASS
Test Result:Â Â Â FAIL
Test Error Code:Â Â Â 06-Quick Test on drive 1 did not complete! Status code = 07 (Failed read test element), Failure Checkpoint = 97 (Unknown Test) SMART self-test did not complete on drive 1!Test Option:Â Â Â EXTENDED TEST
Model Number:Â Â Â WDC WD3200BEVT-00ZAT0
Unit Serial Number:Â Â Â WD-WX80A89X….
Firmware Number:Â Â Â 01.01A01
Capacity:Â Â Â 320.07 GB
SMART Status:Â Â Â PASS
Test Result:Â Â Â FAIL
Test Error Code:Â Â Â 08-Error was detected while repairing bad sectors.
Diese Testergebnisse sind deutlich genug: Die Festplatte dürfte kaputt sein, ein Austausch ist fällig.
Nachtrag (17.01.2011): Inzwischen habe ich auch eine entsprechende Antwort vom Western Digital Support erhalten: Bei den festgestellten Testergebnissen sei die Festplatte tatsächlich ein Garantiefall und solle über den Verkäufer oder direkt bei WD ausgetauscht werden.