Verbindung zum Server / Netzwerk sporadisch weg

[tsunami13 11]

Hm, gewartet habe ich bei keinem User. Auch nicht an dem betroffenem PC.

Zudem habe ich ja den im obigen Beitrag beschriebenem Timeout gesetzt.

Zitat

Die offizielle Lösung von Microsoft ist:
Computer Configuration\Administrative Templates\System\Gruppenrichtlinie\
"Wartezeit für Richtlinienverarbeitung beim Systemstart angeben"

der empfohlene Richtwert beträgt 60 Sekunden

 

[XP-Fan 220]

... und was passiert wenn  du abwartest?

[lefg 276]

Moin

 

Gibt es Auffälliges in den Ereignisanzeigen von Server und Clients?

 

Aus Erfahrung und Deutung der beschriebenen Symphome ist zu vermuten: Das OS des Clients ist zu schnell bereit zum Anmelden, die Netzwerkverbindung aber noch nicht. Da half es erstmal mit dem Anmelden zu warten, so ein/zweit Minuten, das mussten man mal probieren, besser länger warten als kürzer.  Da half dann meist die Gruppenrichtlinie "Bei Neustart und Anmeldung auf das Netzwerk warten." Nach ein - zwei Reboots sollte das GPO vom Client übernommen und wirksam sein. Das konnte man prüfen mit gpresult. Früher reichte das jedenfalls. Früher, das war für mich vor SSD. Mit SSD wurde das OS noch schneller fertig, noch schneller bei der Anmeldung und es wurde anscheinend nicht lange genug gewartet bis das Netzwerk verfügbar. Das Anmelden selbst funktionier ja cached, das der User schon mal an dem Rechner eingeloggt war. Es ist also sicherzustellen, vor einem Versuch des Zugriffs auf den Server, eine Netzlaufwerkverbindung herzustellen, imuss die Netzwerkverbindung vorhanden sein.

 

Ich hatte mal: nach Updates, auch Treiber, auch Netzwerktreiber, funktionierte es plötzlich nicht mehr. Zurückgeschaltet auf den vorherigen Treiber funktionierte es wieder. Der neue Treiber brauchte anscheinend wesentlich länger zum Aufbau der Verbindung. Neueste Treiber müssen also nicht immer gute Treiber sein.

 

 

bearbeitet 26. November 2019 von lefg

[tsunami13 11]

Guten Morgen,

ich bin nun etwas weiter gekommen. Einen Client und den Server direkt auf den Switch geklemmt. An einem besonders problematischen Client habe ich an  den Arbeitsplatz einen Laptop gehängt.

10x rauf und runter gefahren, ohne Schnellstart. Und oh Wunder die Laufwerke wurden alle ohne Probleme genommen.

PC dran und Probleme wieder da. Nun seperate Nic eingebaut und oh Wunder alle 10x keine Probleme.

Das berüchtigte rote Kreuz ist noch davor, man kann aber problemlos aufs Laufwerk zugreifen. Dann verschwindet es sofort.

Nun habe ich "nur" noch das Problemchen mit der abstürzenden MS SQL Anwendung und den Druckern.

Da werden die voreingestelllten Schachtzuweisungen ignoriert bzw. "umgestellt". Das heißt ich setzte den Schacht 1 auf Standard, teste, alles gut. Nach zwei Tagen steht er plötzöich auf manuelle Zufuhr.

Der andere Drucker steht plötzlich auf Auto oder Schacht 4 statt wie eingestellt auf Schacht 1. Aber da habe ich gesehen, dass es Probleme mit einem der letzten Updates gab.

Weiß jemand schon etwas über einen Fix/Korrktur?

 

mFG

tsunami13

[lefg 276]

vor 2 Stunden schrieb tsunami13:

ohne Schnellstart.

 

Und wie wäre es, den Schnellstart zu deaktivieren?

[tsunami13 11]

Das meinte ich. Der ist deaktiviert.

[lefg 276]

Ok, der Schnellstart ist also deaktiviert.

 

Ist das GPO "..... immer auf das Netzwerk warten" wirksam? Wird bei ersten Start morgens auf das Netzwerk gewartet oder nicht?

bearbeitet 27. November 2019 von lefg

[tsunami13 11]

Hi,

Aus Netzwerk warten ist aktiviert und zusätzlich die GPO 

Die offizielle Lösung von Microsoft ist:
Computer Configuration\Administrative Templates\System\Gruppenrichtlinie\
"Wartezeit für Richtlinienverarbeitung beim Systemstart angeben"

der empfohlene Richtwert beträgt 60 Sekunden

PS. Kommando zurück. PC macht wieder Zicken, trotz zusätzlicher Nic

[lefg 276]

vor 19 Minuten schrieb tsunami13:

der empfohlene Richtwert beträgt 60 Sekunden

 

Wurde es schon mit einem höheren Wert versucht?

bearbeitet 27. November 2019 von lefg

[tsunami13 11]

Noch nicht, da alle anderen Clients keine Probleme haben. Wollte nun auch diesen Client mal direkt an den Switch hängen...
Oder wirklich MB defekt...
Weil Laptop an exakt demselben Arbeitsplatz 10x rauf und runter ohne Probleme. Ebenfalls win10 und ebenfalls ssd. Selbes Konto...

[lefg 276]

vor 20 Minuten schrieb tsunami13:

da alle anderen Clients keine Probleme haben.

Wurde das schon einmal hier mitgeteilt?

 

 

vor 20 Minuten schrieb tsunami13:

Wollte nun auch diesen Client mal direkt an den Switch hängen...

Eine gute Idee.

 

Hat das mit dem Rechner eigentlich schon mal funktioniert an dem Anschluss?

vor 20 Minuten schrieb tsunami13:

Oder wirklich MB defekt..

 

Fragte ich nicht in einer anderen Antwort nach dem Blick in das Ereignisprotokoll?

bearbeitet 27. November 2019 von lefg

[tsunami13 11]

Ja das ist ja das merkwürdige. Der PC lief jahrelang. Server getauscht und nun plötzlich MB defekt?

Die anderen Clients laufen, seit ich den Server direkt auf den Switch gehängt habe.

Könnte den PC ja noch an nen anderen Arbeitsplatz hängen...

Aber das sind mir zu viele Zufälle..

Was natürlich sein kann, dass da schon länger nen "Wackliger" in der Dose/Kabel war. Ich habs angefasst und dann ists ganz gebrochen. Der Klassiker...

[tsunami13 11]

Nun macht auch der PC welcher direkt am Switch hängt Probleme, nur 1x aber....

 

Und einen neuen Ansatz gefunden:

https://administrator.de/forum/win10-unc-hardening-sicherheit-375758.html#comment-1287625

[tsunami13 11]

Guten Abend,

folgendes heite erfolglos probiert:

1.   Timeout für Anmeldung auf 300 S

        ComputerConfiguration -> Administrative Vorlagen -> System -> Gruppenrichtlinie

        Wartezeit für die Richtlinienverarbeitung beim Sytemstart angeben

==> Erste Anmeldung gab direkt wieder Fehler. 1 client hat wohl tatsächlich 5 Minuten für den Anmeldeprozess gebraucht.

 

2.   Dauerping setzen

==> Sauber wie nichts

 

3.   Computer Configuration\Administrative Templates\System\Group Policy\

Configure Logon Script Delay auf 0 setzen

==> kein Erfolg

 

4. UNC Hardening deaktiviert

a) HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths

You will need to set 2 entries (both REG_SZ)
 \\*\sysvol
 \\*\netlogon
with this value: RequireMutualAuthentication=0, RequireIntegrity=0, RequirePrivacy=0

4b.   Computer Configuration / Administrative Templates / Network / Network Provider and the setting name is Hardened UNC Paths. Enable this, click Show, and add your shares and values here, i.e. \\*\sysvol as value name and RequireMutualAuthentication=0, RequireIntegrity=0, RequirePrivacy=0 as value.

4c.   Einfachste Lösung ist eine neue GPO anzulegen, welche das UNC-Hardening für die SYSVOL und ggfs. NETLOGON Freigabe wieder deaktiviert.
Dazu unter „Computerkonfiguration > Administrative Vorlagen > Netzwerk > Netzwerkanbieter “ die Richtlinie für Gehärtete UNC-Pfade aktivieren und folgende Einträge hinzufügen:

 Wretname: \\*\SYSVOL
Wert: RequireMutualAuthentication=0, RequireIntegrity=0
(ggfs. für \\*\NETLOGON den selben Wert hinzufügen)

==> Die EInträge in der Registry waren angelegt

 

5. Sicherheitsupdate  KB4517211 und  Sicherheitsupdate KB4522016 deaktivieren

Druckerprobleme durch og Updates. Die Updates gab es gar nicht.

 

6. Anhängendes habe ich noch via DCdiag gefunden. Lissten Adress in der Registry entfernt, danach war ein Fehler in den DNS Server im Dashboard weg.

dcdiag.txt dcdiagfix.txt dcdiagfix2.txt dcd9iag2.txt

Und ich habe gemerkt, dass einer der beiden Front USB Anschlüsse nicht geht. Könnte also auch sowas wie eine Kriechspannung sein, die im System rumgeistert..

[lefg 276]

Nur die Fehler werden in die Zwischenablage übernommen mit dcdiag/q | clip

 

In eine Datei mit dcdiag/q >> diag.txt