mcdaniels

@WeingeistDanke werde ich mal ausprobieren. Müssten die Drucker aber dann nicht zumindest via Word ansteuerbar sein? (Selbst wenn man sie in der tollen "Druckerverwaltung" nicht sieht).

Ich hoffe ich verstehe deine Frage richtig: Ich gehe am Client auf: Systemsteuerung -> Hardware und Sound -> Geräte und Drucker Hier habe ich normalerweise von der Windows 10 Installation (vor dem Upgrade auf 11) ja Drucker angezeigt, die installiert sind. Jetzt fällt mir auf, dass z.B. nach dem Upgrade ein Drucker weg ist, der schon installiert war. Dann fängt das Spiel mit der Installiererei an, wie beschrieben.

@Weingeist wenn es allerdings die Härtung wäre, dann würde es ja auf diesem Wege gar nicht funktionieren. Die Krux ist ja, dass der (verschwundene) Drucker nach Installation eines beliebigen anderen Druckers (auf gleichem Wege), plötzlich wieder da ist.

Jep passiert direkt danach

Okay verstehe, weshalb es dann aber auf dem von mir beschriebenen Weg läuft, ist dennoch unerklärlich, oder?

Hallo @zahni ich kann dir nicht ganz folgen. Was meinst du konkret damit - bezogen auf das von mir durchgeführte Windows 11 24h2 inplace Upgrade?

Hallo zusammen, ich habe ein (aus meiner Sicht) sehr ominöses Problem. Ich betreibe einen Printserver (Server 2016). Auf diesem Printserver habe ich mehrere Netzwerkdrucker freigegeben. Bei einigen meiner Windows 11 24H2 Clients (nach einem inplace Upgrade von Windows 10) geschieht nun Folgendes: Zuvor vorhandene Netzwerkdrucker verschwinden aus der Druckerverwaltung. Wenn ich versuche, den (zuvor vorhandenen) Netzwerkdrucker via \\SRV-PRN --> danach Wahl des Druckers --> Kontextmenü "Verbinden" zu verbinden, bekomme ich die Meldung "Drucker nicht vorhanden". Wenn ich dann einen beliebigen anderen vorhandenen Drucker (der noch nicht verbunden ist) zu verbinden versuche, dann funktioniert dies meist. (In dem Fall kann das auch ein komplett anderer Druckertyp sein, wie der oben erwähnte Drucker). Nach dieser Aktion ist dann plötzlich der andere verschwundene Drucker auch wieder vorhanden. Was ich bereits versucht habe: Printserver neu starten Treiber am Druckserver aktualsieren & danach neu verbinden (=Drucker nicht vorhanden) Client durchstarten Druckspooler auf Client und Server neu starten Was grundsätzlich funktioniert: Drucker via IP direkt am Client installieren. Allerdings will ich das nicht in dieser Art installieren, denn ich fahre ja über den Druckserver. Habt ihr eventuell eine Idee? Danke!

+1 für das Eventlogging

Guten Morgen, um die Sache nun zu einem Abschluss zu bringen: Nach weiterer Recherche und Studium der Logdateien auf dem NAS, habe ich nun festgestellt, dass offenbar die an der Außenstelle tätige externe Firma mit einem Client, der nicht zu unserer Domäne gehört - mit Namen HOME_DS (oh Wunder!) - alle Sekunden mit fehlerhaften lokalen (NAS) Credentials auf das NAS zugreifen will. Ich nehme an, das NAS (Da Domainmember) leitet diese Anfrage dann an unseren DC weiter.... Das also löste das Problem aus. Hab das NAS aus der Domain geworfen, bis die externe Firma das löst (jetzt ist Ruhe).

Hallo, das war nicht das Problem. Hat sich bei mir einfach nicht geöffnet... Seite wurde halb geladen. Vielleicht hab ich auch schon zu viele Protokolle deaktiviert....

Alles klar, dann hänge ich meine GPOs für LLMNR und MDNS auch an die DCs, in der Hoffnung, dass mir nix um die Ohren fliegt.

Danke! Mal schauen was jetzt passiert... Sollte man diese grundsätzlich diese Protokolle auch auf den Servern abdrehen (MDNS LLMNR), oder ist das ev. in diesem Kontext nicht anzuraten?

Hallo und danke, geht der Link bei dir normal auf? Bei mir nämlich nicht.

Hallo, aufgrund meines letzten Beitrags ( Momentan MDNS. Etliche Clients sind hier noch am Werk. Das, obwohl ich via GPO (Computerrichtlinie) Folgendes gemacht habe: Open Windows Registry Editor Navigate to HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters create a DWORD "EnableMDNS" with the value “0”. Die GPO kommt am Client an, dennoch feuern die Clients weiter. Gibt es auch hier "irgendwo" noch ein Setting, das man tätigen müsste, oder sollte eigentlich mit dem Regkey dann Ruhe sein? Ich habe mir bereits einen Wolf gegoogelt Das sieht u.a. zb so aus (die 192.168.10.91 = ein Windows 10 Client) - angefragt werden Druckernamen, wobei eigentlich keine MDNS Abfragen von dem Client kommen dürften (=Regkey): Der Regkey am Client (per Regedit angeschaut) sieht so aus: Danke!

oder die Syno gegen ein neues Modell tauschen (die ist uralt -- gehört eh weg) btw. der Thread ist eh schon kilometerlang.... Habt ihr schon mal gesehen, dass ein PC via mdns versucht einen FQDN aufzulösen, wobei die Abfragen so aussehen im Wireshark. Es gibt mehrere Anfragen. Der gesamte FQDN wäre z.B. Srv-File.local Die Anfragen sehen so aus, wobei es mehrere Anfragen hintereinander sind: Erste Anfrage: s.local dann sr.local srv.local srv-.local srv-f.local srv-fi.local srv-fil.local Die finale Abfrage mit dem "korrekten" DNS Namen erfolgt dann nicht mehr. Für mich sieht das so aus, als ob da jemand Namen ausprobiert. Allerdings gibts es immer nur die Query aber keinen Respond.... Netzwerkforensiker müsste man sein... PS: MDNS hab ich heute via GPO / Registry abgedreht und muss auf den Restart der PC warten... (morgen)

das kann ich dir beantworten: Die DS hängt mit AD-Authentifizierung für die Shares (Als Domänenmember) in der Domain. Dennoch erklärt das (für mich) nicht, wo dieses verda**** \\HOME_DS herkommt. Auf dem Ding läuft an sich (bis auf die nicht deinstallierbaren) Standardapps nur SMB bzgl. Shares und erwähntes \\HOME_DS sehe ich nirgends. Aber vielleicht komm ich da ja noch dahinter. Das ist wenigstens mal etwas anderes, wie "ich kann mich nicht anmelden" ... wieso brauchen wir dieses komplizierte sinnlose 2FA, Ich hab meinen Authenticator gelöscht, weil ich dachte ich brauch ihn nicht mehr, mein PC ist aus... / kann es sein dass du ihn ausgesteckt hast? / nein, ich hab nur meinen Wasserkocher angesteckt... usw. Zeug...

ok werde ich mir anschauen. Es scheint aber definitiv von der Diskstation zu kommen. Diskstation ausgeschaltet: Ruhe. Auf der Diskstation aber nix von \\HOME_DS zu finden.

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 Jetzt kommt aber der Gag... ich habe jetzt mal aufgrund des Hinweises von @daabm eine DiskStation, die via IPSEC VPN Tunnel an uns angebunden ist, neu gestartet. Und jetzt ist der Eintrag verschwunden. Auf der Diskstation selbst finde ich aber nirgends den Eintrag \\HOME_DS. Ich kann mir keinen Reim drauf machen.... Entweder war das jetzt ein Riesenzufall, dass das Gerät das hier reinfunkt exakt zu dem Zeitpunkt als ich die Diskstation neu startete aufhörte den DC zuzuballern, oder es war tatsächlich die Synology Diskstation...... Ich muss mich korrigieren... Dachte grade, ich schau mal auf den zweiten DC nachdem der betroffene (DC3) das nicht mehr protokolliert... siehe da... jetzt ist die Meldung auf dem zweiten DC im Eventlog.... ich werd nicht mehr....

Habe jetzt via Netsh protokolliert, danach das File in Pcap umgewandelt und im Wireshark angeschaut. Ich finde den String HOME_DS nirgends. Dennoch protokolliert der DC fröhlich weiter fehlgeschlagene Anmeldungen von dort. Jetzt muss ich mich mal sammeln und überlegen, was ich noch machen könnte... Interessant, aber mühsam.

Habt ihr eventuell noch einen Tipp für mich wie man die Traces (.etl) öffnen kann. Das Programm das im Artikel von @NorbertFe erwähnt wurde gibt es nicht mehr (habs dann aus anderen Quellen geholt und läuft in einen Fehler). Ich konvertiers mir mit Releases · microsoft/etl2pcapng Cisco haben wir nicht... :-P Aber ok, dann schalte ich den oberen Eintrag mit dem Namen auf nicht konfiguriert. Mann, Mann, Mann... das ist irgendwie alles *******

@testperson @NorbertFe und auch alle anderen. DANKE ihr seid halt einfach ein Hammer. Jetzt ist zumindest mal LLMNR still und ich kann mich diesem HOME_DS widmen. Ich vermute das steht deshalb doppelt da drin, weil MS die Aufmerksamkeit der Admins prüfen will... sehen sie es, oder sehen sie es nicht. Ich bin jedenfalls durchgefallen und kann deshalb wohl nie bei MS anfangen.

Hallo, ich habe jetzt LLMNR per GPO abgedreht, per RSOP geprüft, ob die Richtlinie auf meinem Client ankommt und dann via \\PC-IRGENDWAS im Explorer auf meinem PC eine Namensauflösung nach einem PC Namen angestoßen, den es nicht gibt. Und... siehe da... Mein PC fragt noch immer per LLMNR nach dem Hostnamen. Folgende Richtlinie hab ich verwendet: Computer Configuration -> Administrative Templates -> Network -> DNS Client Turn Off Multicast Name Resolution auf enabled gestellt. Ich liebe es

so gehört sich das ja auch

Danke für die Info. Ganz wohl ist mir dabei eh nicht... Oha, das stammt ja direkt von dir Absolut korrekt.

du meinst wer hier mit der 224.0.0.252 rumballert? Das sind offenbar ein paar Clients, soweit ich am Freitag dann noch gesehen habe und es war auch ein Plotter im Spiel. Was ich halt auch überhaupt nicht mehr verstehe ist, dass der DC hier noch immer im Eventlog dies \\HOME_DS Probleme protokolliert, obwohl ich es im Wireshark nicht finde. Ich werde den Wireshark mal auf dem DC installieren, vielleicht sehe ich dort ja mit dem ProcessMonitor etwas....