Dan More 10 Geschrieben 12. Februar 2010 Melden Teilen Geschrieben 12. Februar 2010 Moin, ich habe da mal eine Frage. Folgendes: Server 2003 R2 als Druckserver, läuft als VM. Im Einsatz sind bei uns HP Drucker und Konica Minolta Mopierer. Für die HP Drucker benutzen wir den Universal PS Treiber. Nun kommt es vereinzelt vor, dass ein User einen Drucker bei sich installiert hat, aber irgend ein Problem damit hat. Die Hotline löscht den Drucker und will ihn neu installieren. Bekommen aber die Fehlermeldung: Sie haben keine ausreichenden Zugriffsrechte, um die Verbindung mit dem Drucker herzustellen. In der Regel kann ich den Drucker dann aber über "Start - Ausführen - \\servername\druckername" installieren. Und danach geht es dann auch wenn ich über "Start - Einstellungen - Drucker und Faxgeräte" gehe. Das Problem tritt auch nie bei zwei Usern gleichzeitig auf, die auf ein und denselben Drucker zugreifen möchten. Manchmal hilft es auch nur, wenn sich ein Admin am Rechner anmeldet und den Drucker mal installiert und dann der User. Die Berechtigungen passen alle und das ganze ist auch nicht auf die HP Drucker bezogen sondern passiert auch bei den Konicas. Irgendwelceh Ideen? Client BS ist XP Prof. An ein Hardware/Treiber Problem glaube ich nicht, da es dann alle User dieses Druckers betreffen würde. Zitieren Link zu diesem Kommentar
solinske 10 Geschrieben 12. Februar 2010 Melden Teilen Geschrieben 12. Februar 2010 Sind die Drucker im AD veröffentlicht? Zitieren Link zu diesem Kommentar
Dan More 10 Geschrieben 12. Februar 2010 Autor Melden Teilen Geschrieben 12. Februar 2010 Sind die Drucker im AD veröffentlicht? Ja, sind sie. Der User geht zum Mittagessen und kommt zurück. Danch kann er sích den Drucker nicht mehr installieren. Von fünf Usern die auf denselben Drucker zugreifen, passiert das nur bei einem. Zitieren Link zu diesem Kommentar
Steven2007 10 Geschrieben 14. Februar 2010 Melden Teilen Geschrieben 14. Februar 2010 Hallo Dan, kann es vielleicht sein, dass noch Reste alter Druckertreiber auf den Clients / dem Server rumliegen? Schau mal unter "Drucker und Faxgeräte"-"Datei"-"Servereigenschaften"-"Treiber" nach. Betrachten die Clients die Server als zur Intranetzone oder zur Internetzone zugehörig? Schau mal nach, indem du von Client aus via \\Servername\Freigabe auf den Server gehst und dann in der Statusleiste überprüfst, in welcher Zone der sich befindet. Mit HP Universaltreibern habe ich bisher keine Erfahrungen. Ich empfehle, wenn möglich, den für den Drucker zugehörigen Treiber zu nehmen. Danch kann er sích den Drucker nicht mehr installieren Wieso installieren die sich eigentlich andauernd einen Drucker neu? Machst du das via login Script (prnmgr.vbs ?) Grüßle Zitieren Link zu diesem Kommentar
Dan More 10 Geschrieben 14. Februar 2010 Autor Melden Teilen Geschrieben 14. Februar 2010 Hast da was falsch verstanden. Die User installieren sich nicht die Drucker immer wieder neu. Das Problem liegt darin, dass die User z.B. vom Essen zurückkommen und aus irgendeinem Grund nicht drucken können. Drucker hat z.B. Papierstau, Ein Druckauftrag blockiert den Drucker, etc. Kann die unterschiedlichsten Gründe haben. Also melden sich die User bei der Hotline, die dann Schema "F" runterspult. Dazu gehört halt auch den Drucker beim User zu löschen und neu zu installieren. Bedeutet der Drucker war vorher schon auf dem Client installiert und der User konnte auch drucken. Von jetzt auf gleich geht es auf einmal nicht mehr. Dabei ist es egal ob es einer der HP Drucker oder ein Konica Mopierer ist. Daher glaube ich weniger an ein Treiber oder an ein HW-Problem. Nun gibt es danach unterschiedliche Szenarien. Wenn nun versucht wird, den Drucker über: Start -> Einstellungen -> Drucker und Faxgeräte -> Drucker hinzufügen zu installieren, bekommt der User die Fehlermeldung der fehlenden Rechte. Geht man aber jetzt über: Start -> Ausführen -> \\servername\druckername läst sich der Drucker installieren Oder man meldet sich als Admin am Client an und installiert den Drucker. Danach meldet sich der Admin wieder ab und der User meldet sich an. Dann kann der User sich den Drucker wieder installieren. Das ganze betrifft aber dann immer nur einen einigen User von mehreren die ein und denselben Drucker benutzen. Das ganze tritt auch nur bei einer Handvoll, immer unterschiedlichen, Druckern von den knapp 800 Druckern, die wir im Betrieb haben, auf. Zitieren Link zu diesem Kommentar
Steven2007 10 Geschrieben 14. Februar 2010 Melden Teilen Geschrieben 14. Februar 2010 Hallo, du könntest mal versuchen, via GPO den Benutzern volle Rechte für die Installation von Druckertreibern, die von Servern kommen zu geben.... wobei das glaube ich erst ab Vista/W2K8 von Bedeutung ist.... siehe hier: Steuern der Sicherheit bei der Druckertreiberinstallation Für XP gibts halt die beiden GPOs: lokalen Benutzern das Installieren von Druckerntreibern gestatten und Laden und Entfernen von Geraetetreibern Grüßle Zitieren Link zu diesem Kommentar
NilsK 2.937 Geschrieben 14. Februar 2010 Melden Teilen Geschrieben 14. Februar 2010 Moin, entschuldige, aber der Prozess eures Helpdesk ist unsinnig. Wenn es einen Papierstau gibt, ändert das Remapping daran genau gar nichts. Ein Papierstau führt auch nicht dazu, dass ein Mapping nicht mehr funktioniert. Gruß, Nils Zitieren Link zu diesem Kommentar
Dan More 10 Geschrieben 15. Februar 2010 Autor Melden Teilen Geschrieben 15. Februar 2010 Moin, entschuldige, aber der Prozess eures Helpdesk ist unsinnig. Wenn es einen Papierstau gibt, ändert das Remapping daran genau gar nichts. Ein Papierstau führt auch nicht dazu, dass ein Mapping nicht mehr funktioniert. Gruß, Nils Da stimme ich Dir zu, sollte aber nur als Beispiel, wenn auch un schlechtes, dienen, dass die Gründe unterschiedlich sein können. Hallo, du könntest mal versuchen, via GPO den Benutzern volle Rechte für die Installation von Druckertreibern, die von Servern kommen zu geben.... wobei das glaube ich erst ab Vista/W2K8 von Bedeutung ist.... siehe hier: Steuern der Sicherheit bei der Druckertreiberinstallation Für XP gibts halt die beiden GPOs: lokalen Benutzern das Installieren von Druckerntreibern gestatten und Laden und Entfernen von Geraetetreibern Grüßle Das ist es ja, Die User in unserem Haus haben alle die Berechtigung sich jeden Drucker im Haus zu installieren und daran haben wir nichts verändert. Zitieren Link zu diesem Kommentar
Pennywise888 10 Geschrieben 12. März 2010 Melden Teilen Geschrieben 12. März 2010 Hallo Zusammen, ich schreibe das erste mal hier. Nicht dass hier jemand Angst bekommt :D. Wir haben original das gleiche Problem hier. Ich habe das mit den Adminberechtigungen und Treibern nicht getestet. Ich kann nur sagen, dass wir die Drucker über das Verzeichnis mit dem FQDN nicht verbinden können. Es geht aber über \\Server\Drucker. Auch bei uns ist das nur bei manchen User- und Drucker-Kombinationen. Andere User können den betroffenen Drucker benutzen. Bei den Berechtigungen haben wir ebenso wenig Einschränkungen. Wir haben den Verdacht, dass es an einem Security-Update von MS liegen könnte. Eventuell hat das was mit den Zonen vom IE zu tun. Ich verbinde die Drucker dann immer per kurzem Namen wieder. Das kann aber nicht die Lösung sein. Ich melde mich wieder, wenn ich was rausbekomme. Viele Grüße Jens Zitieren Link zu diesem Kommentar
KPR 10 Geschrieben 27. Mai 2010 Melden Teilen Geschrieben 27. Mai 2010 Gibt es hier zu diesem Thema etwas neues? Zitieren Link zu diesem Kommentar
Pennywise888 10 Geschrieben 27. Mai 2010 Melden Teilen Geschrieben 27. Mai 2010 Hallo, wir haben einen Microsoft-Call zu dem Thema aufgemacht. Ich habe 3 Wochen intensivst mit denen an dem Thema gearbeitet. Die konnten keinen Grund finden, warum sich die Rechner so verhalten. Die Lösung der ganzen Sache ist: Nur am Client: Drucker löschen, die diesen Treiber verwenden. Ggf. den Drucker aus allen bestehenden Profilen am Client löschen, oder nicht genutzte Profile in denen der Drucker verwendet wird löschen. Den Treiber über Systemsteuerung Drucker-> Datei-> Servereigenschaften-> Treiber deinstallieren. Den Drucker neu über das Active Directory Verbinden. Der Fehler kam bei den betroffenen Clients, danach nie wieder. Ich fand das sehr schwach von MS, aber ich wollte nicht noch mehr Zeit in den Sand setzen. Zum Glück hat sich das Problem nicht ausgeweitet. Wir hatten die Vermutung, dass es an einem Windows-Update lag. Das konnte die Microsoft weder bestätigen noch verneinen. Ich weiß noch nicht ob wir das Geld für den Call jetzt bezahlen müssen, oder nicht. Der Case wurde jetzt archiviert, damit wir den wieder aufnehmen können, falls das Problem wieder auftaucht. Viele Grüße Jens 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.