Alle Aktivitäten

Ja, es ist für das korrekte Profil aktiviert Und der test war remote, jap. Es funktioniert auch nicht mit komplett deaktivierter Windows Firewall. Zwischen den beiden clients ist keine andere Firewall. Endpoint protection hatte ich auch testweise deaktiviert. Eigentlich möchte ich nicht noch tiefer forschen, wir benötigen es nicht, ist nur per Zufall aufgefallen und es hätte mich einfach interessiert ob es ein allgemeiner Fehler ist oder nur bei uns auftritt. Vielleicht hat ja jemand Lust einfach mal zu testen ob bei ihm in der Domäne der remote Zugriff auf die Defender Firewall auf einen 24h2 Client geht (wenn die entsprechenden fw Regeln aktiv sind).

Tru dat. Ich kenne die Ausgabe von Deinem Skript nicht auswendig, dachte, das käme vielleicht von netstat - aber da wäre LISTENING ja groß geschrieben...

Wenn er mit dem Test-TcpPorts den RPC-Port sieht, muss er wohl offen sein - ich hoffe ja, das war "remote" und nicht lokal

Hier trübe und feuchtwarm... Heute Balkonsolar 1,6 kWp bestellt (DYI mit 2 gedrosselten MWR, bei senkrechter Montage kommt nicht besonders viel raus).

Sorry wenn das schon beantwortet wurde... aber ist die Regel auch für das Profil aktiv, welches die Zielmaschine auch tatsächlich erkannt hat? Die Regel gibt's ja für Domäne und Privat getrennt, zumindest sehe ich das auf einer frischen Maschine so...

Das ist dann seltsam... Kann ich jetzt spontan leider nicht erklären Die Portnummer ist wurscht, das ist RPC-Highport, die sind "random" ab 49152 aufwärts. Evtl. findest Du in nem Wireshark-Trace was, den Du auf dem Client mitschneidest, wo Du die MMC aufrufst. Mein Skript gibt leider "out of the box" die RPC Interface GUIDs nicht aus, hat sie intern aber. Vielleicht haben sie die GUID in 24H2 geändert, ich weiß es nicht.

Hi Martin, danke für das Script und die Infos. Also beim Win10 22H2 sehe ich ein Remote Fw APIs mit Port 50369:Listening - also wie du schon vermutet hattest. Bei Win11 24H2 sehe ich das auch - Remote Fw APIs mit Port 49749:Listening Ich würde das jetzt so verstehe, dass eigentlich beide für eine Verbindung bereit wären. Win11 24H2 das aber irgendwie nicht macht.

# for hex 0x6d9 / decimal 1753 : EPT_S_NOT_REGISTERED winerror.h # There are no more endpoints available from the endpoint # mapper. Da gibt's keinen RPC-Listener... Kannst ja mal lokal und remote schauen, ob Du was findest: https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 .\test-tcpports.ps1 -computer <IP-Adresse> -Ports 135 -IncludeEPM Da sollte ein RPC Highport auftauchen, der was mit Firewall im Namen hat. Kann Dir leider kein Beispiel dafür anbieten, hier läuft nix mehr "vor 24H2".

Moin, dafür müsste der Patch ja auch eingespielt worden sein. Darüber wissen wir hier nichts, soweit ich sehe. Gruß, Nils

Hallo zusammen, ich bin bei uns per Zufall darauf aufmerksam geworden, dass es bei Win11 24H2 nicht mehr möglich ist sich remote mit der Windows Defender Firewall per MMC zu verbinden. Unter Windows 10 22H2 funktioniert das noch einwandfrei. Auf beiden Clients (Win11 24H2 und Win10 22H2) sind die Firewall Regeln "Windows Defender Firewall Remoteverwaltung" (RPC und RPC-EPMAP) aktiv. Auch läuft der Windows Defender Firewall Dienst. Der IPSec Dienst läuft auch (wird bei der Fehlermeldung genannt) Für den Test sind die beteiligten Clients alle im gleichen VLAN um die zentrale Firewall auszuschließen. Auch wurde auf dem 24H2 Client die Windows Firewall deaktiviert. Trotzdem geht die Verbindung nicht. Die Verbindung per MMC von 24H2 zu 24H2 schlägt mit folgender Fehlermeldung fehl: Die Verbindung per MMC von 24H2 zu Win 10 22H2 funktioniert einwandfrei. Hat jemand eine Idee woran das liegen kann? Ist jetzt nicht so tragisch, aber würde mich interessieren ob wir hier nur irgendwas übersehen oder MS da etwas grundlegendes geändert hat. Viele Grüße

Ich warte mal auf das nächste Update, aber sonst wäre das sicher eine gute Option. Danke!

Vielleictht das ISO nochmal herunterladen und neu installieren.

Moin, ich dachte, das wäre weggepatcht worden, aber versucht mal, RC4 auf Domain Controller-Ebene wieder zuzulassen, zumindest bis alle Maschinen ihr Kennwort gerollt haben.

Ja mal ist es so, mal so.

Nicht generell. Ich habe einige Sever 2025 und keiner hat solche Probleme.

Hi Jan, danke für den Input. Nun scheint alles zu funktionieren. Jedoch stelle ich oft seltsames verhalten des Servers 2025 fest. Z.B. beim Herunterfahren hängt der Rechner, Installation werden nicht ausgeführt usw. Die Hardware ist ein Serverboard, Xeon Prozessor usw. Ich denke es gibt aktuell noch ein paar Bugs im Server 2025. Mal auf das kommende Update warten. Danke auf jeden Fall an alle für die Unterstützung. BG

Hallo zusammen, wir haben aktuell "massive" Probleme mit Anmeldeproblemen, die ich einfach nicht nachvollziehen kann. Ich würde behaupten, dass die Probleme auftreten, seit dem wir einen Windows Server 2025 DC mit im System haben, 12 Jahre davor hatten wir keinerlei diese Probleme. Die Probleme äußern sich wie folgt: Einige Rechner melden bei der Anmeldung "Benutzername oder Kennwort falsch". Wenn wir in dem Moment uns dann lokal Anmelden und Test-SecureComputerChannel machen, bekomme ich ein True. NSLookup hat auch die Domain sowie alle Domaincontroller aufgelöst usw. Zeit passt auch mit den DCs überein. Nach einem Neustart des Clients gehts dann immer wieder. Das Problem haben wir auch im gesperrten Modus, also wenn ein Benutzer seinen Rechner sperrt und wieder entsperren will. Im Log des Clients wird folgendes gemeldet: EventID 4625 MachineName TA-CLPC20005.xxx.local EntryType FailureAudit Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: S-1-5-18 Kontoname: TA-CLPC20005$ Kontodomäne: [DOMAINNAME] Anmelde-ID: 0x3e7 Anmeldetyp: 2 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: S-1-0-0 Kontoname: [Anmeldename] Kontodomäne: [DOMAINNAME] Fehlerinformationen: Fehlerursache: %%2304 Status: 0xc000006d Unterstatus:: 0x0 Prozessinformationen: Aufrufprozess-ID: 0x9e8 Aufrufprozessname: C:\Windows\System32\svchost.exe Netzwerkinformationen: Arbeitsstationsname: TA-CLPC20005 Quellnetzwerkadresse: 127.0.0.1 Quellport: 0 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: User32 Authentifizierungspaket: Negotiate ?bertragene Dienste: - Paketname (nur NTLM): - Schl?ssell?nge: 0 zur gleichen Zeit wird auf dem DC folgendes protokolliert: Ein Kerberos-Dienstticket wurde angefordert. Kontoinformationen: Kontoname: [Anmeldename]@[DOMAINNAME] Kontodomäne: [DOMAINNAME] Anmelde- GUID: {8ceb624b-4a79-43d5-9f30-fc3eacf3d33c} MSDS-SupportedEncryptionTypes: 0x0 (N/A) Verfügbare Schlüssel: N/A Dienstinformationen: Dienstname: TA-CLPC20005$ Dienst-ID: [DOMAINNAME]\TA-CLPC20005$ MSDS-SupportedEncryptionTypes: 0x1C (RC4, AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Domaincontrollerinformationen: MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Netzwerkinformationen: Clientadresse: ::ffff:10.1.10.38 Clientport: 53570 Angekündigte ETYPEs: AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC-NT DES-CBC-MD5 DES-CBC-CRC RC4-HMAC-NT-EXP RC4-HMAC-OLD-EXP Zusätzliche Informationen: Ticketoptionen: 0x40810000 Ticketverschlüsselungstyp: 0x12 Sitzungsverschlüsselungstyp: 0x12 Fehlercode: 0x0 Übertragene Dienste: - Ticketinformationen Hash des Anforderungstickets: s5yh1FJP7/QGNfIseWEklJBJwrWgI6rnxxwBYFb82qw= Hash des Antworttickets: Kd0//U3zlF76OWCXt/dK468UjDOx3yRqjxSDZW6014E= Es wurde ein Kerberos-Authentifizierungsticket (TGT) angefordert. Kontoinformationen: Kontoname: [Anmeldename] Bereitgestellter Bereichsname: [DOMAINNAME] Benutzer-ID: [DOMAINNAME]\ [Anmeldename] MSDS-SupportedEncryptionTypes: 0x24 (RC4, AES-SK) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Dienstinformationen: Dienstname: krbtgt Dienst-ID: [DOMAINNAME]\krbtgt MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Domaincontrollerinformationen: MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Netzwerkinformationen: Clientadresse: ::ffff:10.1.10.38 Clientport: 53569 Angekündigte ETYPEs: AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC-NT DES-CBC-MD5 Zusätzliche Informationen: Ticketoptionen: 0x40810010 Ergebniscode: 0x0 Ticketverschlüsselungstyp: 0x12 Sitzungsverschlüsselungstyp: 0x12 Vorauthentifizierungstyp: 2 Vorauthentifizierungsverschlüsselungstyp: 0x12 Zertifikatinformationen: Name des Zertifikatausstellers: Seriennummer des Zertifikats: Fingerabdruck des Zertifikats: Ticketinformationen Hash des Antworttickets: s5yh1FJP7/QGNfIseWEklJBJwrWgI6rnxxwBYFb82qw= ich weiß leider nicht mehr wo wir ansetzen sollen, es betrifft aktuell nur "wenige" einzelne Rechner, gefühlt werden es aber mehr. Hat jemand Ideen wo ich noch ansetzen könnte? Interessanterweise meldet der Client auch folgendes: 13:15:21 Der Computer konnte eine sichere Sitzung mit einem Domänencontroller in der Domäne DOMAINNAME aufgrund der folgenden Ursache nicht einrichten: Interner Fehler. Was interner Fehler hier bedeutet weiß ich nicht - ABER, dieser Fehler kommt erst eine ganze Weile nach den Meldungen oben. Auch finde ich im Log, dass er erfolgreich die Zeit mit dem DC synchronisiert usw. Ich wäre glücklich, wenn jemand eine Idee hat. Liebe Grüße

das war auch meine Vermutung - impliziert aber eine andere Interpretation von "günstig", als für die meisten Kunden üblich, die nur einen 2-Node-Cluster haben

Vermutlich wärst du selbst drauf gekommen. ;)

DAS nenne ich mal nen guten Tip, danke!

Vermutlich meinst du Fibre Channel SAN. Auch ein iSCSI SAN kann über Glasfaser gehen und ein FC SAN kann über Kupfer gehen ;)

Hi Nicht doch, das sind "bedauerliche Einzelfälle". VG Damian

Moin, das darunterliegende Protokoll - iSCSI., FC, SAS - hat nichts damit zu tun, wie zuverlässig das ganze funktioniert. Das Besondere an iSCSI *könnte* sein, dass Windows nur die ersten 10(?) Buchstaben des Maschinennamen für die IQN-Generierung verwendet. Wenn die Nodes also "HYPERVSERVER01" und "HYPERVSERVER02" heißen, ist es für das SAN derselbe IQN. Da kann es zu Fehlern kommen. Daher sollte man die IQNs kontrollieren und bei Bedarf anpassen, bevor man das ans SAN anschließt oder die LUNs für dieses Pärchen freizont. Die Cluster-Vorprüfung sagt Dir das übrigens, weil die SCSI-Reservierung nicht übertragen werden kann.

Hallo zusammen, Broadcom/VMware sammelt gerade massig Audit-Gelder bei vielen Kunden ein, „komisch“ dass Microsoft kurze Zeit später bei den „sündigen Kunden“ auch anklopft und ein Audit macht…komisch, oder „petzt“ da jemand über „Goldgruben“ ??? und wohl auch umgekehrt…“eine Hand wäscht die andere“. Ich sage schon immer „Die Welt ist schlecht und wir sitzen mitten drin“ Wird für einige wohl ein „teurer heißer Herbst“. viele Grüße, Franz

Hallo, zwei -Rechner, die auf die Selbe iSCSI-Quelle zugreifen, kann zu großen Datenverlusten führen. Ich habe gerade einen HyperV-Cluster gebaut. Zwei Knoten und ein, über Glasfaser angeschlossenes SAN. Das funktioniert einfach super. Alle redundant ausgelegt. Aktuell läuft die Migration der VMs auf den Cluster. Kann ich nur empfehlen. Denn so eine Lösung ist kostengünstig und zuverlässig. Warum also noh VM-Ware?