mcdaniels

stimmt schon. Nach wie vor beschäftigt mich aber, weshalb das an einem Sonntag um ca. 07.00h angefangen hat (Da ist niemand in der Firma).

Hallo eine Synology ist im Einsatz aber die darf und kann DNS. Ich werde dem am Montag auf den Grund gehen (hoffe ich) Die unnötigen Protokolle werde ich definitiv abdrehen. Interessant nebenbei: Bei Ping auf 224.0.0.252 meldete sich der Plotter mit der IP 192.168.10.80... Kann mir das jemand erklären?

Ich halte euch auf dem Laufenden... DANKE!

Hallo, ja das hab ich auch gelesen... Und werde ich auch umsetzen. Allerdings trotzdem komisch was da läuft. V.a. mit diesem komischen HOME_DS. Mal weiter wiresharken...

Hallo, mir ist heute aufgefallen, dass unser DC, der alle FSMO hat im Sicherheits-Eventlog alle Minuten (oder tlw auch kürzere Abstände) eine Event ID 4776 (Überwachung gescheitert) protokolliert, deren Inhalt offenbar der Versuch ist die Anmeldeinformation für ein Konto zu prüfen. Gestartet haben die Einträge am 3. November. Inhalt: Es wurde versucht, die Anmeldeinformationen für ein Konto zu überprüfen. Authentifizierungspaket: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Anmeldekonto: (ist leer) Arbeitsstation: \\HOME_DS Fehlercode: 0x0000064 Es gibt bei uns kein: \\HOME_DS (ich nehme mal an, das scheint ein Client zu sein? Ich habe dann Wireshark angeworfen und festgestellt, dass diese HOME_DS Anfragen von einem Plotter kommen und das LLMNR Protokoll betreffen und auch die IP 224.0.0.252 im Spiel ist, die eindeutig etwas mit LLMNR zu tun hat. Also Plotter mal testweise abgedreht.... Die Meldungen gingen aber weiter (auch jetzt noch). Per Wireshark kann ich den String \\HOME_DS aber nicht mehr in der Paketinfo finden. Weitere "Wireshark-Forensik" brachte dann zu Tage, dass sich offenbar mehrere Domänen-PC des LLMNR Protokolls bedienen, obwohl sie Domänenclients sind und DNS ordnungsgemäß auflösen könnten. Im Wireshark sieht man auch, dass sie FQDN per LLMNR auflösen wollen, die problemlos via DC-DNS aufgelöst werden könnten. Soweit ich mich richtig informiert habe, ist das LLMNR Protokoll dafür da, um in kleinen Netzwerken den DNS quasi zu ersetzen. Oder, besser formuliert, kann es in Netzen ohne DNS eingesetzt werden. Für mich ist jetzt völlig unklar: Wie es sein kann, dass die Clients LLMNR sprechen wollen, obwohl sie den DC DNS verwenden können um die angefragten Namen aufzulösen und vor allem weshalb diese gescheiterten Überwachungen mit der Arbeitsstation \\HOME_DS weitergehen, obwohl der Wireshark nichts mehr sieht. Ich habe auch gelesen dass LLMNR gerne missbraucht wird (LLMNR poisoning) um User quasi auf andere Seiten umzuleiten... Ist jetzt natürlich ein etwas fader Beigeschmack, obwohl ich nicht denke, dass wir kompromittiert worden sind. Zumindest konnte ich bislang nichts finden... Das heißt wiederum noch lange nicht, dass trotzdem etwas im Argen liegt. Was mich aber stutzig macht ist, dass die Einträge am 3.11 gestartet sind. (Ohne Aktion unsererseits) Wenn ich mir die Queries anschaue, dann spricht hier zumindest gegen eine MITM-Attack (LLMNR poisioning) dass die ursprüngliche LLMNR Query dann nicht von einem "anderen" Endpunkt beantwortet wird. Es kommt anscheinend ganz einfach gar keine Antwort. Momentan spielt sich wohl lt. Wireshark wenig ab. Der DC protokolliert aber nach wie vor oben erwähnte Meldung. Aktuell sieht es so aus (Queries aber kein Response): Kann sich hier jemand vorstellen was hier los sein könnte? Ich könnte / sollte wohl jedenfalls mal LLMNR und NBT-NS abdrehen. Allerdings muss dieses Verhalten ja von "irgendjemandem" oder "irgendetwas" ausgelöst werden.... Vielen Dank im Voraus!

Jep hat nicht geklappt... Vielleicht ist auch dieses System hier einfach verbogen. Habs jetzt platt gemacht und neu hochgezogen. Und siehe da - das Update lässt sich installieren. Danke aber für den Tipp!

Hallo zusammen, ich versuche bei Win 11 24H2 (Build 26100.2033) das CU 2024-11 zu installieren, scheitere aber mit Fehler 0x800f081f. Soweit ich nachgelesen habe, kann dies von einem Virenschutz verursacht werden, der den Updatedownload bzw. das heruntergeladene Update quasi beeinträchtigt. Testhalber habe ich den Virenschutz entfernt, die Updatekomponenten des Client rückgesetzt und dann das Update erneut angestoßen. (brachte nix) Der Download (vom WSUS!) funktioniert. Nach einiger Zeit des Installierens wirft das System aber oben genannten Fehler. Wenn ich mir das Update aus dem Update Catalog lade und manuell starte, bekomme ich den Fehler: 0x800f0838 Ist euch ein derartiges Problem bekannt? Gibts dafür eine Lösung? Danke!

Hallo zusammen, mal eine Frage an die Gurus hier. Weiß jemand von euch weshalb das Feature "Recall" unter 24H2 auch bei X86 Pcs aktiv ist und manuell deaktiviert werden muss (dism)? In den Features wird nichts aufgeführt. Ein Deinstallieren ist nicht möglich. Es gibt eine GPO die Recall abdreht, jedoch bleibt das Feature aktiv. (Ist das normal bzw. würgt die GPO Recall dann auf anderem Wege ab und das Feature bleibt aktiviert?) Würde mich echt interessieren, was ihr davon haltet bzw. wie ihr die Sache seht, denn im Internet gibts ja mittlerweile etliche Quellen die meinen MS könnte Recall auch auf x86 einführen (ohne NPU). Die brennenste Frage ist aber: Weshalb wird hier auf x86 ein nicht deinstallierbares (verstecktes?) Feature aktiv ausgerollt? (MS Fehler oder Absicht). Danke!

jep, gute Idee! Danke!

na gekündigt wurde ja nicht -- achso, du meinst ja nicht das Abo Danke! Wir werden da jetzt jedenfalls einen Backupadmin anlegen.

Die Sache konnte gestern noch gelöst werden, ich bekam innerhalb von 2 Stunden dann noch einen Rückruf und 2FA konnte danach neu eingerichtet werden. Der Support war echt gut. Ich war überrascht.

nun wird eine Verifizierung durchgeführt. Nachdem auf keines der Konten mehr ein Zugriff besteht (auch nicht Email) wurde das via Festnetztelefon gemacht. Die sehr nette Dame am Ende der anderen Leitung meinte, dass sie hofft, dass das die Datenschutzabteilung akzeptiert und dass es jetzt 24h dauern wird, bis sie eine Rückmeldung hat.

gestern wurde offenbar außerhalb der Dienstzeiten angerufen und ein Mail ist auch gesendet worden. Nun gibt es neue Anrufzeiten.... na da bin ich mal gespannt. Jedenfalls muss man aber sagen, dass MS sich im Zeitfenster gemeldet hat.

Korrekt... Mittlerweile ist noch ein bisschen mehr rum....

Ich bekomme in 1h bis 24h einen Rückruf

Wahnsinn.... Das Codewort des Tages ist "Microsoft Azure". Ich spreche jetzt jedenfalls mit einem Menschen! Danke @NorbertFe

@testperson das ist über einen Distributor gelaufen, den es allerdings jetzt nicht mehr gibt bzw. der nichts mehr mit M365 zu tun hat. Es passt halt wiedermal alles zusammen. Wäre toll, wenn du hier weiterhelfen könntest.

du kannst ja mal versuchen, die Hotline anzurufen. Da redest du mit einem Roboter..... Vielleicht mag sie ja den österreichischen Dialekt nicht. Jedenfalls konnte Sie dann, als ich schon dezent angenervt war, mit meiner Antwort "Ich möchte Bill Gates heiraten" auch nichts anfangen. Es ist wohl so wie bei I-Robot und dem dortigen Hologramm: "Meine Antworten sind begrenz, Sie müssen die richtigen Fragen stellen".... vielleicht gibts ja ein Keyword für den menschlichen Support.

Die sind einfach zu groß.... für den Kunden ist das halt sehr angenehm. Gott sei Dank, muss man dafür zahlen... (Abo usw) Du kannst zurück gerufen werden, dafür muss man sich aber einloggen.....

Die deutsche Nummer führt mich wieder zum automatischen Assistenten, der mich dann einfach auf eine Webseite verweist und dann....... vielen Dank, dass Sie MS angerufen haben, auf Wiedersehen... Hast du eventuell noch eine Kontaktemailadresse, die man da in Anspruch nehmen könnte? Ein Traum! Gerade MS Österreich (Rezeption) angerufen. Zitat: "Es gibt bei MS keinen Menschen mehr, den Sie anrufen können....." Vorschlag: Neues Konto erstellen (irgendeines) und dann mit diesem Konto das Problem schildern und einen Rückruf anfordern. Schöne neue Welt, in der wir da leben...

Hallo, danke für die Info. Die österr. Nummer funktioniert leider nicht... läutet nicht mal und die Verbindung wird sofort beendet. Leider gibts nur ein Adminkonto.

Hallo, wir haben leider das Problem, dass wir auf eines unserer Azure/MS-Cloudkonten nicht mehr zugreifen können, da der ehemals zuständige Admin sämtliche Daten, die den zweiten Faktor angehen, quasi "mitgenommen" hat. Ich versuche nun schon den ganzen Vormittag bei MS jemanden zu erreichen, werde aber per Automatismus immer wieder nur auf Online-Ressourcen verwiesen, die es wiederum nötig machen sich mit dem betroffenen Konto einzuloggen, was ja wiederum nicht funktioniert, da wir keinen Zugriff auf den zweiten Faktor haben. Könnt ihr mir hier eventuell weiterhelfen? Wohn kann man sich sonst noch wenden? Danke!

bislang 1x. Also vermutlich dann ein Überbleibsel des Neustarts? Würde sich dann auch damit decken, dass repadmin /showreps eine ordnungsgemäße Replikation meldet.

Hallo zusammen, ich habe hier eine Server 2019 Domain mit 2DCs. Einer der DCs hat alle FSMO. Nach einem Stromausfall, bei dem alle zwei Server geregelt herunter gefahren sind, habe ich auf dem DC mit allen FSMO folgendes in den Eventlogs stehen: Event ID 2092 Quelle ActiveDirectory_Domainservices Dieser Server ist der Besitzer der folgenden FSMO Rolle, die jedoch nicht als gültig eingestuft wird. Für die Partition, die das FSMO enthält, wurde dieser Server seit dem letzten NEustart nicht erfolgreich mit einem beliebigen Partner repliziert. Replkationsfehler verhindern die Verifizierung dieser Rolle. Vorgänge, die eine Kontaktaufnahme mit dem FSMO-Betriebsmaster erfordern, sind nicht erfolgreich, solange dieser Zustand nicht behoben wird. FSMO Rolle CN= Schema, CN=Configuration, DC=bruckmur, DC=local Benutzeraktion: Die ursprüngliche Synchronisierung ist die erste Replikation, die von dem System beim Start durchgeführt wird. Das Scheitern der ursprünglichen Sync. ist eventuell die Ursache dafür, dass die FSMO nicht verifiziert werden kann. Dieser Prozess wird im KB-...... erklärt. Dieser Server verfügt über mindestens einen Replikationspartner, und die Replikation scheitert bei allen Partnern. Führen Sie den Befehl REPADMIN /showrepl aus, um die Replikationsfehler anzuzeigen. Beheben Sie den fraglichen Fehler. ...... ..... Der Witz dabei: REPADMIN /showrepl zeigt mir auf allen beiden Servern eine korrekte Replikation an. Kann ich die Warnung also ignorieren, oder müsste man hier aktiv werden. Tipps sind wie immer willkommen. :-) Danke!

findet nix -- also wie du vermutest up to date. Test-PC 2 angeworfen: Via WSUS nach Updates gesucht --> Am WSUS bzgl. Sicherheitsupdates nach "nicht genehmigten/erforderlichen" Updates gesucht. Siehe da, Windows 11 Updates sind da. Notiz an mich selbst: Vor 13:00h nichts mehr posten. Hoffe, dass ich dann mental leistungsfähiger bin und keinen "Fürnixpost" mehr starte.