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).

vor 28 Minuten schrieb Weingeist:

Eine Frage hätte ich dazu aber noch: sprichst Du eigentlich von der richtigen Druckerauflistung oder der Geräteauflistung wo auch die Drucker drin sind? Das sind zwei komplett unterschiedliche Dinge. Die Geräteauflistung ist ziemlich buggy. Die richtige Druckerauflistung mit vernünftigen Treibern, das erste mal durch einen Admin installiert und zuverlässig per FQDN verbunden ist dagegen üblicherweise völlig unproblematisch. Treiber von Billig-Geräten verhinderten in der Vergangenheit aber gerne mal die zuverlässige Auflistung. Ich weigere mich heute sowas zu installieren. ;)

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.

vor 15 Minuten schrieb Sunny61:

Passiert das direkt nach dem Inplace Upgrade? Falls ja, probier es mal mit W11 23H2, das 24H2 soll ja noch ein paar Fehler enthalten.

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).

vor 35 Minuten schrieb Lian:

Der Link passt nicht 100%ig, daher ist er auch nicht hervorgehoben...

 

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.... 

vor 5 Minuten schrieb NorbertFe:

Natürlich auch für Server abschalten. Alles weg, was man nicht aktiv benutzen "will oder muss".

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:

1. Open Windows Registry Editor
2. Navigate to HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
3. 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!

vor 8 Minuten schrieb NorbertFe:

Tjo.... mal synology anrufen ;)

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)

vor 52 Minuten schrieb NorbertFe:

Wäre ja auch eher interessant, welcher Prozess von der Diskstation sich irgendwie auf Ressourcen deiner Domain zugreifen will. Fallen mir ja nur andere SMB Shares oder LDAP usw. ein.

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...

vor 6 Minuten schrieb NorbertFe:

Schalte doch mal netlogon logging aktiv und schau da nach. Hat mir schon einige Male geholfen in solchen Fällen.

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.

vor einer Stunde schrieb NorbertFe:

Wie sieht so eine Meldung im Eventlog denn aus? 

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

vor 26 Minuten schrieb NorbertFe:

Nicht einfach beide abschalten, sondern das richtige (siehe obigen Thread). Bin ich bei zwei Kunden schon auf die Nase gefallen, weil die VPN Lösung von Cisco das nutzte. ;)

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

Gerade eben schrieb NorbertFe:

Jupp, kommt aus einem Projekt, wo man nix auf dem DC installieren durfte ;)

so gehört sich das ja auch

vor 11 Minuten schrieb NorbertFe:

Wenn man wireshark nicht auf einem dc installieren will, geht das übrigens auch mit netsh.

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

vor 11 Minuten schrieb NorbertFe:

zu Plotter usw. Das sind Funktionen, die man immer als erstes abschalten sollte. Gibt’s ja noch ein paar weitere, die bei Nichtnutzung im Idealfall nur Traffic verursachen und im worstcase Lücken öffnen die man ohne sie nicht hätte.

Absolut korrekt.

vor 11 Minuten schrieb NorbertFe:

Solange man nicht genau weiß, welches Gerät da rumblökt, wirds natürlich immer schwer. Was spricht denn wireshark dazu, wer da broadcasts schickt?

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....