Microsoft 365: warum sich ein Konto nicht anmelden kann und wie Sie es beheben

Das Microsoft-365-Modul verbindet jeden Kundenmandanten mit der Konsole und beantwortet eine konkrete Frage: warum sich dieses Konto nicht anmelden kann. Die Diagnose führt zehn Prüfungen gegen Microsoft aus und drückt das Ergebnis über einen Katalog von 21 Befunden aus, jeder mit festem Schweregrad und einer im Voraus formulierten Empfehlung. Wenn es zu einem Befund eine Behebung gibt, steht die passende Aktion direkt daneben. Das Ergebnis erscheint auf dem Bildschirm und in einem PDF-Bericht unter Ihrer MSP-Marke.

Das Modul öffnet sich aus dem Kundendatensatz heraus, neben den übrigen Informationen zu diesem Kunden. Im Mandanten ist nichts zu installieren, und es werden keine Zugangsdaten des Kunden gespeichert: Die Verbindung wird einmal hergestellt, mit der Zustimmung des Administrators dieses Kunden, und sie lässt sich jederzeit aus der Konsole widerrufen. Die Konsole liest ohne Einschränkungen und schreibt nur das, wozu dieser Administrator zugestimmt hat und was ein Techniker bestätigt hat.

Mandantenverbindung und synchronisiertes Inventar

Die Verbindung wird Mandant für Mandant hergestellt, eine je MSP-Kunde, mit der Zustimmung des Administrators dieses Kunden. Die Anwendung authentifiziert sich mit einem Zertifikat, es gibt also kein gemeinsames Geheimnis, das in jedem Mandanten von Hand rotiert werden müsste.

Jede Synchronisierung holt das Inventar des Mandanten: Benutzer mit ihrem Kontostatus, ihrer letzten Anmeldung und den ihnen zugewiesenen Lizenzen, dazu die von Intune verwalteten Geräte.

Bei jeder Synchronisierung prüft die Konsole außerdem, was sie in diesem Mandanten lesen darf: ob Entra ID P1 vorhanden ist, ob Intune vorhanden ist und ob Defender vorhanden ist. Verweigert Microsoft eine Berechtigung, benennt die Konsole das auf dem Bildschirm, statt den Wert leer zu lassen.

Ein Lizenzablauf erreicht Sie, bevor der Anruf des Kunden kommt

Die Lizenztabelle zeigt je Produkt, wie viele Einheiten gekauft wurden, wie viele zugewiesen sind, wie viele verfügbar sind, das Verlängerungsdatum, die verbleibenden Tage und den Status des Abonnements. Ein verfügbarer Bestand von null wird markiert, und ein negativer wird mit seinem Vorzeichen angezeigt, statt zu einer Null geschönt zu werden.

Interne Dienstabonnements von Microsoft werden von den gekauften getrennt und am Ende der Tabelle unter einer Überschrift zusammengefasst, die sagt, worum es sich handelt. Microsoft stellt eigene kostenlose Abonnements mit Kontingenten von Hunderttausenden Einheiten bereit, die in der Gesamtsumme genau das begraben, wofür der Kunde tatsächlich zahlt. Sie werden nicht versteckt, denn das hieße, einen vorhandenen Wert zu leugnen: Sie werden getrennt ausgewiesen.

Auf dieser Tabelle läuft die Erkennung, und sie löst vier Warnungen aus: die Lizenz, die bald abläuft, mit Stufen bei 30, 15, 7 und 1 Tag und steigendem Schweregrad; das Abonnement, das Microsoft ausgesetzt hat; das Produkt, bei dem keine freien Lizenzen mehr übrig sind; und das Produkt, dem mehr Personen zugewiesen sind, als Lizenzen bestellt wurden. Jede Warnung landet im selben Warnungseingang wie der Rest der Konsole, löst sich von selbst auf, sobald die Bedingung entfällt, und lässt sich stummschalten, ohne zu verschwinden.

Das ist der konkrete Nutzen: Der MSP erfährt, dass eine Kundenlizenz abgelaufen ist oder dass Personen an einem ausgesetzten Abonnement hängen, bevor der Kunde anruft, weil die E-Mail nicht mehr funktioniert. Die drei Fälle, die heute wehtun, also die bereits abgelaufene Lizenz, das ausgesetzte Abonnement und der negative Lizenzbestand, erstellen zusätzlich ein Ticket im Service Desk. Die Ablaufstufen bleiben Warnung und E-Mail: Würde jede Stufe ein Ticket erstellen, bestünde der Service Desk nach einem Monat nur noch aus Lizenzen.

In der Benutzerliste zeigt jede Person, welche Lizenz ihr zugewiesen ist, unter dem kommerziellen Namen und nicht unter der internen Kennung von Microsoft: Microsoft 365 Business Premium statt SPB. Eine Kennung, die der Katalog nicht führt, wird weder versteckt noch leer angezeigt; sie erscheint mit ihrem Rohwert und dem Hinweis, dass der kommerzielle Name nicht katalogisiert ist.

Zehn Prüfungen je Diagnose und 21 katalogisierte Befunde

Jede Diagnose führt zehn Prüfungen gegen Microsoft aus, in dieser Reihenfolge: Dienstzustand, Existenz und Status des Kontos, Lizenzen und Servicepläne, Postfach, Passwortstatus, registrierte Authentifizierungsmethoden, letzte Anmeldungen, Richtlinien für bedingten Zugriff, Benutzerrisiko und Weiterleitungsregeln des Postfachs.

Was diese Prüfungen finden, wird über den Katalog ausgedrückt: 21 Befunde, davon 13 kritisch, 6 mit Handlungsbedarf und 2 rein informativ. Jeder Code trägt seinen Schweregrad und seine Empfehlung, formuliert, bevor der Fall überhaupt existiert, sodass zwei Techniker exakt dieselben Kriterien lesen.

Die Anmeldefehlercodes von Entra ID werden in lesbaren Text übersetzt: Die Konsole hat 16 davon katalogisiert. Ein Code, der nicht in der Tabelle steht, wird weder versteckt noch verworfen; er erscheint mit seiner Rohnummer und dem Hinweis, dass er nicht katalogisiert ist.

Die Diagnose lässt sich als PDF unter Ihrer MSP-Marke herunterladen: mit Ihrem Logo und dem Briefkopf Ihres Unternehmens. Der Name KairosLink taucht an keiner Stelle des Dokuments auf, sodass der Bericht genau so an den Kunden weitergegeben werden kann, wie er heruntergeladen wird.

Beheben Sie dort, wo das Problem sichtbar ist

Die Diagnose endet nicht in einem Bericht. Wenn es zu einem Befund eine Behebung gibt, erscheint die zugehörige Aktion direkt neben dem Befund, in derselben Zeile, in der das Problem zu lesen ist, und außerdem im Menü jedes Kontos in der Benutzerliste. Niemand muss sich merken, wo welche Sache repariert wird, und niemand muss die Diagnose verlassen, um danach zu suchen.

Es gibt drei korrigierende Aktionen auf einem Mandantenkonto, und es sind genau die, die im Code stehen: aktive Sitzungen widerrufen, wodurch die ausgestellten Token ungültig werden und die Person sich auf jedem Gerät und in jeder Anwendung neu anmelden muss; ein deaktiviertes Konto aktivieren, damit die Person wieder in die Dienste von Microsoft 365 kommt; und einen Passwortwechsel erzwingen, der bei der nächsten Anmeldung ein neues Passwort verlangt.

Keine davon läuft auf einen einzigen Klick. Jede führt über eine Bestätigung, die das Konto, den Mandanten und den Kunden benennt, auf den sie wirkt, und die die konkrete Folge für die Person beschreibt: dass sie sich neu anmelden muss, bis hin zur Mail-App auf ihrem Telefon, oder dass ihr aktuelles Passwort nicht mehr funktioniert, sobald sie es ändert. Das ist keine Sind-Sie-sicher-Abfrage, sondern die ausgeschriebene Konsequenz, bevor sie eintritt.

Jeder Versuch wird protokolliert, ob er gelingt oder scheitert, mit dem Techniker, der ihn ausgelöst hat, dem betroffenen Konto, dem Datum und dem Ergebnis. Der Verlauf wird je Kunde gelesen, das Neueste zuerst, und abgewiesene Versuche stehen neben den erfolgreichen: Ein Verlauf, der nur zeigt, was gut gegangen ist, prüft gar nichts. Die Aktion schreibt ihr Ereignis zusätzlich in das Audit-Log der Konsole.

Fehlt eine zugestimmte Berechtigung, läuft die Aktion nicht, und die Konsole benennt die genaue Berechtigung, der im Microsoft-Portal zugestimmt werden muss, zusammen mit der weiter gefassten Berechtigung, die sie ebenfalls freigibt. Die Konsole fügt niemals von sich aus Berechtigungen hinzu: Sie liest die Anwendungsregistrierung in Entra ID nicht und ändert sie nicht. Die Entscheidung darüber, was der Dienstleister im Mandanten tun darf, bleibt immer auf der Kundenseite und fällt im Microsoft-Portal.

Nichts sehen zu können ist nicht dasselbe wie nichts gefunden zu haben

Das ist der Kern des Moduls. Wenn eine Lizenz im Mandanten, eine zugestimmte Berechtigung oder eine Fähigkeit fehlt, sagt die Konsole genau das und benennt den konkreten Grund. Ein fehlender Wert wird nie als negativer Wert dargestellt.

Der klarste Fall ist der Anmeldeverlauf, der Entra ID P1 voraussetzt. Hat der Mandant das nicht, gibt das Modul einen informativen Befund aus, der das erklärt, und schließt die Befunde aus der Diagnose aus, die von diesem Verlauf abhingen: Über das, was nicht eingesehen werden konnte, wird nichts behauptet.

Aus demselben Grund gilt eine Prüfung, die nicht laufen konnte, nie als bestandene Prüfung. Die Diagnose hat dafür einen eigenen Abschnitt, und jede nicht ausgeführte Prüfung steht dort mit ausgeschriebenem Grund: Die Lizenz, die die Prüfung verlangt, fehlt; einer benannten Berechtigung wurde nicht zugestimmt; oder der Bericht von Microsoft kam für den Zeitraum ohne Daten zurück.

Die Zusammenfassung trennt außerdem den Kontext des Mandanten von den Befunden des Kontos. Ein Vorfall oder ein von Microsoft veröffentlichter Diensthinweis erscheint in der Diagnose jeder Person dieses Mandanten identisch; deshalb steht er oben und abgesetzt und zählt nicht in die Zähler des Kontos.

Die Kriterien stehen im Code, nicht in einem Sprachmodell

Das zweite Unterscheidungsmerkmal ist die Reproduzierbarkeit. Die Bewertung ist im Code der Konsole festgeschrieben: Dieselben Daten ergeben immer dieselben Befunde, mit demselben Schweregrad und demselben Text. An den Kriterien ist keine künstliche Intelligenz (KI) beteiligt, weder beim Einstufen noch beim Formulieren.

Diese Kriterien lassen sich prüfen, ohne den Quellcode zu öffnen: Eine Seite der Konsole listet die 21 Prüfungen des Katalogs auf, jede mit ihrem Schweregrad, ihrer Empfehlung und dem Link zur Microsoft-Dokumentation, sofern es einen gibt, dazu die Tabelle der Anmeldefehlercodes.

Der Umfang wird offen erklärt: Die Konsole liest ohne Einschränkungen alles, was der Mandant sie lesen lässt, und schreibt nur das, wozu der Administrator des Kunden zugestimmt hat und was ein Techniker bestätigt hat. Die drei korrigierenden Aktionen sind der einzige Teil des Moduls, der bei Microsoft schreibend eingreift. Diagnose und Synchronisierung fragen ab und zeigen an, und jede Diagnose wird von einer Person auf einem Konto ausgelöst, das diese Person ausgewählt hat.

Häufige Fragen