JohnDoo

Immer noch nix Neues... MS und HP stehen in Kontakt. Bei MS konnte das Problem anhand meiner gelieferten Daten reproduziert werden. MS hat diese Daten an HP geschickt und auch HP konnte das Problem reproduzieren. Allerdings war das vor 3-4 Wochen. Seitdem kommt HP nicht weiter in die Gänge...

@Lian Beispiel: Auf deinem Server hast du bereits den Inbox-Treiber für den HP LJ 4000 installiert und Queues damit angelegt. Danach aktualisierst du die unidrv.dll. In diesem Fall passiert mit den Queues nix weiter und es kommt auch nirgendwo eine Meldung hoch, dass Treiber nicht signiert sind. Nach der Aktualisierung der unidrv.dll musst dann für einen neuen Drucker den Inbox-Treiber für z.B. den HP LJ 5000 zusätzlich installieren. In diesem Fall kommt dann der Hinweis (das Popup), dass der Treiber nicht signiert ist. Die gleiche Meldung würde auch kommen, wenn du eine Reinstallation des bereits vorhandenen Inbox-Treibers für den HP LJ 4000 machen würdest. Nur in diesen beiden Fällen kommt der Hinweis, dass der Treiber nicht signiert ist, wenn die aktuellste unidrv.dll im Einsatz ist. @all Noch nix gravierend Neues von MS bzw. HP...

@Lian Queues werden nie als nicht signiert angemeckert. Dieser Hinweis kommt nur, wenn man einen Treiber installiert. @all So, bzgl. des "Deleting - Printed"-Problems wurde der Kontakt zwischen HP und MS hergestellt. Jetzt unterhalten sich die beiden miteinander. Mal sehen, was dabei rauskommt...

Kleines Schmankerl zwischendurch: (hat nichts mit dem Problem des Threads zu tun) Wir haben mit dem Ausrollen von SP2 auf unsere Printcluster gewartet, weil es mit der darin enthaltenen unidrv.dll Probleme geben kann. Nachdem dafür ein Hotfix verfügbar war, haben wir SP2 ausgerollt. Nach dem Ausrollen haben wir festgestellt, dass nur auf der physikalischen Maschine die DLL aktualisiert wurde. Auf den virtuellen Maschinen waren nach wie vor ältere Versionen der Datei vorhanden. Einen Nachfrage bei MS ergab, dass man mit einem Workaround die aktuelle DLL auch auf die virtuellen Maschinen bekommt. Dazu muss man auf der virtuellen Node eine Queue mit einem Inbox-Treiber anlegen. Danach ist dann die aktuelle DLL auch auf der virtuellen Node. Das ist das eine. Das andere ist, dass mit der aktuellen unidrv.dll sämtliche Inbox-Treiber, die ja alle signiert sind, bei einer Installation als nicht-signiert angemeckert werden. Dieser "Indesign-Bug ist bei MS bekannt. Ob es dafür irgendwann mal einen weiteren Patch gibt, weiß man jedoch nicht. Soviel zum Thema "an Standards halten". :D Offensichtlich hält sich MS noch nicht einmal an seine eigenen Standards...

Ich habe, wie es vorher hier im Thread auch schon jemand getan hat, einen Server mit W2k3 SP1 installiert. Danach habe ich genau einen Druckertreiber und eine Druckqueue eingerichtet. => Das Drucken eines Problem-Dokuments hat problemlos funktioniert. Danach habe ich den Server mit SP2 aktualisiert und Treiber- bzw. Queue-mäßig nichts geändert. => Das Problem-Dokument blieb mit dem Status "Deleting - Printed" in der Queue hängen. Lustigerweise handelt es sich bei dem Treiber, den ich getestet habe, um die aktuellste Version, die bei HP zu bekommen ist, und zusätzlich ist dies auch noch ein WHQL-Treiber... :confused::D:shock: Die Daten und einen PrintMig-Abzug habe ich an MS geschickt. Dort lässt sich damit das Problem auch nachvollziehen. Allerdings will MS das Problem mit HP klären. MS umternimmt momentan nichts, um evtl. festzustellen, welche Komponenten im SP2 das Problem verursachen oder was beim Problem-Dokument anders ist als bei anderen Dokumenten des gleichen Typs...

Ganz so eindeutig sehe ich das noch nicht... Nachdem Anfang des Jahres noch alles problemlos lief, gibt es meiner Ansicht nach min. 3 mögliche Fehlerquellen: 1.) Print Prozessoren Diese wurden mit an Sicherheit grenzender Wahrscheinlichkeit nicht geändert, da wir keine regelmäßigen unregelmäßigen Treiberupdates durchführen. Könnte höchstens sein, dass diese betroffenen Prozessoren schon immer fehlerhaft gewesen sind. Dann bliebe allerdings die Frage, warum alles funktioniert hat. 2.) SP2 für W2k3 Da die Probleme erst nach der Installation von SP2 aufgetreten sind und laut MS auch bzgl. Printing einiges mit SP2 geändert wird, könnte hier das Problem liegen. 3.) Office-Patches Bei uns werden natürlich auch die aktuellsten Office-Patches eingespielt. Da dieses "Deleting-Printed"-Problem bis jetzt ausschließlich gewisse Office-Dokumente betrifft, könnte auch hier etwas falsch gelaufen sein. Bezüglich betroffener Dokument-Typen hatte ich auch hier schon einmal nachgefragt. Dazu hat aber niemand etwas geschrieben. Vielleicht diesmal...

@Velius Davon lasse ich bei einem Produktiv-System mit ca. 1000 Druckqueues die Finger. Man kennt ja die MS-Deinstallationsroutinen... @Lian Unsere Canon's und Kyocera's bringen keine Print-Prozessoren mit. Da ist alles ok und es bleiben keine Spools in den Queues hängen.

Welcher Hersteller wird es wohl sein? :confused:;) HP natürlich. Ich kenne jetzt so aus dem Stehgreif auch keinen anderen, der Print-Prozessoren mitbringt. Die anderen Hersteller, die bei uns im Einsatz sind, brauchen zumindest keine. Es bleiben aber trotzdem die Fragen offen: Warum hat der gleiche Print-Prozessor unter SP1 wunderbar funktioniert? Und warum betrifft es nach SP2 nur einzelen Excel-Dokumente?

So, ich konnte auf unserem Test-Cluster eines unserer Problem-Cluster nachbilden. Dort taucht auch das "Deleting - Printed"-Problem auf... In der Zwischenzeit hat es für mich den Anschein, dass es hauptsächlich Excel-Dokumente betrifft, die dann auf diesen ****en Status gehen. Da aber wiederum nicht jedes Dokument, sprich, die meisten werden problemlos gedruckt und verschwinden aus der Queue. Manche bleiben aber in den Queues hängen... Wie sieht das bei euch aus? Welche Dokumenttypen bleiben bei euch in den Queues hängen? @Lian Nach dem Umstellen auf WinPrint werden die Problem-Dokumente problemlos gedruckt und verschwinden auch aus den Queues. Aber wie schon gesagt, das ist leider keine Option für uns... Es sind auch Treiber mit den unterschiedlichsten Print-Prozessoren betroffen...

@Lian Kann ich gerne mal tun, aber als permanente Lösung können wir das nicht umsetzen. Die aktuelle unidrv.dll kommt nicht mit einem Druckertreiber sondern mit einem MS-Patch (KB944203). Mit diesem Patch wird allerdings nur die lokale DLL aktualisiert. Die DLL in den Cluster-Ressourcen bleiben auf ihrem Stand. Für mich sieht es auch so aus, das eine SP-Installation die DLL in den Cluster-Ressourcen nicht aktualisiert, da diese bei uns unetrschiedliche Stände haben. @Velius Dieses Problem ist schon länger bekannt. Hierfür haben wir bei uns ein Script laufen, das bei allen angelegten Ports SNMP deaktiviert.

Hallo. @Lian Mit dem Umstellen auf WinPrint fallen zusätzliche Funktionen wie z.B. Booklet-Printing weg. Das wird von unseren Anwendern häufig genutzt. Wenn wir das jetzt "Abschalten" würden, würden bei uns die Telefone heiß laufen. Gegen Inbox-Treiber spricht grundsätzlich nix, außer dass es für die aktuellen und auch schon etwas älteren Drucker keine gibt... @vmorbit Danke für deinen Test und diese Info. Somit scheint es ja wirklich am SP2 zu liegen... Habt ihr mit SP-Installationen ähnliche Erfahrungen gemacht, wie ich oben beschrieben habe? Sprich, dass auf den Cluster-Ressourcen Dateien nicht aktualisiert werden? – @Lian Sicher liegt es mit hoher Wahrscheinlichkeit an Treibern, wenn es auf dem Cluster Probleme gibt. Deshalb setzen wir schon seit geraumer Zeit nur noch Treiber ein, die von MS signiert sind. Für die wenigsten Treiber gibt es von den Herstellern eine explizite Cluster-Freigabe. Nach einer SP-Installation sollten aber noch alle Treiber genauso wie vorher funktionieren... Stell dir vor, du bringst dein Auto zum Kundendienst in die Werkstatt. Als du es wieder abholst, sagt dir der Meister, dass die Pumpe für die Servolenkung abgebaut werden musste, damit der neue Ölfilter reinpasst...

Hallo Leute. Sorry, hat etwas gedauert... Wir hatten in der Zwischenzeit wieder 2 Ausfälle. Dazu habe ich diverse MPS-Reports an MS zur Auswertung geschickt. Die Analyse dort hat etwas gedauert. Jetzt kam dabei heraus, dass die Print Prozessoren von HP schuld sein sollen. Wir sind der Meinung, dem ist nicht so, weil es mit diesen Print Prozessoren vor SP2 ja auch keine Probleme gab. Um weiteres Material für MS zu haben, wäre ich euch dankbar, wenn mir Betroffene folgende Fragen beantworten würden: - Traten die Probleme nach SP2 bei euch auf? - Verwendet ihr Standalone-Printserver oder Print-Cluster? - Welche Druckermodelle sind bei euch mit "deleting - printed" betroffen? - Verwendet ihr Inbox- oder Herstellertreiber? Vielen Dank schon mal... – Im Zuge der Fehleranalyse kam die Sprache auch auf den Patch KB944203. Dieser soll die unidrv.dll nach der Installation von SP2 aktualisieren, weil es ansonsten zu Problemen kommen kann. Wir haben diesen nach jeder SP2-Installation nachgezogen. Wir setzen Print-Cluster ein und ich musste feststellen, dass die unidrv.dll zwar auf dem lokalen System auf dem aktuellsten Stand war, auf den virtuellen Ressourcen bzw. den Shared-Disks liegen aber nach wie vor die unterschiedlichsten Versionen. Der Patch aktualisiert also nur das lokale System. Ich hätte ja zumindest vermutet, dass auf den Shared Disks die unidrv.dll liegen sollte, die beim SP2 dabei ist, aber auch das ist nicht der Fall. Deshalb wissen wir nicht, ob Cluster-mäßig mit SP2 evtl. auch andere Dateien nicht oder vielleicht nur teilweise aktualisiert wurden. Habt ihr ähnliche Erfahrungen?

@ Lian Das war nur ein kurzer Mailverkehr. Deshalb ist leider kein Re-Open möglich. Auf unseren Clustern sind je nach Standort zwischen 200 und 2000 Druckqueues installiert. Von der SNP-Problematik habe ich hier das erste Mal etwas gehört... Könnte aber vielleicht etwas mit den Problemen zu tun haben... Da wir doch ziemlich viele Queues und Drucker hosten und diese entsprechend frequentiert sind, könnte ich, wenn überhaupt, erst am Wochenende auf den Kisten etwas tun, wenn die Kollegen entsprechend zustimmen. Deshalb ist es mir nicht möglich, den Patch so ohne weiteres einzuspielen. Paralell habe ich heute einen Call bei MS aufgemacht. Dort werde ich das SNP-Thema auch mal ansprechen. Mal sehen, was dabei rauskommt...

Auf dem einen Printcluster betraf es gestern neben ein paar anderen hauptsächlich HP LaserJet 4300 Drucker. Ich werde mal mitschreiben, welche Modelle es alles betrifft. Laut Google sind auch Inbox-Treiber davon betroffen. Bei uns sind hauptsächlich HP-Drucker im Einsatz. Daneben gibt es noch Canon-MuFus und einige Kyoceras. @Lian Es handelt um diese Meldung. Diesbzüglich war ich letztes Jahr auch schon mit MS in Kontakt. Da kam die Aussage, dass dieses Event hin und wieder mal auftreten kann, aber keine Auswirkungen haben sollte. So war es bis vor kurzem auch. Jetzt tritt dieses Event vermehrt auf und kann nur durch einen Reboot gebremst werden.

Hallo zusammen. Wir haben vor kurzem unsere W2k3 Print Cluster auf SP 2 aktualisiert. Seitdem haben wir folgende Probleme: 1. Bei einigen Druckermodellen gehen die gedruckten Dokumente in der Queue auf den Status "deleting - printed" und bleiben dort so stehen. Man kann diese auch nicht händisch löschen. Erst nach einem Reboot bzw. einem Restart des Printspoolers verschwinden diese meistens, aber auch nicht immer. 2. Es kommt im Eventlog vermehrt zu Einträgen mit der EventID 6161. Wenn diese Events zu häufig hintereinander auftreten, dann streikt der Printserver über kurz oder lang und es ist ein Reboot nötig. Fällt jemandem zu diesen Problemen etwas ein? Für Hilfe wäre ich echt dankbar.

Wird mir wohl nix anderes übrig bleiben als es mal mit der Sicherung in ein Binary-File zu versuchen. Wobei natürlich die Gefahr besteht, dass die Einstellungen nicht mehr 1:1 passen, wenn ich einen aktuelleren Treiber einspiele. Irgendwie hatte ich mir das einfacher, übersichtlicher und sicherer vorgestellt...

Hallo. Danke für die Antwort. Die prnadmin.dll verwende ich bereits. Allerdings lassen sich darüber nur sehr begrenzte Einstellungen zu den Druckqueues machen. Man kann damit z.B. die "advanced printig featueres" aktivieren bzw. deaktivieren. Welche Papierformate unter den "device settings" eingestellt sind, kann man damit nicht auslesen, geschweige denn setzen. Und genau dafür suche ich eine Lösung, eben u.a. die "device settings", die "printing defaults" unter "advanced" und die "printing preferences" unter "general" auszulesen bzw. zu setzen. Kennt dafür jemand Scripts oder andere Freeware oder so?

Hi. Wir setzen mehrere Print-Cluster von MS ein und möchten jetzt Treiber aktualisieren bzw. auf allen Cluster-Nodes gleichziehen. Am Saubersten realisiert man das ja, wenn man die betroffenen Printqueues auf einen anderen Treiber umstellt, den alten Treiber löscht, danach bootet, dann den neuen Treiber installliert und den Druckqueues wieder zuordnet. Hört sich soweit ganz gut an... Damit die AW später allerdings nicht unnötig und berechtigt motzen, müsste man sich vorher alle Einstellungen einer Printqueue harausschreiben oder Screenshots machen und nach der Treiberaktualisierung bei jeder einzelnen Queue wieder passend einstellen. Nachdem die Treiberaktualisierung selbst schon einen erheblichen Aufwand bedeutet (siehe oben), würde das Herausschreiben der Einstellungen und das spätere erneute Setzen diesen Aufwand vervielfachen. Aus diesen Gründen bin ich auf der Suche nach Scripts oder ähnlichen Helferlein... Kennt da von euch jemand was? Ich wäre sehr dankbar. Ach ja, es handelt sich um W2k3-Cluster...

Danke für die schnelle Antwort. Ich habe das gerade mal getestet und du hast recht, dass ein Standard-User nix ändern darf. Allerdings möchten wir, dass die SAP-Jogis diverse Einstellungen selbst ändern können sollen. Ein Power-User darf wiederum zu viel. Unsere Server sprechen englisch und ich möchte nach Möglichkeit die Laschen "General", "Sharing", "Ports" und "Security" der Druckereigenschaften per Policy ausblenden oder deaktivieren.

Tach zusammen. Ich bin u.a. für die Administration von Druckservern (w2k3 / w2k) zuständig. Über diese Druckserver laufen auch die SAP-Ausdrucke. Um uns nun etwas Arbeit zu ersparen, wollen wir den SAP-Jogis die Möglichkeit geben, diverse Druckereinstellungen selbst zu verändern. Sie sollen aber auf keinen Fall wichtige Einstellungen ändern dürfen. Dazu zählt z.B., dass sie Druckqueues nicht umbenennen oder nur bereits installierte Treiber verwenden dürfen. Deswegen bin ich auf der Suche nach Group Policies, über die man z.B. diverse Laschen bei den Druckereinstellungen ausblenden oder Einstellungen für Änderungen deaktivieren kann. Ich weiß, dass es z.B. für "Anzeige" in der Systemsteuerung solche Policies gibt, aber für die Druckereigenschaften habe ich noch nix gefunden. Kennt jemand von euch dokumentierte oder nicht-dokumentierte Policies, über die man die Druckereigenschaften einschränken kann? Bin für jede Hilfe dankbar.

Hat denn niemand eine Idee? Ich habe nämlich keine mehr...

Tach. Ich habe ein ähnliches bzw. das gleiche Problem wie miboe. Es geht um einen Lexmark Optra W810. Dieser hängt über eine HP JetDirect-Box im Netzwerk. Auf dem W2k-Server ist der Drucker mit einem Standard-TCP/IP-Port eingerichtet und freigegeben. Das Drucken hat auch immer einwandfrei funktioniert. So weit, so gut. Der Drucker musste nun in Reparatur. In der Zwischenzeit habe ich als Netzwerkdrucker einen HP LaserJet IV an die JetDirect-Box angeschlossen. Auf dem W2k-Server habe ich dann einen neuen Drucker und einen weiteren TCP/IP-Port mit der gleichen IP-Adresse wie beim Lexmark angelegt. Auch da hat das Ausdrucken immer geklappt. Der Lexmark-Drucker kam wieder zurück und ich habe alles wieder umgestöpselt. Wenn ich aber jetzt von einer Arbeitssation auf den Lexmerk drucken will, dann kommen (wenn es gut läuft) einige Seiten heraus und danach steht am Server die Fehlermeldung "Druckerordner - Fehler beim Schreiben auf Diskette". *???* Kennt jemand eine Lösung für diese komische Fehlermeldung??? Folgendes habe ich schon versucht (leider ohne Erfolg): - alle Drucker auf dem Server gelöscht (natürlich auch die Freigaben dazu) - alle eingerichteten TCP/IP-Ports gelöscht - den Lexmark-Drucker neu angelegt und während der Installation einen neuen TCP/IP-Port eingerichtet Momentaner Status: Nachdem das Drucken über den Server nicht funktioniert, habe ich den Drucker auf den Arbeitsstationen als lokalen Drucker mit einen TCP/IP-Port eingerichtet. Da funktioniert das Drucken auf den Netzwerkdrucker wieder problemlos. Deshalb kann es weder am Drucker noch an der JetDirect-Box liegen. Noch einmal die Frage: Kennt jemand eine Lösung für diese komische Fehlermeldung???