Küstennebel 0 Geschrieben 13. Dezember 2017 Melden Teilen Geschrieben 13. Dezember 2017 Moin, wir hatten vor einigen Wochen unseren alten Windows Server 2003 auf's Altenteil geschickt und gegen einen Server 2016 ersetzt. Der 2016er wurde der Domäne hinzugefügt und zum DC hochgestuft. Dann wurden alle FSMO Rollen übertragen und der 2003er zum Memberserver herabgestuft. Lief alles ohne Probleme. Auch die Ereignisanzeige ist bis auf einen einzelnen DCOM Fehler, der einmal pro Tag auftaucht, sauber. Laut diversen Internetbeiträgen kann man diesen aber wohl ignorieren. Die Domänenfunktionsebene (und Gesamtfunktionsebene) läuft noch auf 2003. Diese soll die Tage noch auf 2012 hochgestuft werden. Der DC ist der einzige DC in der Domäne (über den Sinn eines zweiten DC bitte jetzt an dieser Stelle nicht diskutieren. Der Vorteil eines Zweiten ist uns bewusst. Die Mittel sind aber begrenzt) Es melden sich um die 15 Clients an der Domäne an. Heute morgen nun folgende Situation: alle Netzlaufwerke waren nicht mehr verfügbar (Der DC ist auch unser File Server). Die Anmeldung der User wurde durch den lokalen Cache gepuffert und klappte soweit noch. Die Anmeldung über RDP am DC als Administrator funktionierte aber nicht mehr - angeblich existiert kein Administratorkonto. Auch direkt an der Konsole fand er kein Admin Konto mehr. Letztendlich half nur ein Warmstart über Power Button. Der Server fuhr daraufhin runter und startete neu. Und jetzt läuft wieder alles, als wäre nichts geschehen. Alle melden sich wieder an, Administratorkonto ist auch verfügbar, Netzlaufwerke sind alle wieder da. Das Ereignisprotokoll nach dem Neustart ist auch wieder sauber. Der verursachende Fehler vor dem Neustart wurde erstmalig heute Nacht um 04:33 und dann fortlaufend bis zum Neustart wie folgt im Ereignisprotokoll registriert: Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "marsrv9$" empfangen. Der verwendete Zielname war LDAP/MARSRV9. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschl\'fcsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, das der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN nur bei dem Konto registriert ist, das vom Server verwendet wird. Dieser Fehler kann auch auftreten, wenn das Kennwort f\'fcr das Zieldienstkonto nicht mit dem Kennwort \'fcbereinstimmt, das im Kerberos-KDC (Key Distribution Center) f\'fcr den Zieldienst konfiguriert ist. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide f\'fcr die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldom\'e4ne (Domain Name ersetzt) von der Clientdom\'e4ne (Domain Name ersetzt) unterscheidet, pr\'fcfen Sie, ob sich in diesen beiden Dom\'e4nen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.\par Event Source Name: Kerberos Event ID: 16384 Das Googlen im Netz bringt hier zu viele kryptische Fehlermöglichkeiten. Habt Ihr da noch eine Idee, was ich checken sollte? Gruß Jörg Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 13. Dezember 2017 Melden Teilen Geschrieben 13. Dezember 2017 Heute Nacht gab es Windows Updates, wurden die evtl. um 03.00 Uhr automatisch installiert? Zitieren Link zu diesem Kommentar
Küstennebel 0 Geschrieben 13. Dezember 2017 Autor Melden Teilen Geschrieben 13. Dezember 2017 (bearbeitet) Nein, die Serverupdates müssen hier immer manuell angestoßen werden. Er zeigt momentan die verfügbaren Updates und den "Jetzt installieren" Button an. Was mir aber gerade eingefallen ist: Nachdem ich mich nach dem Neustart wieder anmelden konnte, kam zuerst der blaue Screen mit dem Windows Kreisel, der irgendwelche Benutzereinstellungen laden musste und danach für ca. 20s, bis auf den Mauszeiger, gar kein Desktop (alles schwarz). Erst danach war der normale Desktop wieder zu sehen. Das sah wirklich so aus, als hätte er irgendwelche Updates auch ohne Bestätigung eingespielt. Kann das sein? bearbeitet 13. Dezember 2017 von Küstennebel Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 13. Dezember 2017 Melden Teilen Geschrieben 13. Dezember 2017 Das solltest Du im Eventlog sehen. Zitieren Link zu diesem Kommentar
Küstennebel 0 Geschrieben 13. Dezember 2017 Autor Melden Teilen Geschrieben 13. Dezember 2017 Nein, installiert hat er nichts, zumindest wurde nichts dokumentiert. Das Einzige, was ich im Log erkennen kann, ist, dass 10 min vor dem ersten Auftreten des Fehlers der Dienst "Windows Update" in den Status "ausgeführt" gesetzt wurde und 2 s nach Auftreten des Fehlers der Windows Update Service ordnungsgemäß beendet wurde. Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 13. Dezember 2017 Melden Teilen Geschrieben 13. Dezember 2017 Könnte z.B. sein: - Unterschiedliche Uhrzeit - Fehlerhafte Namensauflösung Zitieren Link zu diesem Kommentar
Küstennebel 0 Geschrieben 13. Dezember 2017 Autor Melden Teilen Geschrieben 13. Dezember 2017 Hi Zahni, es gibt eine Warnung im Eventlog, dass der Zeitdienst nicht mehr als gute Zeitquelle angekündigt wird. Als nächsten Logeintrag steht dann aber das die Systemzeit mit 1.de.pool.ntp.org synchronisiert wurde. Zeitsync-Einstellungen werden per GPO auf dem DC und den Clients gesetzt. - Ich denke mal nicht, dass es die Zeit ist. Und bzgl. DNS habe ich auch keine Fehler m Log. DNS Server sieht auch sauber aus. Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 13. Dezember 2017 Melden Teilen Geschrieben 13. Dezember 2017 Du hast in der %windir%\WindowsUpdate.log nachgeschaut? Und im Eventlog Installation könnte was zu finden sein. Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 13. Dezember 2017 Melden Teilen Geschrieben 13. Dezember 2017 Deine Uhrzeit-Sync-Einstellung ist nicht korrekt. Es darf nur der PDC-Emulator mit einer externen Zeitquelle synchronisiert werden. Von welchen Eventlog reden wir? Die hast doch am Client ein Problem, oder? Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 13. Dezember 2017 Melden Teilen Geschrieben 13. Dezember 2017 Moin, der Fehler mit dem Kerberos-Ticket des Clients hat mit deinem Problem ziemlich sicher nichts zu tun. Zeitprobleme auf dem DC können wir auch ausschließen, denn es gibt ja nur den einen, und der synchronisiert sich per NTP. Wie ist denn der Stand momentan? Gibt es aktuell noch Probleme? Gruß, Nils Zitieren Link zu diesem Kommentar
Küstennebel 0 Geschrieben 13. Dezember 2017 Autor Melden Teilen Geschrieben 13. Dezember 2017 Du hast in der %windir%\WindowsUpdate.log nachgeschaut? Und im Eventlog Installation könnte was zu finden sein. Server 2016 schreibt nichts mehr in die WindowsUpdate.log. Darin steht nur noch: "Windows Update logs are now generated using ETW (Event Tracing for Windows). Please run the Get-WindowsUpdateLog PowerShell command to convert ETW traces into a readable WindowsUpdate.log." Das habe ich mal getan. Die Powershell erstellt daraufhin ein WindowsUpdate.log auf dem Desktop. Leider stehen darin nur sehr viele Zeilen im Format: 16.01.01 01:00:00:0000000 1252 6868 Unknown(15): GUID=.........(No Format Information found) Ich habe bisher immer direkt in den Updateverlauf geschaut und da sind die letzten Updates am 25.11. gelaufen. Event Log Installation deckt sich damit. Deine Uhrzeit-Sync-Einstellung ist nicht korrekt. Es darf nur der PDC-Emulator mit einer externen Zeitquelle synchronisiert werden. Von welchen Eventlog reden wir? Die hast doch am Client ein Problem, oder? Zeit Sync findet am PDC statt. Zumindest habe ich mich vor ein paar Wochen, als der Server neu aufgesetzt wurde, durch eine Anleitung, welche hier im Forum empfohlen wurde, gearbeitet. Diese hat eine WMI Filterung auf PDC Emulator. https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/ An den Clients haben wir kein Problem. Moin, der Fehler mit dem Kerberos-Ticket des Clients hat mit deinem Problem ziemlich sicher nichts zu tun. Zeitprobleme auf dem DC können wir auch ausschließen, denn es gibt ja nur den einen, und der synchronisiert sich per NTP. Wie ist denn der Stand momentan? Gibt es aktuell noch Probleme? Gruß, Nils Nein, momentan keine Probleme mehr, abgesehen von einem einzelnen EventLog Fehler: Der Dienst "Diagnosediensthost" wurde aufgrund folgenden Fehlers nicht gestartet: In der Dienstkontokonfiguration fehlt eine Berechtigung, die für die ordnungsgemäße Funktion des Dienstes erforderlich ist. Sie können das Snap-In "Dienste" in der Microsoft Management Console (MMC) (services.msc) und das Snap-In "Lokale Sicherheitseinstellungen" in der MMC (secpol.msc) verwenden, um die Dienstkonfiguration und die Kontokonfiguration anzuzeigen.. Aber das Vertrauen hat erst mal einen Kratzer abbekommen. Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 13. Dezember 2017 Melden Teilen Geschrieben 13. Dezember 2017 Moin, beobachten. Und noch mal die Eventlogs genau studieren, ggf. auch von ein paar Clients oder weiteren Servern. Solange es keine konkreten Probleme gibt, fehlt die Grundlage für weitere Einschätzungen. Gruß, Nils Zitieren Link zu diesem Kommentar
Küstennebel 0 Geschrieben 13. Dezember 2017 Autor Melden Teilen Geschrieben 13. Dezember 2017 (bearbeitet) Ok Nils, werde ich wohl tun müssen. Wo ich Euch gerade an der Leitung habe ... Ich will demnächst noch die Funktionsebene hochstufen. Irgendetwas (Authentifizierung, Replikation, etc.) wurde doch bei Server 2003 noch nicht über Kerberos gemacht. Kann ich jetzt einfach hochstufen oder sollte ich dazu irgendwas bedenken, außer, dass es dann kein zurück mehr gibt? bearbeitet 13. Dezember 2017 von Küstennebel Zitieren Link zu diesem Kommentar
Tektronix 21 Geschrieben 13. Dezember 2017 Melden Teilen Geschrieben 13. Dezember 2017 Hallo, hast Du mal in der Konsole die spn's abbgefragt? setspn -T * -T <Domänenname> -X Zeigt Dir an ob es doppelte SPN-Namensregististrierungen gibt. setspn -T <Domänenname> -F -Q */<Domänencontrollername> Zeigt Dir alle SPN-Namensregistrierungen an die im Format */<Domänencontrollername> in der Gesamtstruktur <Domänenname> vorhanden sind. Greez Zitieren Link zu diesem Kommentar
Küstennebel 0 Geschrieben 13. Dezember 2017 Autor Melden Teilen Geschrieben 13. Dezember 2017 Hi Greez, Dank für die Konsolenkommandos. Abfrage 1 brachte: "0 Gruppe von doppelten SPNs gefunden" Abfrage 2 brachte: 25 Zeilen Ausgabe, von HOST über RPC, GC, LDAP, TERMSRV, etc. (Da habe ich zu wenig Ahnung, um darin einen Fehler zu finden.) Am Ende stand jedenfalls "Bestehender SPN wurde gefunden" Gruß Jörg Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.