PaddraighOS

Hallo, Das 12-Minuten-Intervall ist ein klassisches Kennzeichen: Der Windows Computer Browser Service sendet in diesem Rhythmus seine Announcements ans Netzwerk, und zwar über TCP 139 (NetBIOS Session Service) zum PDC-Emulator. Der Prozess taucht als "System" auf, weil der Browser Service ein Kernel-Mode-Treiber ist. Warum nur der PDC-Emulator betroffen ist, erklärt sich dadurch, dass der Browser Service seinen Domain Master Browser immer beim PDC sucht. Das erklärt auch, warum der Neustart geholfen hat: Nach einem Neustart wird der Dienst neu gestartet und baut den Zustand erst wieder auf. Du kannst prüfen ob der Computer Browser Service läuft mit: Get-Service Browser Wenn der Dienst auf den betreffenden Servern läuft und ihr ihn nicht braucht (in modernen AD-Umgebungen ab Windows 8/Server 2012 ist er in der Regel überflüssig), kann er einfach deaktiviert werden: Set-Service -Name Browser -StartupType Disabled Stop-Service -Name Browser Das wäre die saubere Lösung und SMBv1 wäre auf dem Server danach tatsächlich wirkungslos, weil nichts mehr darüber kommuniziert. Gutes Gelingen!

Interessantes Phänomen. Also, Dein Hinweis, dass es nur an der Dockingstation passiert, ist der Schlüssel: Windows und das UEFI lassen Wake-Timer generell nur feuern, wenn der Rechner am Netz hängt, nicht im Akkubetrieb. Die Dockingstation liefert Strom, also wird der geplante Wake-Timer ausgelöst. Das erklärt auch, warum kein baugleiches Notebook das gleiche Verhalten zeigt: Der Auslöser ist spezifisch auf diesem Gerät konfiguriert. Mein Verdacht: Ein Windows-geplanter Task mit aktivierter Option "Computer für diesen Task aus dem Standbymodus aktivieren", monatlich am 4. um 16:42 UTC. Das wäre genau so eine Aufgabe, die von Dell SupportAssist, Lansweeper-Agent, SCCM/Intune-Client oder einem ähnlichen Tool angelegt wurde. Das kannst du mit zwei Befehlen direkt prüfen: In einer Admin-PowerShell alle Tasks, die den Computer aufwecken dürfen: Get-ScheduledTask | Where-Object {$_.Settings.WakeToRun -eq $true} | Select-Object TaskName, TaskPath Und wenn du das nächste Mal am 4. dabei bist, direkt nach dem Wake als Admin: powercfg /waketimers Der zweite Befehl zeigt aktive Wake-Timer, also was den Rechner kurz vorher aufgeweckt hat oder als nächstes wecken würde. Ein drittes Tool das prüfenswert ist: Dell SupportAssist hat standardmäßig eine monatliche Systemprüfung. Die läuft oft auf einen festen Termin und kann den Rechner dafür aufwecken. Schau in den SupportAssist-Einstellungen unter "Geplante Scans".

Kurze Antwort: Du brauchst keinen Switch zwischen Nodes und Storage, wenn das Storage direkt genug Ports hat – für ein Produktiv-Cluster würde ich es trotzdem empfehlen. Warum? Direkte Verbindung (ohne Switch): Funktioniert prinzipiell. Jeder Node bekommt seinen eigenen Port am Storage. Problem: Kein Multipath möglich, also keine Redundanz. Fällt eine NIC oder ein Kabel aus, verliert der Node seine Storage-Verbindung – und das ist in einem Cluster kritisch. Mit dediziertem iSCSI-Switch (empfohlen): Du hast die Möglichkeit, MPIO zu aktivieren (z.B. 2 NICs pro Node x 2 Switches = 4 Pfade pro Node). Das gibt dir echte Redundanz ohne Single Point of Failure. Zur zweiten Frage, ob die Nodes untereinander über das iSCSI-Netz kommunizieren müssen: Nein, das brauchen sie nicht. Beim iSCSI redet jeder Node direkt mit dem Storage, nicht mit den anderen Nodes. Die Cluster-Kommunikation (Heartbeat, CSV-Koordination, LiveMigration) läuft über eure anderen Netze (Management und LiveMigration). Das iSCSI-Netz ist rein für Node-zu-Storage. Empfohlene Architektur für drei Nodes: Management 1 GbE (bestehend), LiveMigration / Cluster 25 GbE (bestehend), iSCSI eigenes Netz mit dediziertem Switch und MPIO mit 2 Pfaden pro Node. Wenn das Storage genug Ports hat, kannst du auch mit einem einzigen iSCSI-Switch arbeiten, solange die NICs im Server redundant sind (MPIO). Zwei Switches wären besser, aber einer ist schon ein großer Schritt gegenüber direkten Verbindungen ohne Redundanz.