Besonders faszinierend an Windows finde ich, dass Fehlermeldungen, oftmals völliger Unsinn sind, geradezu frei erfunden. Sie sind dann nicht nur mies übersetzt, sie haben mit dem eigentlichen Problem einfach nichts zu tun, und weitere Diagnosemöglichkeiten hat man dank Microsofts Verschlossenheitspolitik nicht.
Eigentlich super, oder? Damit kann man die User so richtig fertigmachen: "Das bedeutet wahrscheinlich nichts — oder etwas völlig anderes." Selbst schuld, die liefern auch immer nur Meldungen wie "geht nicht" oder "ist kaputt".
Leider wollen die dann trotzdem, dass man was repariert. Und wo unter Linux ein Blick ins Logfile genügt, muss unter Windows einfach alles durchprobiert werden, egal wie abwegig. Im Laufe der Zeit werden die Vermutungen dann immer abstruser, bis man tatsächlich durch Zufall das Übel erkennt...
So geschehen in einem Netzwerk mit Windows-XP-Clients und einem
Samba-Server, der zwei vernünftige, mit
CUPS eingerichtete
PostScript-Drucker freigibt. Die Treiber werden wie üblich in der Freigabe
print$ auf dem Server hinterlegt und von den Clients bei Einrichtung der Drucker automatisch installiert.
Na ja,
halbautomatisch, denn man muss sie einmal
als Admin und dann nochmal
als User installieren. Diese kleinen Skurrilitäten ist man ja gewohnt.
Jahrelang funktionierte das, doch plötzlich weigern sich alle Rechner bis auf einen, auf einem der beiden Geräte zu drucken, oder gar Druckertreiber anzunehmen.
Es läge keiner im Netz, lügt Windows. Die Treiber von einem
Backup wiederherzustellen nützt nichts. Verschiedene Treiber von HP werden frisch heruntergeladen und durchprobiert — kein Erfolg:
Windows konnte an der angegebenen Position keinen Treiber finden, buhuhuu!
Rotznasensystem, blödes.
An dem einen Client, an dem es noch funktioniert, sind für die beiden
identischen Drucker
unterschiedliche Optionen verfügbar, obwohl der
selbe Treiber installiert wurde. Aha.
Nach Stunden des fehlgeleiteten Herumprobierens entdecke ich eine Statusmeldung in der Oberfläche des
"Universal-Printing"-Treibers von HP, testweise im
"dynamischen Modus" installiert:
Der Drucker HPsoundso ist kein kompatibles Gerät.
Das ist mir allerdings auch neu.
Sollten die Drucker womöglich kaputtgegangen sein? Nein, ein Probedruck über CUPS gelingt. Drucker-Reset und sogar ein Server-Neustart verändern erstmal nichts. Ein Rechte-Problem kann es auch nicht sein, die Clients können auf die Treiberfreigabe zugreifen.
Nein, eine Lösung die zu Windows passt muss her. Etwas
leicht abwegiges, gerade so, dass man nicht darauf kommen würde. Mal überlegen: Rechte... Rechte... — genau!
Eigentlich sollte ich ein
Klicklog führen. Ein kleines Buch, in dem steht, wo ich wann hingeklickt habe. Dann wäre mir nämlich sofort aufgefallen, dass ich von dem einen Client aus die Benutzerrechte der Druckerfreigabe
erweitert hatte. Wie konnte ich überhaupt so dumm sein, und den
Standard-Windows-Klickie-Weg dafür wählen?
Vielleicht wurde die Rechte
erweiterung als
Einschränkung umgesetzt? Das macht in der
Microsoft-Welt schon Sinn. Windows könnte gedacht haben, ich will nur die Rechte für die
lokalen Benutzer (die es nicht gibt) des einen Clients erweitern. Das ist natürlich mit einer
Einschränkung aller anderen verbunden.
Ich öffne die Verwaltung, doch die Ankreuzkästchen sind schon zurückgesetzt, so als wäre die Veränderung nie übernommen worden. Macht nichts, ich wähle in der Verwaltung den Postscript-Treiber erneut aus und bestätige. Ok, das mag jetzt
zusammenhangslos erscheinen, aber das ist ja mein Plan! Und tatsächlich funktioniert der Drucker nun wieder im ganzen Netz.
Yippieh!
Am nächsten Tag ist das Problem erstmal wieder da. Hat ja auch geregnet.
