LigH

Wie schon erwähnt: Windows meldet, dass das Dokument aufgrund eines "Fehlers" nicht gedruckt werden kann. Ich möchte erstmal herausfinden, welcher Fehler das genau ist. Meine erste Idee war, in der Ereignisanzeige nachzuforschen, welche Fehler zu diesem Zeitpunkt aufgezeichnet wurden. Und wie auch schon erwähnt, habe ich dabei nur einen DCOM-Fehler in diesem Zeitraum gefunden. Und gehofft, dass sich vielleicht jemand an solche Arten von Fehlern erinnert. Hätte ja sein können, dass es MCSEs mit mehr Erfahrung in dieser Ecke von Windows gibt...

Ein genaues Datum kann ich nicht nennen, ist aber schon einige Monate her. Man kann ja nicht stundenlang herumbasteln, während die Kollegen daran arbeiten müssen... Nur einen der Treiber zu installieren würde bedeuten, den anderen Drucker bzw. MFC nicht an diesem PC nutzen zu können, was aber eigentlich das Ziel ist, beide verwenden zu können. Das funktioniert auf anderen PCs ja auch noch. Und das funktioniert auf anderen PCs auch mit WSD-Treibern und über WLAN. Mehr oder weniger zielloses Rumprobieren ist auch nicht die Lösungsstrategie, die mir hier vernünftig erscheint. Damit habe ich schon recht viel Zeit verbraucht. Ich hatte auf etwas mehr systematisches Vorgehen gehofft. Angefangen damit herauszufinden, welche Art von Fehler genau denn nun das Drucken verhindert. Am Ende sind vielleicht die Treiber an sich korrekt installiert, und eine andere Schnittstelle ist defekt (evtl. dank der halbjährlichen Windows-10-Funktionsupgrades im speziellen Ausnahmefall), dann wäre Neuinstallieren von Treibern auf Verdacht nur wieder zusätzliche Zeitverschwendung. Zum Ereignisprotokoll fällt keinem was ein?

Die wurden beide schon mehrfach deinstalliert und wieder neu installiert. Auch mit dem Herstellerprogramm, das beim vollständigen Entfernen helfen soll.

Ich habe im Netzwerk einen Windows-10-PC, von dem aus schon einmal alles problemlos funktionierte. Nachdem einmal die Druckertreiber für zwei verschiedene Brother-Drucker neu installiert wurden, ist nun das Drucken von diesem PC aus nicht mehr möglich. Laut Diagnose sollen die Treiber korrekt installiert sein. Der relevante Drucker (mit WSD-Treiber, via WLAN erreichbar) kann konfiguriert werden, sein Webdienst lässt sich im Browser aufrufen. Wenn aber ein Druckauftrag erzeugt wird, kann dieser wegen eines "Fehlers" nicht gedruckt werden (Windows 10 erzeugt dann rechts unten eine Meldung als Popup). Leider erkenne ich nicht, um welche Art von Fehler es sich handelt, was die Behebung natürlich erschwert. Wie sollte man hier nun systematisch vorgehen? Bisher bin ich auf die Idee gekommen, in der Ereignisanzeige nachzuschauen. Das einzige Ereignis, das mir zum Zeitpunkt des Druckfehlers als relevant auffällt, ist aber nur eine DCOM-Warnung, deren Analyse beschreibt, dass die Ausführung der Immersive Shell für diesen Benutzer nicht erlaubt wurde. Wie wahrscheinlich mag da ein Zusammenhang sein? Immerhin wäre die Behebung dieses Fehlers recht aufwändig, und ein Zusammenhang mit dem Druckproblem für mich nicht offensichtlich (außer bei der Uhrzeit des Ereignisses).

Alle PCs verwenden die gleiche Hardware (wurde sogar untereinander ausgetauscht) und die gleichen Treiber (von der selben Treiber-CD). Bitte auch bedenken: Die SSID des 5-GHz-Netzes wird erkannt. Es wird überhaupt versucht, sich zu verbinden. Ein falsches Kennwort wird als falsch erkannt. Das alles weist also für mich darauf hin, dass die unteren Ebenen der Netzwerkverbindung durchaus korrekt funktionieren.

In einem Gebäude befinden sich eine Telefonanlage mit Speedport-Router (ZyXEL 790) mit 2,4-GHz- und 5-GHz-Kanälen sowie eine Fritz-Box 3270 als Access Point nur mit 2,4-GHz-Kanal (5 GHz wurde hier deaktiviert wegen Kompatibilität zu b-Geräten). Mehrere PCs, teils mit Windows 7 oder Windows 10, können sich an jedem der Netze wahlfrei anmelden, das 5-GHz-Netz wird bevorzugt. Nur bei einem der PCs mit Windows 7 wird beim Versuch der Anmeldung an das 5-GHz-Netz (WPA2) ein unspezifischer Verbindungsfehler gemeldet (Verbindungen mit den beiden anderen 2,4-GHz-Netzen funktionieren einwandfrei). Wird ein falsches Kennwort eingegeben, wird auch korrekt gemeldet, dass das Kennwort falsch ist. Zur Behebung des Problems schlägt Windows lediglich vor, den Router neu zu starten, weitere Vorschläge kommen nicht. Hat jemand Ideen, welche Ursachen hier in Frage kommen, und Empfehlungen, wie man das Problem weiter eingrenzen könnte? ... Mir fällt zum Beispiel gerade ein, dass es wohl irgendwo noch eine Möglichkeit gab, die unterstützte Verschlüsselungstechnik (AES oder PSK) genauer auszuwählen.

Ja, danke, lesbar und auch irgendwie gleich vom Sinn und Zweck her verständlich. Sehr deskriptive Befehle, erinnert fast etwas an SQL-JOINs mit GROUPs, von Umfang und Struktur her. Auf jeden Fall reichlich Schlagworte zum Stöbern.

Wie sähe denn dann vergleichsweise ein Einzeiler für PowerShell aus, mit dem man alle vorhandenen Dateien nach dem Muster Text1_???.txt in Text1_Dummy3_???.txt mal eben schnell an der Kommandozeile umbenennen kann? So ein Beispiel würde mir sicherlich reichlich Syntax-Elemente liefern, nach denen ich dann weiter suchen kann. Und nein, das ist bei weitem nicht die einzige Aufgabe, die ich auf solche Art von Dateigruppen anwenden will, und die unterscheiden sich immer wieder...

Gut möglich; damit kenne ich mich aber überhaupt nicht aus. Da ist die Syntax ja grundlegend anders als in Batch.

OK, danke. Vielleicht schaffst du es auch noch, die überflüssigen Leerzeilen in den Code-Blöcken wieder zu entfernen, die jeder Bearbeitungsschritt da eingefügt hatte ... ich kann ja nun nicht mehr editieren. In der Zwischenzeit habe ich noch mehr ausprobiert. Es gab im IRC den Tipp, die FOR-Schleife auf die Ausgabe von "DIR /B" anzuwenden; da kommt aber ebenso mehr im Ergebnis heraus als erwünscht, wie wenn ich direkt mit FOR maskiere. Dies nützte also auch nichts: FOR /F "usebackq" %a IN (`DIR /B Text1_???.txt`) DO ECHO %a Zur Problemlösung verwende ich mittlerweile TCC/LE x64 (Take Command Console - Light Edition). Die wäre konfigurierbar, falls man Dateimasken nicht nur auf die LFN, sondern auch auf die SFN vergleichen wollte; Standard ist dort aber, nur die LFN zu vergleichen. Der kostenlose Funktionsumfang genügt mir.

Wenn ich in einem Verzeichnis sehr viele Dateien habe (evtl. über tausend), die am Anfang ihrer Dateinamen übereinstimmen, sich aber nach etwa dem 5. Zeichen unterscheiden, dann kann ich mich nicht mehr darauf verlassen, dass für das Jokerzeichen '?' noch die Regel gilt, dass es für exakt ein Zeichen steht. Auch unter Windows nach Vista ist immer noch eine Kompatibilität für kurze Dateinamen (DOS 8.3) aktiv, die auch beim Test auf Übereinstimmung von Dateiname und Suchmuster angewendet wird. Im Ergebnis kann es dann passieren, dass man z.B. in einer FOR-Schleife versucht, einen Befehl nur auf Dateien anzuwenden, deren Dateiname einer bestimmten Länge entspricht, indem man diese Länge mit einer entsprechenden Anzahl Fragezeichen vorgibt. Wenn das System dann aber die kurzen Dateinamen zum Vergleich heranzieht, wird auch das Suchmuster auf die Länge 8.3 gekürzt, und schon erscheinen auch solche Dateien als auf das Suchmuster passend, deren langer Dateiname viel länger ist als das ursprüngliche Muster. Beispiel zum Nachstellen: @ECHO OFF ECHO Text1_Dummy1... FOR /L %%a IN (0,1,9) DO FOR /L %%b IN (0,1,9) DO FOR /L %%c IN (0,1,9) DO ECHO %%a%%b%%c > Text1_Dummy1_%%a%%b%%c.txt ECHO Text1_Dummy2... FOR /L %%a IN (0,1,9) DO FOR /L %%b IN (0,1,9) DO FOR /L %%c IN (0,1,9) DO ECHO %%a%%b%%c > Text1_Dummy2_%%a%%b%%c.txt ECHO Text1... FOR /L %%a IN (0,1,9) DO FOR /L %%b IN (0,1,9) DO FOR /L %%c IN (0,1,9) DO ECHO %%a%%b%%c > Text1_%%a%%b%%c.txt ECHO Text1_??? ECHO Text1_??? > Text1.txt FOR %%a IN (Text1_???.txt) DO ECHO %%a >> Text1.txt Ergebnis (gekürzt): Text1_??? Text1_000.txt Text1_001.txt Text1_002.txt ... Text1_997.txt Text1_998.txt Text1_999.txt Text1_Dummy1_000.txt Text1_Dummy1_001.txt Text1_Dummy1_002.txt Text1_Dummy1_003.txt Wie lässt sich das nun verhindern? Kann man dafür sorgen, dass FOR ausschließlich die langen Dateinamen auswertet? Es ist zwar möglich, das zukünftige Erzeugen von kurzen Dateinamen auf NTFS-Volumes zu verhindern: fsutil behavior set disable8dot3 1 Nach einem Neustart kann man die schon vorhandenen kurzen Dateinamen auch löschen lassen: fsutil 8dot3name strip /f /s C: Allerdings wurde (auch hier) schon über Nebenwirkungen berichtet, z.B. Inkompatibilitäten in Netzwerkfreigaben (nun ja, möglicherweise nur mit heutzutage veralteten Windows-Versionen, aber wer weiß?), und Firmware von Consumer-Mediaplayern fiele mir dazu auch noch ein – bevor ich das anwende, würde ich da schon gern mehr wissen; vielleicht gibt es ja noch andere Methoden, dafür zu sorgen, dass ich einer Dateimaske aus Sicht eines Nutzers von langen Dateinamen vertrauen kann. _ P.S.: Der Kommandozeilen-Interpreter von JPSoft (TCC, früher 4DOS / 4NT) ließ sich dahingehend konfigurieren. CMD wird so eine Möglichkeit wohl nicht bieten?

Offenbar kann man hier besser spot-ten als helfen. Dieser Umgangston wäre dann für mich auch kein deutlicher Anreiz, einen der Teilnehmer hier dafür auch noch bezahlen zu wollen. Such ich also lieber anderswo...

Die Anfahrtspreise steigen sicher auch mit der Entfernung, oder?

@ DocData: In der Altmark ist die Auswahl an ebensolchen Spezialisten aber arg dünn. Und der eine, den ich mittelbar finden konnte, "muss sich erstmal darüber schlau machen" ... Darfst mir aber gern jemanden in dieser Region empfehlen. @ testperson: Nun ja, les ich mal, danke...

Immer noch keine Lösung in Sicht... Mittlerweile hat jemand den Verdacht geäußert, dass vielleicht der Windows Server explizit nicht auf interne Ports 80 weiterleiten mag, aus Sicherheitsgründen. Also habe ich mal in den Geräten den HTTP-Port auf 8080 konfiguriert. Auch damit keine Durchleitung. Bleibt mir nur weiter zu hoffen, dass jemandem ein wirklich grundsätzlicher Fehler auffällt. Wie schon geschrieben, Netzwerkprotokolle aus WireShark kann ich gern bereitstellen.