illuminaten

Hallo Nils, es sind Windows 2022 Server. Patchlevel ist gleich. Ansonsten gibt es keine Zugriffsprobleme auf Windows - Ressourcen. Es wurde auch kein Host aus einem Backup wiederhergestellt. Gruß

Hallo, wir haben ein MS HyperV Failvover Cluster eingerichtet. Hierbei haben wir das Problem, dass die Livemigration nicht funktioniert. Es wird die Meldung: Der Vorgang wurde für die Ressource "Virtueller Computer "VM1" nicht abgeschlossen. Wählen Sie die Aktion "Informationsdetails" aus, damit die Ereignisse für die Ressource angezeigt werden. Die Informationsdetails sind leer. Im Ereignisprotokoll System bekommen wir diese Meldung: Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "hyperv04-001$" empfangen. Der verwendete Zielname war HTTP/Cluster01-kdm.domain.de. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln 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ür das Zieldienstkonto nicht mit dem Kennwort übereinstimmt, das im Kerberos-KDC (Key Distribution Center) für den Zieldienst konfiguriert ist. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (domain.de) von der Clientdomäne (doamin.de) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren. Die Schnellmigration funktioniert in beide Richtungen. Kennt jemand das Problem und weiß eine Lösung. Für Eure Unterstützung bedanke ich mich im Voraus

Danke für die ganzen Antworten. -> Das haben wir nun umgesetzt. Den Rest schaffen wir auch noch :)

Wir sind nun etwas klüger :) Laut Eventlog wurden an beiden Hosts die Netzwerkkarten komplett zeitgleich getrennt (sind zwei komplett getrennte Systeme). Habe daraufhin den Switch untersucht. Dieser hat zu der genannten Uhrzeit wo die Fehler auftraten ein Update installiert. Scheinbar war der Link dann kurz weg. Auto-Update habe ich dann direkt ausgeschaltet. Zudem habe ich laut Eventlog herausgefunden, dass die VM's (auch zu der Uhrzeit) "unerwartet heruntergefahren" wurden. Liegt vielleicht auch den Fehlermeldungen im Failovercluster, Was mir noch nicht in den Kopf geht ist, wieso die VM's heruntergefahren wurden und wieso es mit den VM's überhaupt Probleme gab, diese sind per Fibre Channel jeweils 2x 16Gb an den Hosts angeschlossen.

Ehrlich gesagt können wir das nicht ausschließen und konnten auch noch keinen Blick in das Bios werfen. Der Fehler ist heute morgen aufgefallen. Wir sind noch daran die "Nachwehen" zu fixen. auch können wir den Host (noch) nicht neu starten. Das kann ich dir schonmal beantworten. Im Cluster ist eine Ethernus eingebunden, also Netzwerkspeicher auf dem alle VM's angelegt sind.

Physische Adapter: Je Host: 2 × Intel X710-10 Gbit Ports (für Cluster) Zusätzlich: 1 × Intel I350-T4 1 Gbit Port (für anderes Netz) vSwitches: 10G-Failover: Externer vSwitch, an beide 10 G-Ports (X710-T2L + X710-TL) angebunden Typ: Switch Embedded Teaming (SET) Teaming-Modus: Switch Independent AllowManagementOS: True

Der Host selbst läuft in der Energieverwaltung auf "Höchstleistung". Bei der Netzwerkkarte ist der Haken nicht gesetzt bei "Computer kann das Gerät ausschalten um Energie zu sparen"

Intel_LAN_ProSet_All Treiber ist die Version 9.01.04.00 installiert. Eine neuere Version 9.02.04.00 wäre verfügbar. Die Disks wurden immer zwischen 18 und 19 Uhr getauscht. Die Ausfälle der Netzwerkkarte war immer in Nacht, jeweils um 01:00 Uhr und gegen 02:00 Uhr

Hallo zusammen, wir haben bei einem Kunden vor ein paar Monaten zwei neue HyperV-Hosts hingestellt. Vor ca. 4 Wochen kam es dann zu einem Ausfall auf einem der Hosts. Sie sind zwar im Failovercluster, aber die angelegten VM's wurden nicht korrekt verschoben und waren in einem undefinierten Zustand. Nach Prüfung des Fehlers ist uns aufgefallen, dass am Host in der Nacht die Netzwerkkarte getrennt wurde, was dann dutzende Folgefehler produziert hat. Eine Woche später erneut der genau gleiche Ausfall. Wir haben dann alle VM's auf den zweiten Host verschoben und sind von einer defekten Netzwerkkarte ausgegangen. Nun haben wir heute den gleichen Fehler auf dem zweiten Host. Die Meldungen aus dem Ereignisprotokoll hänge ich ganz unten an. Hört sich jetzt b***d an, aber bei allen drei Ausfällen wurde vorher vom Kunden selbst die externe HDD getauscht, für die Backup Copy Jobs. Ich gehe mal nicht davon aus, dass das damit etwas zu tun haben kann, aber ich erwähne es mal lieber. Die Hosts sind: Windows Server 2022 Fujitsu PRIMERGY RX2530 M7 bzw. PRIMERGY RX2530 M7S CPU: Intel(R) Xeon(R) Gold 5416S (CORES 16) Motherboard: FUJITSU D3982-A1 Hier noch ein paar Infos zu Netzwerkkarten: Name : Flexible LOM1 Port 3 Description : Intel(R) Ethernet Network Adapter I350-T4 for OCP NIC 3.0 Manufacturer : InterfaceDescription : Intel(R) Ethernet Network Adapter I350-T4 for OCP NIC 3.0 PNPDeviceID : Name : Flexible LOM1 Port 2 Description : Intel(R) Ethernet Network Adapter I350-T4 for OCP NIC 3.0 #4 Manufacturer : InterfaceDescription : Intel(R) Ethernet Network Adapter I350-T4 for OCP NIC 3.0 #4 PNPDeviceID : Name : PCI Slot 2 Port 1 Description : Intel(R) Ethernet Network Adapter X710-T2L Manufacturer : InterfaceDescription : Intel(R) Ethernet Network Adapter X710-T2L PNPDeviceID : Name : PCI Slot 2 Port 2 Description : Intel(R) Ethernet Network Adapter X710-TL Manufacturer : InterfaceDescription : Intel(R) Ethernet Network Adapter X710-TL PNPDeviceID : Name : Onboard LAN Description : Intel(R) I210 Gigabit Network Connection Manufacturer : InterfaceDescription : Intel(R) I210 Gigabit Network Connection PNPDeviceID : Name : Flexible LOM1 Port 1 Description : Intel(R) Ethernet Network Adapter I350-T4 for OCP NIC 3.0 #3 Manufacturer : InterfaceDescription : Intel(R) Ethernet Network Adapter I350-T4 for OCP NIC 3.0 #3 PNPDeviceID : Name : Flexible LOM1 Port 4 Description : Intel(R) Ethernet Network Adapter I350-T4 for OCP NIC 3.0 #2 Manufacturer : InterfaceDescription : Intel(R) Ethernet Network Adapter I350-T4 for OCP NIC 3.0 #2 PNPDeviceID : Edit: Ich habe noch einen Screenshot angehängt von der Clusterüberprüfung. Dort gibt er mir Warnungen und Fehler bei der Switch Konfiguration aus.

Habe ich soeben versucht. Funktioniert leider immer noch nicht.

Hallo zusammen, ich betreibe einen dedizierten Printserver auf Windows Server 2022 (Build 10.0.20348.1). Der DC läuft ebenfalls auf Server 2022, beide Maschinen sind also voneinander getrennt. Unsere Clients Windows 11 - 10, alle sauber in die Domäne eingebunden. Das Problem: Sobald sich ein normaler Domänen­benutzer per Explorer (\\print‑mm) mit einem freigegebenen Drucker verbindet, erscheint nahezu direkt „Treiber wird gesucht …“ und endet dann reproduzierbar mit dem Dialog. Auf dem Print-Server ist bei den Berechtigungen für den Drucker und den Treiber Die Berechtigung "Jeder" gesetzt mit den Rechten "Drucken, Diesen Drucker verwalten". Druckerverbindung herstellen Druckerverbindung kann nicht hergestellt werden. Zugriff verweigert. Melde ich mich als Domänen‑Admin am gleichen PC an, lässt sich der Drucker ohne Rückfrage sofort installieren – der Treiber ist also grundsätzlich vorhanden und freigegeben. Auf dem Printserver liegen ausschließlich paket‑signierte Type‑3‑Treiber. Was ich bisher untersucht habe Registry auf dem Print-MM Server: Unter HKLM\…\Printers\PointAndPrint finde ich Restricted = 1 und ServerList = Print‑MM (ohne FQDN). Der Schlüssel RestrictDriverInstallationToAdministrators existiert gar nicht. (Ich hatte darüber was unter Microsoft Support point-and-print-default-driver-installation-behavior gelesen) die Einstellung existiert außerdem nicht in den Gruppenrichtlinien. Gruppenrichtlinien: In der GPMC steht „Point‑and‑Print‑Einschränkungen“ aktuell auf Deaktiviert. „Installation von Treibern für diese Gerätesetupklassen ohne Administratorrenrechte zulassen“ ist auf Aktiviert mit folgenden Klassen: {4d36e979-e325-11ce-bfc1-08002be10318} {6bdd1fc6-810f-11d0-bec7-08002be2092f} GPUpdate & Neustart: Sowohl gpupdate /force als auch ein kompletter Reboot der Clients bringen keinen Unterschied. (Das Problem besteht auf allen Clients) Im Moment komme ich hier leider nicht weiter. Falls jemand dieses Problem schon erfolgreich lösen konnte oder einen konkreten Ansatz kennt – gerne auch nur eine Idee, freue ich mich über jeden fundierten Hinweis. Vielen Dank vorab für eure Unterstützung! Viele Grüße

Hallo, ich habe seit Montag das Problem, dass externe E-Mails nicht mehr im O365 Postfach ankommen. Die DNS Einträge sind in Ordnung. Es wurde auch nichts in den Einstellungen bei Strato oder im O365 Admincenter geändert. Der Absender von E-Mails an das Postfach bekommt keine Fehlermeldung zurück. Es wurden keine Regeln im OWA gesetzt Ich kann von dem Postfach E-Mails nach extern versenden. Diese kommen beim Empfänger auch an. Vielen Dank für eure Unterstützung im Voraus Gruß

Hallo, das Problem tritt aktuell nicht auf. Trotzdem habe ich mir die DNS Konfiguration angeschaut. Hierbei ist mir aufgefallen, dass für jeden Host in der Sammlung ein DNS Eintrag erstellt wurde. Das war doch noch die Vorgehensweise bis TS 2008 Server. Könnt ihr mir bitte mitteilen wie die DNS Konfiguration bei einer RDS 2016 Farm aussehen muss. Vielen Dank im Voraus

Hallo Ralf, vielen Dank für die schnelle Antwort. -> der Broker ist ein eigenständiger Server. Wenn der Fehler auftritt sollte es eigentlich im Server Manager des Brokers Hinweise dazu geben, also kritische Fehler. -> ich konnte im Broker Ereignis nichts auffälliges finden. Was passiert wenn Du Dich an einem der RDS Server anzumelden, wenn der Fehler auftritt, also Console mit Admin? -> muss ich abwarten bis es zum nächsten Fehler kommt. GRuß

Hallo zusammen, ich habe seit ca zwei Wochen ähnliches Problem. in der RDS Farm mit 4 RDS-Servern. Sobald der Fehler auftritt landen alle Anmeldungen auf dem Server RDS02-Farm. Diese Verbindungen werden aber nicht auf dem Broker unter unter den Verbindungen im Server Manager -> Remotedesktop-dienste-> Sammlungen -> RDS-Farm01 angezeigt. Im Taskmanager des RDS 02 sind die Anmeldungen sichtbar. Abhilfe: ich starte den Broker und den RDS02 Server neu. Danach werden die Anmeldungen auf die RDS Server verteilt. Ich starte die RDS-Server täglich neu. Im Ereignisprotokoll konnte ich keine Auffälligkeiten finden. Ich hoffe, dass ihr mir weiterhelfen könnt. Vielen Dank für Eure Unterstützung im Voraus GRuß