Eine fehlgeschlagene Anmeldung ist zunächst eine Beobachtung. Ob die Ursache beim Benutzerkonto, bei der Serverkonfiguration oder bei einem anderen Aufrufweg liegt, lässt sich aus einem einzelnen Screenshot oft nicht erkennen. Ein kurzer, sauber abgegrenzter Fehlerbericht hilft Ihrer IT und dem Support, gezielt weiterzuarbeiten.
Den betroffenen Weg benennen
Notieren Sie, ob der Fehler beim Öffnen der Weboberfläche, bei der Anmeldung, beim Zugriff auf ein Projekt oder bei einem anderen Aufruf auftritt. Halten Sie verwendete Programmversion, Browser, Zielumgebung und genaue Uhrzeit einschließlich Zeitzone fest. Unterschiedliche Wege können unterschiedliche Voraussetzungen haben.
Mit einer kleinen Vergleichsmatrix beginnen
| Prüfung | Beobachtung festhalten |
|---|---|
| Derselbe Benutzer, derselbe Aufruf | Ist der Fehler reproduzierbar? Wortlaut und Uhrzeit notieren. |
| Ein berechtigtes Vergleichskonto | Gleicher Fehler oder abweichendes Ergebnis? Keine fremden Zugangsdaten verwenden. |
| Betroffene und funktionierende Umgebung | Version und Konfiguration getrennt vergleichen; Produktivsystem nicht versuchsweise umbauen. |
Passende Protokolle zuordnen
Bitten Sie den zuständigen Administrator, die zum Aufrufzeitpunkt passenden Anwendungs- und Serverprotokolle zu prüfen. Ein Logeintrag gehört nur dann zum Fehler, wenn Zeit, Umgebung und Aufruf zusammenpassen. Fehlende Einträge sind ebenfalls eine Information; sie beweisen keine bestimmte Ursache.
Das Handbuch zur Protokollierung beschreibt die Protokollierung der Windows-Anwendung. Übertragen Sie deren Menüpfad nicht ungeprüft auf einen IIS-Webserver. Für die Webbereitstellung gilt die Anleitung zur Installation und Konfiguration Ihrer eingesetzten Version. Zusätzliche Protokollierung nur gezielt für die Untersuchung verwenden und anschließend mit der IT wieder auf den vorgesehenen Betriebszustand zurückstellen.
Konfiguration nicht auf Verdacht ändern
Ändern Sie Authentifizierungsmodule, Zugriffsrechte oder Schlüssel nicht allein deshalb, weil ein ähnlicher Fall im Internet so gelöst wurde. Zuerst den aktuellen Stand sichern, die belegte Hypothese benennen und einen rücknehmbaren Einzelversuch im passenden Testsystem festlegen. Ein erfolgreicher Versuch ersetzt weder die Freigabe noch die Gegenprobe in der Zielumgebung.
So sieht eine brauchbare Übergabe aus
Fiktives Beispiel: „Weboberfläche, Testsystem, Version [eintragen]. Am [Datum] um [Uhrzeit/Zeitzone] tritt beim Öffnen von [Aufrufweg] die Meldung [Wortlaut] auf. Zweimal mit demselben Ergebnis wiederholt. Vergleichskonto: [beobachtetes Ergebnis]. Letzte bekannte funktionierende Nutzung: [Zeitpunkt oder unbekannt]. Seitdem bekannte Änderungen: [Liste oder unbekannt]. Passende Protokollstelle: [durch IT geprüft oder noch offen].“
Passwörter, API-Schlüssel, vollständige Konfigurationsdateien und unnötige personenbezogene Projektdaten gehören nicht in einen frei weitergegebenen Fehlerbericht. Vereinbaren Sie mit Ihrer IT beziehungsweise dem Support einen geeigneten Übertragungsweg für erforderliche Diagnosedaten.