JohnDoo

Hallo Leute. Ich habe einen Win7 64bit Client. Auf diesem habe ich einen Drucker namens "Testdrucker" angelegt und als Port "FILE:" zugewiesen. Dieser Drucker ist auch als "Testdrucker" freigegeben. Wenn ich nun in die Eigenschaften des Druckers gehe und auf "Testseite drucken" klicke, kommt das kleine Fenster "Ausgabe in Datei umleiten" und ich kann einen Pfad und einen Dateinamen angeben. So weit, so gut... Nun öffne ich auf diesem Client eine DOS-Box (cmd) und setze folgenden Befehl ab: echo Das ist ein Test > \\computername\Testdrucker Nachdem dem "Testdrucker" der Port "FILE:" zugewiesen ist, sollte man jetzt eigentlich erwarten, dass wieder das kleine Fenster "Ausgabe in Datei umleiten" erscheint und man einen Pfad und einen Dateinamen angeben kann. Tut es aber nicht. Warum??? Stattdessen wird ein "normaler" Druckauftrag erzeugt, der in der Druckerqueue landet und nach kurzer Zeit auf Fehler läuft. Unter XP hat das so immer wunderbar funktioniert. Kann mir jemand sagen, warum das unter Win7 nicht geht bzw. wie ich das hin bekomme?

Hallo zusammen. Ich habe auf einem Win7-Client einen lokalen Drucker namens Testdrucker eingerichtet und auch so freigegeben. Als Port des Druckers ist "FILE:" eingestellt. Nun möchte ich in einer cmd-Box folgenden Befehl absetzen: echo TESTAUSDRUCK > \\%computername%\Testdrucker Danach sollte eigentlich das kleine Fenster kommen, in dem man den Pfad und Dateinamen für die Druckdatei eingibt. Das Fesnter kommt aber nicht und stattdessen landet der Druckauftrag in der Druckqueue und läuft auf Fehler. Unter WinXP funktioniert das genau so wie gewünscht. Wie bekomme ich das auch unter Win7 hin, dass das kleine Fenster für die Pfad- und Dateiangabe kommt? Hat jemand eine Idee?

So wie es aussieht, fällt niemanden dazu mehr etwas ein. Leider... Naja, mit dem Workaround funktioniert es ja zumindest. Nochmals vielen Dank für die Hilfe.

Normalerweise müsste es doch auch möglich sein, die Funktionen der prnadmin.dll von einer Access-DB aus zu nutzen, oder? Ich habe dazu mal in der DB einen Verweis auf die prnadmin.dll gesetzt und folgendes kleines Programm geschrieben: Dim oPrn As Object, oDrv As Object Set oPrn = CreateObject("PrintMaster.PrintMaster.1") Set oDrv = CreateObject("Driver.Driver.1") For Each oDrv In oPrn.Drivers("\\server") MsgBox oDrv.ModelName Next Set oPrn = Nothing Aber auch hier funktionieren die beiden "CreateObject"-Anweisungen problemlos. Und sobald die "For Each"-Schleife abgearbeitet werden soll, kommt die Fehlermeldung "Der an einen Systemaufruf übergebene Datenbereich ist zu klein". Das ist die gleiche Meldung in grün bzw. auf deutsch. Aber warum kommt diese Meldung?

.Net-Versionen auf dem Client: 1.1.4322 2.0.50727 3.0.04506.30 .Net-Versionen auf dem Server: 1.1.4322 2.0.50727 Auf dem Server ist kein .Net 3 installiert und dort läuft das Script. Sollte .Net 3 auf dem Client für den Fehler verantwortlich sein? (Kann ich mir nicht verstellen.) Auf dem Client gibt es keine oledb-DLLs. Das sollte aber nicht die Ursache sein, denn das Script läuft ja auf dem Client, wenn man die Objekte nacheinander und nicht gemeinsam nutzt. Die prnadmin.dll ist auf beiden Systemen die gleiche.

Ähm..., da muss ich jetzt leider passen. Wie findet man am schnellsten und einfachsten die verschiedenen Versionen heraus? So tief stecke ich da leider nicht im Thema...

Hallo Dirk. Ja, so bin ich vorgegangen. Habe das Script jetzt aber angepasst und arbeite nur noch mit einer Schleife. In dieser re-dimensioniere ich das Array mit "ReDim Preserve". Das klappt ganz gut. Danke für den Tipp. Ich kann es auch nicht ändern... :o Ideal wäre jetzt noch, wenn man irgendwie den Grund für die Fehlermeldung herausfinden würde... Nichtsdestotrotz möchte ich mich an dieser Stelle für die super Hilfe bedanken.

Hallo Dirk. Ich lege momentan das Array an, ermittle über eine Schleife die Anzahl der Druckermodelle, re-dimensioniere das Array mit Redim und schreibe dann wiederum über eine Schleife die Daten ins Array. WMI scheidet aus, weil man damit nicht die virtuellen Nodes eines Clusters auslesen kann. WMI geht immer nur auf die physikalische Maschine bzw. einen Standalone-Server. Ich frage mich halt nur, warum das Script, das auf dem Server läuft, auf dem Client bei der "For Each"-Schleife diesen Fehler bringt. Sind da Buffers zu niedrig oder gibt es Speicherprobleme oder... Sowohl auf dem Server als auch auf dem Client ist der WSH 5.7 drauf. Fällt dir dazu evtl. noch etwas ein?

@Cybquest Wie d.stegemann schon geschrieben hat, ein separates ADODB-Objekt anlegen funktioniert ohne Fehler... @d.stegemann Der Workaround mit dem Zwischenspeichern der Werte in einem Array und danach erst in die Access-DB schreiben funktioniert. --- Tja, jetzt stellt sich halt die Frage: Welchen Weg gehe ich? Nachdem man im voraus immer nicht weiß, wieviele unterschiedliche Druckermodelle auf einem Server sind, muss man zuerst die Anzahl ermitteln, damit man danach das Array entsprechend re-dimensionieren kann. Das ist halt etwas umständlich, funktioniert aber... Die Variante, die auf dem Server läuft und bei der beide Objekte gleichzeitig verwendet werden können, wäre diesbezüglich wesentlich eleganter... --- Übrigens: Die Fehlermeldung "The data area passed to a system call is too small" in meinem obigen Script bezieht sich immer auf die Zeile, in der die "For Each"-Schleife stehtund kommt nicht (!) beim Anlegen des Objekts. Das hatte ich vorher vergessen zu erwähnen und vielleicht hilft es ja weiter. Habe ich da etwas falsch gemacht? Sollte aber nicht sein, weil das Script ja auf dem Server so läuft... Fällt hierzu noch jemandem etwas ein?

@d.stegemann Das mit dem Zwischenspeichern in Arrays werde ich mal versuchen. Ich melde mich dann dazu wieder... @Cybquest Der Hotfix bezieht sich anscheinend nur auf SQL Server 2000. Ich will aber per VB Script in eine ganz normale Access-DB schreiben. Somit hilft mir der Hotfix nix. Trotzdem danke. --- Interessant: Bisher habe ich das Script immer nur auf einem WinXP-Client gestartet und dabei den Fehler erhalten. Nun habe ich das Script auf einem Win2k3-Server laufen lassen. Und da läuft es ohne Fehler durch! Komisch... Auf dem Server ist noch nicht einmal ein Office oder so installiert. Was könnte zwischen XP und Win2k3 der Unterschied sein?

Hallo Scripter! Ich habe folgendes kleines (gekürztes) VB-Script: Set oMaster = CreateObject("PrintMaster.PrintMaster.1") Set oCon = CreateObject("ADODB.Connection") For Each oDriver In oMaster.Drivers(sServer) WScript.Echo "DriverName : " & oDriver.ModelName Next Set oMaster = Nothing Über das Script möchte ich die Drucker eines Druckservers auslesen und in einen Access-DB schreiben. Die Verbindung zur Access-DB ist noch nicht vollständig implementiert. Wenn ich das Script, so wie es oben steht, mit "cscript script.vbs" in einer Shell ausführe, bekomme ich die Fehlermeldung "The data area passed to a system call is too small". Sobald ich die Zeile Set oCon = CreateObject("ADODB.Connection") auskommentiere, läuft das Script ohne Fehler und listet mir die Druckermodelle auf. Woher kommt der Fehler "The data area passed to a system call is too small"? Und wie bekomme ich diesen weg?

Ich bin hier weiter am Testen... Ich habe mir auf meinem Client gerade einen IPP-fähigen Drucker als Netzwerkdrucker verbunden. Das funktioniert so: Beim Einrichten des Druckers muss man als URL "http://DruckerIP/ipp angeben und danach den passenden Treiber auswählen. Das hat auch wunderbar funktioniert. Wenn ich jetzt jedoch eine Testseite auf diesen Drucker drucken will, erscheint der Druckerjob nicht in der Warteschlange und im Eventlog habe ich einen 6161-Eintrag. Weiß jemand ob es hier evtl. irgendwelche Policies oder so gibt, die hier etwas sperren könnten? Auf dem Client ist die Firewall aus und über Port 80 (also http) komme ich auf den Drucker bzw. auf dessen Webinterface. Am Drucker selbst ist IPP-Druck aktiviert. Ich weiß nicht mehr weiter...

Hi. Ich möchte mal das Internet Printing über den IIS testen, weil es damit auch möglich ist, verschlüsselt über https zu drucken. Der IIS läuft auf W2k3. Unter anderem bei Heise habe ich dazu folgende Anleitung gefunden: heise Netze - 19.09.06 - Überall drucken Nach diese Anleitung habe ich bei meinem IIS das Modul für Internet Printing hinzugefügt. Am Client (XP) werden mir im Browser über die passende URL auch alle auf dem IIS freigegebenen Drucker und sonstige Informationen zu den Druckern angezeigt. Ich kann mir am Client auch, wie beschrieben, über den passenden Link für den entsprechenden Drucker (http://SERVER/printers/DRUCKERNAME/.printer) einen Drucker verbinden bzw. einrichten. Wenn ich jedoch auf diesen über http verbundenen Drucker einen Ausdruck schicke, passiert nichts. Im Eventlog habe ich dazu einen 6161-Eintrag mit dem Hinweis, dass der Ausdruck nicht erfolgte. Der Druckauftrag taucht nicht einmal für ein paar Millisekunden in der Druckerqueue auf. Selbst die Testseite taucht nicht auf und erzeugt einen 6161-Eintrag. Hat jemand eine Idee? Fehlt auf meinem Client was? Laut Anleitung bringt XP schon alles mit, oder doch nicht?

Wir haben u.a. das Problem, dass vom UPD 4.7 z.B. der HP CLJ 3800 nicht als Farbgerät erkannt wird. Außerdem kommt es zu Problemen, wenn der UPD 4.7 PCL 5 und UPD 4.7 PS gleichzeitig installiert sind...

Gibt es noch keinerlei Erfahrungen mit dem UPD (Universal Printing Driver) 4.7 von HP? Hat ihn noch keiner im Einsatz oder sogar ausgerollt?

So, der Fall hat sich zumindest seitens HP erledigt... Es wird keine neuen Treiber für die betroffenen Drucker geben, weil die meisten der Modelle mit dem UPD (Universal Printing Driver) abgedeckt sind und damit das "Deleting-Printing"-Problem nicht auftritt. Die wenigen nicht darin enthaltenen Modelle werden nicht weiter berücksichtigt, weil diese schon älteren Datums sind und dafür neue angeschafft werden sollten, laut HP. Jetzt müssen halt die Anwender bzw. Admins schauen, dass sie möglichst auf den UPD umstellen. Die Frage ist nur, welche Probleme man sich mit dem UPD einhandelt...

Seit knapp einer Woche gibt es ja den HP UPD 4.7. Bei dem soll es jetzt u.a. möglich sein, die nervigen Popups abzuschalten. Außerdem soll man Queues auch manuell konfigurieren können, ohne dass der Drucker am Netz ist. Hat jemand mit diesem UPD 4.7 bereits Erfahrungen gesammelt?

HP hat uns für den BIJ 2300 einen Beta-Treiber zur Verfügung gestellt. Mit diesem Treiber tritt das "Deleting - Printed"-Problem nicht mehr auf. Offensichtlich sind fehlerhafte Treiber für das Problem verantwortlich. Der Beta-Treiber soll jetzt noch von Microsoft zertifiziert und danach zum Download bereit gestellt werden. In Klärung ist noch, ob es für die anderen betroffenen Modelle auch aktualisierte Treiber geben wird...

Nachdem die Firmware eines betroffenen Druckers bereits auf dem aktuellsten Stand war, hatte HP die Vermutung, dass es an der Firmware der Jetdirect, also der Netzwerkkarte des Druckers, liegt. Diese habe ich daraufhin aktualisiert. Es bleiben aber nach wie vor die Druckjobs mit "Deleting - Printed" in der Queue hängen. Das war also nicht die Lösung....

Hat denn niemand eine Idee?

Hallo. Auf unseren Druckservern ist mir bei einigen Queues aufgefallen, dass diese doppelt unter "Printers" in der Registry stehen. Da gibt es z.B. den Eintrag für den Drucker "prn123" und gleich danach steht der Eintag "prn123,0" oder "prn123,2". Weiß jemand woher diese Einträge "xxx,0" mit dem Komma und einer weiteren Zahl kommen? (Komma 0 bzw. Komma 2) Wie bekommt man diese weg? Ich habe auch schon versucht, eine Queue zu löschen, habe dann den ",2"-Eintrag per Hand aus der Registry gelöscht und danach die Queue neu angelegt. Wenn ich dann wieder in die Registry schaue, ist auch wieder der ",2"-Eintrag da.

So, jetzt gibt es etwas Neues... HP hat festgestellt, dass bei dem Excel-Dokument, das Probleme macht, im Seitenlayout als Papierformat A3 eingestellt ist. Wenn man das auf A4 umstellt, wird der Druckjob aus der Queue gelöscht und bleibt nicht mit dem Status "Deleting - Printed" hängen. Ich habe dann selbst eine neues Excel-Dokument erstellt und auf A3 eingestellt. Auch dieses Dokument blieb dann mit "Deleting - Printed" hängen. Das gleiche gilt auch für Word-Dokumente, bei denen eine "falsches" Papierformat eingestellt ist. An HP habe ich geschrieben, dass man nicht verlangen kann, dass immer das passende Papierformat eingestellt ist. Ich erwarte, dass in einem solchen Fall trotzdem die Druckaufträge aus der Queue gelöscht werden. Was am Drucker dann rauskommt ist in diesem Fall zweitrangig. Viel wichtiger ist, dass die Queues leer bleiben.

Immer noch nix Neues, außer dass HP zum 2. Mal den Fehler reproduzieren kann...

Also uns wurde von verschiedenen Herstellen primär den PCL5-Treiber einzusetzen und wenn es damit Probleme gibt, dann den PS-Treiber. Abgesehen von Plottern halten wir uns auch daran. Wir setzen hauptsächlich HP-, Canon- und Kyocera-Drucker ein. Mit Lexmark-Druckern hatten wir auch schon Probleme. Deshalb wurden diese soweit es ging abgeschafft. ----- Von HP gibt es seit kurzem den sog. UPD (Universal Printing Driver). Habt ihr den schon mal getestet oder im Einsatz? Welche Erfahrungen habt ihr damit? Gibt es damit Probleme?

Hallo zusammen. Welche Druckertreiber von welchen Herstellern laufen eurer Meinung nach am stabilsten und zuverlässigsten auf Printservern / Printclustern? PCL5 oder PCL6 oder PS? HP, Kyocera, Canon, Ricoh oder oder oder?