logix 0 Geschrieben 28. Oktober 2016 Melden Teilen Geschrieben 28. Oktober 2016 Guten Abend, mich plagt seit einiger Zeit ein komisches Problem. Ich habe einen Windows Server 2012 R2 im Einsatz mit 5 - Windows 7 Pro Arbeitsplätzen. Auf dem Server läuft AD, DHCP, DNS, Druckerserver,Dateifreigabe und eine Branchensoftware. Nach ca. 10 Stunden funktioniert plötzlich der Zugriff auf die Netzlaufwerke nicht mehr, d.h wenn der Rechner sich 7.00 Uhr anmeldet, dann stürzt die Verbindung 17.00 Uhr ab. Man kann von den Windows 7 Clients dann ohne Probleme ins Internet, Drucken,etc aber eben nicht auf die Netzlaufwerke zugreifen. Nach einen Neustart des Clients funktioniert alles wie gehabt, es gibt auch beim laufenden Betrieb keinerlei Einschränkungen. Ich hab auf den Clients schon den Energiesparmodus von der Netzwerkkarte deaktiviert und net config server /autodisconnect-1 auf den Clients probiert, leider ohne Erfolg bisher. Als Virenlösung läuft Kaspersky Small Office Security. Jemand eine Idee was das ist ? Vielen Dank Zitieren Link zu diesem Kommentar
Doso 77 Geschrieben 28. Oktober 2016 Melden Teilen Geschrieben 28. Oktober 2016 Mal überall die Treiber aktualisiert? Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 28. Oktober 2016 Melden Teilen Geschrieben 28. Oktober 2016 Moin, gibt es in den Ereignisprotokollen etwas Interessantes? Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 28. Oktober 2016 Melden Teilen Geschrieben 28. Oktober 2016 10h kann auf die Laufzeit des Kerberostickets, bzw. Probleme das Ticket automatisch zu erneuern, hindeuten. Es wurde hier ja schon oft diskutiert, dass auf einem DC nichts anderes laufen soll, als der DC. u.a. ist Troubleshooting dann extrem schwierig. Führe doch mal um 16:30 und 17:30 jeweils ein "gpupdate" als Administrator auf einem Client aus. Läuft es in beiden Zeiten fehlerfrei druch? (die Ausgabe ansich interessiert nicht) Zitieren Link zu diesem Kommentar
logix 0 Geschrieben 28. Oktober 2016 Autor Melden Teilen Geschrieben 28. Oktober 2016 (bearbeitet) Moin, gibt es in den Ereignisprotokollen etwas Interessantes? Ich werde morgen mal in die LogFiles schauen und ggf. posten 10h kann auf die Laufzeit des Kerberostickets, bzw. Probleme das Ticket automatisch zu erneuern, hindeuten. Es wurde hier ja schon oft diskutiert, dass auf einem DC nichts anderes laufen soll, als der DC. u.a. ist Troubleshooting dann extrem schwierig. Führe doch mal um 16:30 und 17:30 jeweils ein "gpupdate" als Administrator auf einem Client aus. Läuft es in beiden Zeiten fehlerfrei druch? (die Ausgabe ansich interessiert nicht) Werde ich am Dienstag testen, wenn die Firma wieder arbeitet, Montag ist Feiertag bei uns. Also werde ich dann 16:30 das gpupdate ausführen, aber warum 17:30 nochmal ? Der betroffene Client war jetzt noch an und ich hab "gpupdate" mal ausgeführt Die Benutzerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Pr obleme sind aufgetreten: Bei der Verarbeitung der Gruppenrichtlinie ist aufgrund fehlender Netzwerkkonnek tivität mit einem Domänencontroller ein Fehler aufgetreten. Dies kann eine vorüb ergehende Bedingung sein. Es wird eine Erfolgsmeldung generiert, wenn die Verbin dung des Computers mit dem Domänencontroller wiederhergestellt wurde und wenn di e Gruppenrichtlinie erfolgreich verarbeitet wurde. Falls für mehrere Stunden kei ne Erfolgsmeldung angezeigt wird, wenden Sie sich an den Administrator. Die Computerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Pr obleme sind aufgetreten: Bei der Verarbeitung der Gruppenrichtlinie ist aufgrund fehlender Netzwerkkonnek tivität mit einem Domänencontroller ein Fehler aufgetreten. Dies kann eine vorüb ergehende Bedingung sein. Es wird eine Erfolgsmeldung generiert, wenn die Verbin dung des Computers mit dem Domänencontroller wiederhergestellt wurde und wenn di e Gruppenrichtlinie erfolgreich verarbeitet wurde. Falls für mehrere Stunden kei ne Erfolgsmeldung angezeigt wird, wenden Sie sich an den Administrator. Lesen Sie zur Fehlerdiagnose das Ereignisprotokoll, oder führen Sie den Befehl " GPRESULT /H GPReport.html" aus, um auf Informationen über Gruppenrichtlinienerge bnisse zuzugreifen. bearbeitet 28. Oktober 2016 von logix Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 28. Oktober 2016 Melden Teilen Geschrieben 28. Oktober 2016 Also werde ich dann 16:30 das gpupdate ausführen, aber warum 17:30 nochmal ? Der betroffene Client war jetzt noch an und ich hab "gpupdate" mal ausgeführt weil gpupdate sich einmal mit dem Kerberosticket des User für die Userpolicies und eimal mit dem Kerberosticket des Computers für die Computerpolicies mit dem DC verbindet. Das solltst du einmal vor Ablauf der 10h und einmal danach machen. Wobei das "Danach" hast du ja jetzt schon gemacht. Offenbar ist "danach" weder Client noch User am AD ordnungsgemäß angemeldet. Der Test mit gpupdate wäre jetzt nur meine Vorgehensweise, um die Richtung des Problems rauszufinden. Das eigentliche Troubleshooting ist auf einem solchen System, konfiguriert abseits von allen Empfehlungen, Glückssache. Ein Neuaufsetzen des Servers oder ein Restore vom Backup ist vielleicht schneller und günstiger. blub Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 28. Oktober 2016 Melden Teilen Geschrieben 28. Oktober 2016 (bearbeitet) Der betroffene Client war jetzt noch an und ich hab "gpupdate" mal ausgeführt Handelt es sich nur um einen Client? Oder sind alle Clients betroffen? Wurde nach gpupdate in die Ereignisanzeige geschaut? bearbeitet 28. Oktober 2016 von lefg Zitieren Link zu diesem Kommentar
daabm 1.366 Geschrieben 29. Oktober 2016 Melden Teilen Geschrieben 29. Oktober 2016 Da wäre dann die Frage, warum die TGTs nicht automatisch erneuert werden - blub hat absolut Recht... Aber das per Forum herauszufinden ist schwierig schwierig Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 29. Oktober 2016 Melden Teilen Geschrieben 29. Oktober 2016 (bearbeitet) Moin, - den Client aus der Domäne nehmen, neu starten - das Computerkono im AD löschen - den Client der Domäne hinzufügen . nach Neustart Blick in die Ereignisanzeigen Eine Hand für das Schiff, eine für den Mann, einen Blick ins Ereignisprotkoll. ? bearbeitet 29. Oktober 2016 von lefg Zitieren Link zu diesem Kommentar
logix 0 Geschrieben 29. Oktober 2016 Autor Melden Teilen Geschrieben 29. Oktober 2016 Handelt es sich nur um einen Client? Oder sind alle Clients betroffen? Wurde nach gpupdate in die Ereignisanzeige geschaut? Alle Clients sind davon betroffen. Ich werde am Dienstag gegen 16:30 nochmal das "gpupdate" durchführen und dann mal in die Ereignisanzeige schauen, ob dort Einträge diesbezüglich sind. weil gpupdate sich einmal mit dem Kerberosticket des User für die Userpolicies und eimal mit dem Kerberosticket des Computers für die Computerpolicies mit dem DC verbindet. Das solltst du einmal vor Ablauf der 10h und einmal danach machen. Wobei das "Danach" hast du ja jetzt schon gemacht. Offenbar ist "danach" weder Client noch User am AD ordnungsgemäß angemeldet. Der Test mit gpupdate wäre jetzt nur meine Vorgehensweise, um die Richtung des Problems rauszufinden. Das eigentliche Troubleshooting ist auf einem solchen System, konfiguriert abseits von allen Empfehlungen, Glückssache. Ein Neuaufsetzen des Servers oder ein Restore vom Backup ist vielleicht schneller und günstiger. blub Wenn wir es vermutlich eine Neuinstallation werden, Vollbackup ist natürlich vorhanden, aber die Problematik ist schon ca. 2 Wochen, sodass der "Fehler" in allen Sicherungen seien wird. Sonst noch Ideen bzw. Vorschläge wie man das ganze evtl. noch beheben könnte ? Moin, - den Client aus der Domäne nehmen, neu starten - das Computerkono im AD löschen - den Client der Domäne hinzufügen . nach Neustart Blick in die Ereignisanzeigen ? Wäre eine Möglichkeit. Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 29. Oktober 2016 Melden Teilen Geschrieben 29. Oktober 2016 War das eigentlich schon immer so? Oder gibt es eine ungefähre History? Zitieren Link zu diesem Kommentar
daabm 1.366 Geschrieben 29. Oktober 2016 Melden Teilen Geschrieben 29. Oktober 2016 Client raus/rein wird net viel bringen... Ich würde ja - wenn es entsprechend wichtig ist - folgendes vorschlagen: - Netzwerktrace auf Clientseite mitlaufen lassen. Filter auf den DC und 88/389/464. Auswertung ist aber mühsam - Security Eventlogs auf DC und Client prüfen auf TGT/Kerberos relevante Fehler - Kerberos Logging aktivieren - https://support.microsoft.com/en-us/kb/262177 Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 29. Oktober 2016 Melden Teilen Geschrieben 29. Oktober 2016 (bearbeitet) Wurde die Namensauflöung per DNS schon erwähnt? Meine bevozugte Hauptverdächtige? Wurde dcdiag schon erwähnt? Das Schauen ins Ereignisprotoll habe ich erwähnt, von Client und Server. Eine Fehleranalyse beginnt mit dem Schau in die Protokolle. Manchmal habe ich den Eindruck, Leute haben Furcht davor, wie vor schlechter Diagnose beim Arzt, gehen deshalb nicht hin. ;) bearbeitet 29. Oktober 2016 von lefg Zitieren Link zu diesem Kommentar
djmaker 95 Geschrieben 1. November 2016 Melden Teilen Geschrieben 1. November 2016 Auxch wenn es vielleicht b***d klingt - ein Call kostet bei MS 300 € netto - unabhängig vom Aufwand. Ich denke das ist die schnellste und zielsicherste Vorgehenesweise. Zitieren Link zu diesem Kommentar
NorbertFe 2.097 Geschrieben 1. November 2016 Melden Teilen Geschrieben 1. November 2016 Naja obs die schnellste sein wird? ;) 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.