FranklyFrank 0 Geschrieben 17. August 2016 Melden Teilen Geschrieben 17. August 2016 Hallo allerseits, Seit mehreren Tagen plagt mich nun schon dieses mysteriöse Problem :( Vorab zur Umgebung: Hyper-V Server mit 2x Windows 2012 R2 Server (1x Active Directory und 1x Software, Daten, etc) mehrer Win 7 Pro Client Computer 2x Multifunktionsdrucker mit Scanner (1x HP und 1x Olivetti ) Problem: Für die Netzwerkscanner ist ein Ordner auf dem Server (Software) freigegeben auf dem die Dokumente gespeichert werden. Die Clientcomputer haben problemlosen Zugriff auf den Ordner, aber wenn die Geräte scannen melden sie nur "Anmeldefehler". (auch mit Anmeldedaten des Domänenadministrators) Drucken auf den besagten Geräten funktioniert problemlos. Derzeitiger Workaround: Wenn ich auf einem beliebigen anderen Rechner oder auf dem AD-Server einen Ordner freigebe und einrichte funktioniert es problemlos, aber mit jeglichen Freigaben auf dem Software-Server funktioniert es nicht. Versuchte Lösungen: Anderen Ordner Freigeben (auf selben Server) Andere Benutzer verwenden Berechtigungen/Freigabe auf Jeder setzen Bin für jegliche Anregungen Dankbar! mfg Zitieren Link zu diesem Kommentar
meinerjunge 10 Geschrieben 17. August 2016 Melden Teilen Geschrieben 17. August 2016 Hallo, hier ist deine Lösung https://social.technet.microsoft.com/Forums/de-DE/e9ff7803-a19e-4bf3-9ffc-c93ee5edcbe5/server-2012-r2-nach-patchday-kein-scantosmb-mglich?forum=windowsserver8de genauer: https://support.microsoft.com/en-us/kb/3165191 alternativ kannst du SMB 2 und 3 abschalten. MfG Meiner Zitieren Link zu diesem Kommentar
FranklyFrank 0 Geschrieben 17. August 2016 Autor Melden Teilen Geschrieben 17. August 2016 Danke für die schnelle Antwort! Für die erste Lösung ist ein Server-Neustart erforderlich - kann über Erfolg/Misserfolg also erst am Abend berichten. Zitieren Link zu diesem Kommentar
Sunny61 811 Geschrieben 17. August 2016 Melden Teilen Geschrieben 17. August 2016 Du kannst auch einfach den dazugehörenden Dienst einmal neu starten und testen. Alternativ dann später den Server neu starten. Das passt heute wieder wie die Faust aufs Auge, gestern war wieder Patchday. ;) Zitieren Link zu diesem Kommentar
zahni 561 Geschrieben 17. August 2016 Melden Teilen Geschrieben 17. August 2016 (bearbeitet) Mir fällt bei der "Lösung" für ein Sicherheitsproblem nur der Holzhammer ein. Genauso gut hätten die auch das WPAD-Gedöns ganz entfernen können. bearbeitet 17. August 2016 von zahni Zitieren Link zu diesem Kommentar
FranklyFrank 0 Geschrieben 17. August 2016 Autor Melden Teilen Geschrieben 17. August 2016 Leider funktioniert es auch nach dem Vorschlag von meinerjunge noch nicht :( -> habe das mit den registry einträgen versucht -> habe SMB 2 abgeschalten -> funktionierte ebenfalls nicht Ich vermute es hängt nicht mit Windows Updates zusammen sondern vielleicht mit DNS Einträgen (da hab ich ein paar Konfigurationen geändert) aber wie dieses spezielle Problem damit zusammenhängen könnte ist mir schleierhaft. Bin für weitere Lösungsvorschläge dankbar! Zitieren Link zu diesem Kommentar
Sunny61 811 Geschrieben 18. August 2016 Melden Teilen Geschrieben 18. August 2016 Welche Konfigurationen im DNS hast Du geändert? Lösungsvorschlag: Ändere es wieder zurück so wie es vorher war. :) Zitieren Link zu diesem Kommentar
FranklyFrank 0 Geschrieben 18. August 2016 Autor Melden Teilen Geschrieben 18. August 2016 @Sunny61 das ist leider nicht möglich, bzw. das würde im Gesamten Netzwerk zu Problemen führen (darum hab ich's ja geändert). Aber wenn die DNS Einstellungen schuld wären, dann würde das Problem nicht auf nur einen speziellen Server auftreten ... Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 18. August 2016 Melden Teilen Geschrieben 18. August 2016 (bearbeitet) Zitat sondern vielleicht mit DNS Einträgen (da hab ich ein paar Konfigurationen geändert) Moin, wenn am MF die IP des Servers als Ziel eingetragen, dann spielt die Namenauflösung, auch die per DNS keine Rolle.. Ich nehme mal an, das MF ist nicht in die Domäne aufnehmbar? Oder doch? Hat das MF dafür doch eine Funktion? Oder kann dafür upgradet werden, schon beim Hersteller geschaut? bearbeitet 18. August 2016 von lefg Zitieren Link zu diesem Kommentar
Sunny61 811 Geschrieben 18. August 2016 Melden Teilen Geschrieben 18. August 2016 Firmwarestand von den Geräte hast Du überprüft? Gibt es aktuellere Firmware? Notfalls beim Hersteller direkt nachfragen. Zitieren Link zu diesem Kommentar
testperson 1.729 Geschrieben 18. August 2016 Melden Teilen Geschrieben 18. August 2016 Hi, bei MFPs würde ich den Scan2File immer über FTP realisieren. Gruß Jan Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 19. August 2016 Melden Teilen Geschrieben 19. August 2016 Hört sich so an (auch aus den anderen Threads heraus), als ob der Scanner versucht, über SMB over Netbios (Port 139) mit dem Software-Server zu kommunizieren, mit den anderen Servern aber über 443 (SMB over TCP). Ersteres wurde durch den Patch offenbar (sinnvollerweise) abgedreht. Nimm einen Wireshark und verifizier das mal. Danach kann man da die Ursache suchen, warum der Scanner zu dem einen Server nicht über 443 geht. Und solange dir jemand nicht genau sagen kann, was er mit einer Umkonfiguration erreichen will, lass bitte die SMB-Protokolle, so wie sie sind! Blub Zitieren Link zu diesem Kommentar
FranklyFrank 0 Geschrieben 21. September 2016 Autor Melden Teilen Geschrieben 21. September 2016 So jetzt hab ich endlich das überprüfen können. so wie der Mitschnitt aussieht passiert beides - zuerst versucht er über 445 zu verbinden bekommt dann ein RST, ACK und nach dem Reset versucht er es mit Netbios 139 nochmal und endet ebenfalls in einem Reset, ACK vom Server. Hier mitschnitt von Wireshark drucker -> server | TCP 74 1388 → 445 [sYN] Seq=0 Win=16384 Len=0 MSS=1460 WS=1 TSval=225368583 TSecr=0 server -> drucker | TCP 445 → 1388 [sYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 drucker -> server | TCP 66 1388 → 445 [ACK] Seq=1 Ack=1 Win=17376 Len=0 TSval=225368583 TSecr=297794339 drukcer -> server | SMB 128 Negotiate Protocol Request server -> drucker | TCP 54 445 → 1388 [RST, ACK] Seq=1 Ack=63 Win=0 Len=0 -> danach versucht er es über TCP 139 mit selben ende netstat -ano zeigt, dass 0.0.0.0:445 abgehört wird (vom Prozess System) 127.0.0.1:445 wird nicht abgehört serverip:445 wird nicht abgehört -> aber es sind einige andere verbindungen über serverIp:445 hergestellt Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.