none
Problem beim Verteilen von Druckern über GPO unter Windows 2008 R2 RRS feed

  • Frage

  • Hallo zusammen,

    folgendes Problem tritt bei mir auf einem Terminalserver auf:

    Umgebung:

    Druckserver: Windows 2008 Standard x64 (ohne R2!), dieser ist ausschliesslich für nachfolgenden Terminalserver zuständig. In einer VMWare Umgebung an Standort A

    Terminalserver: Windows 2008 R2 Standard (logischerweise x64) an Standort A

    Domänencontroller: 2x Windows 2003 R2 Standard an Standort A, 1x Windows 2008 R2 Standard an Standort B

    Problembeschreibung:

    Den Benutzern werden über eine Gruppenrichtline Drucker vom Druckserver zugewiesen. Die Gruppenrichtlinie habe ich zu diesem Zweck an dem 2008er Domänencontroller entsprechend geändert, da diese Funktionalität ja unter 2003 noch nicht gegeben war. Die Domänenfunktionsebene ist noch auf Windows 2003, da sich noch 2003er Domänencontroller in der Domäne befinden.

    Auf dem Terminalserver erscheinen nun folgende Warnungen in der Ereignisanzeige, wenn sich ein Benutzer anmeldet:

    Das Benutzer "Druckername"-Einstellungselement im Gruppenrichtlinienobjekt "Name der GPO" wurde nicht übernommen, da ein Fehler mit Fehlercode "0x80070bc4 Es wurden keine Drucker gefunden." Dieser Fehler wurde unterdrückt. aufgetreten ist.

    Diese Meldung erscheint für jeden zu verbindenden Drucker einmal. Die Drucker sind kurz nach der Anmeldung noch nicht unter "Geräte und Drucker" zu sehen, erscheinen dann aber nach ein paar Sekunden, und sind dann funktionsfähig. Wenn man innerhalb dieser Zeit manuell versucht, den Drucker zu verbinden, erscheint die gleiche Meldung. Danach ist verbinden mit den Druckern kein Problem.

    Für mich sieht das Problem aus, als ob der Rechner zu dem ersten Verbindungszeitpunkt seine Dienste noch nicht komplett hochgefahren hat, und sich deswegen noch nicht mit dem Drucker verbinden kann. Ich kann mir aber nicht vorstellen, dass dies normal sein soll.

    Hat jemand hier einen Tipp für mich, wo ich mit dem Suchen nach dem Fehler beginnen könnte?

    Ich habe bereits mehrere Sachen mit den Einstellungen der Drucker in der Richtlinie probiert (Benutzerkontext ein/aus), ausserdem wurde der verwendete Druckertreiber bereits auf den neuesten Stand gebracht, jedoch bleibt dieses Problem bestehen. DNS-Einträge sind soweit ich sehen kann in Ordnung, die Drucker werden inzwischen nicht mehr über den Servernamen, sondern über die IP verbunden, um die Probleme beim DNS komplett auszuschliessen.

    Mit freundlichen Grüßen

    Steffen Timmermann

     

    Mittwoch, 29. September 2010 14:45

Alle Antworten

  • Am 29.09.2010 schrieb STEX20:

    Auf dem Terminalserver erscheinen nun folgende Warnungen in der Ereignisanzeige, wenn sich ein Benutzer anmeldet:

    Das Benutzer "Druckername"-Einstellungselement im Gruppenrichtlinienobjekt "Name der GPO" wurde nicht übernommen, da ein Fehler mit Fehlercode "0x80070bc4 Es wurden keine Drucker gefunden." Dieser Fehler wurde unterdrückt. aufgetreten ist.

    Diese Meldung erscheint für jeden zu verbindenden Drucker einmal. Die Drucker sind kurz nach der Anmeldung noch nicht unter "Geräte und Drucker" zu sehen, erscheinen dann aber nach ein paar Sekunden, und sind dann funktionsfähig. Wenn man innerhalb dieser Zeit manuell versucht, den Drucker zu verbinden, erscheint die gleiche Meldung. Danach ist verbinden mit den Druckern kein Problem.

    Setz doch mal beide Einstellungen aus der GPO-FAQ No. 36 auf den
    Clients: http://www.gruppenrichtlinien.de/Grundlagen/faq.htm

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Mittwoch, 29. September 2010 15:37
  • Danke für die Antwort.

    Leider ist dies nicht das Problem. Ich habe die Einstellung "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" bereits gesetzt gehabt. Die Einstellung "Anmeldeskripts gleichzeitig ausführen" habe ich jetzt mit in die Gruppenrichtlinie für die Terminalserver aufgenommen, auch wenn es leider nicht das gewünschte Ergebnis erzielt hat. Ich werde das heute abend nochmal nach einem Rechnerneustart versuchen, evtl. ist die Gruppenrichtlinie ja nicht komplett ohne Neustart übernommen worden. Ich hatte nur ein gpupdate /force gemacht.

    Für weitere Ideen bin ich immer dankbar.

    Mit freundlichen Grüßen

    Steffen Timmermann

    Donnerstag, 30. September 2010 15:10
  • Am 30.09.2010 schrieb STEX20:

    Leider ist dies nicht das Problem. Ich habe die Einstellung "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" bereits gesetzt gehabt. Die Einstellung "Anmeldeskripts gleichzeitig ausführen" habe ich jetzt mit in die Gruppenrichtlinie für die Terminalserver aufgenommen, auch wenn es leider nicht das gewünschte Ergebnis erzielt hat. Ich werde das heute abend nochmal nach einem Rechnerneustart versuchen, evtl. ist die Gruppenrichtlinie ja nicht komplett ohne Neustart übernommen worden. Ich hatte nur ein gpupdate /force gemacht.

    Die Clients sollen die o.g. Einstellungen bekommen. Und die mußt Du
    neu starten damit sie auch umsetzen was ihnen mitgeteilt wurde.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Donnerstag, 30. September 2010 15:30
  • Hallo,

    ich denke doch das mit "Die Clients" die Druckserver-Clients also die Terminalserver gemeint sind, oder?

    Ich kann mir gerade nicht vorstellen, wie unsere Thin-Clients, welche auf die Terminalserver zugreifen, etwas damit zu tun haben sollen.

    Ich habe den Terminalserver (momentan ists nur einer, da wir noch testen) gerade eben neugestartet, und das Problem bleibt. Im Richtlinienergebnissatz (Protokollierungsmodus) steht auch, dass diese Richtlinien angewendet wurden. Der Anmeldevorgang läuft jetzt gefühlt auch etwas langsamer ab als vorher, was dafür sprechen würde, dass die Richtlinie gezogen hat.

    Mit freundlichen Grüßen

    Steffen Timmermann

    Donnerstag, 30. September 2010 22:12
  • Am 01.10.2010 schrieb STEX20:

    ich denke doch das mit "Die Clients" die Druckserver-Clients also die Terminalserver gemeint sind, oder?

    Ich kann mir gerade nicht vorstellen, wie unsere Thin-Clients, welche auf die Terminalserver zugreifen, etwas damit zu tun haben sollen.

    Die starten zu schnell.

    Ich habe den Terminalserver (momentan ists nur einer, da wir noch testen) gerade eben neugestartet, und das Problem bleibt. Im Richtlinienergebnissatz (Protokollierungsmodus) steht auch, dass diese Richtlinien angewendet wurden. Der Anmeldevorgang läuft jetzt gefühlt auch etwas langsamer ab als vorher, was dafür sprechen würde, dass die Richtlinie gezogen hat.

    Der TS hat damit auch IMHO nichts zu tun. Du könntest evtl.im
    Loginscript für die Benutzer noch eine Abfrage auf den Printserver
    absetzen, ist er erreichbar gehts weiter, ansonsten abbrechen oder
    eine Warteschleife einbauen.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 1. Oktober 2010 09:56
  • Vielleicht reden wir hier gerade aneinander vorbei. Folgendes nochmal zur erklärung unserer Umgebung:

    Wir haben Thin-Clients der Firma "IGEL" im Einsatz (Betriebssystem: Windows Embedded Standard). Wenn diese starten, wird automatisch ein lokaler Benutzer angemeldet. Auf dem Desktop des Thin-Clients befindet sich die rdp-Datei, mit der die Remotedesktopsitzung aufgebaut werden kann. Auf den Thin-Clients sind keine Drucker installiert! Der Benutzer klickt, nachdem der Client vollständig gestartet ist, auf die Verknüpfung.

    Es wird eine Verbindung mit dem Terminalserver über die RDP-Datei aufgebaut. Die Benutzer der verschiedenen Abteilungen befinden sich in verschiedenen OUs, auf die eine Gruppenrichtlinie mit den CSEs für die Drucker wirkt (Pro Abteilung verschiedene Drucker). Die Terminalserver bauen also die Verbindung zu den Druckern über den Druckserver auf. Zu diesem Zeitpunkt läuft der Thin-Client aber ja schon mehrere Minuten.

    Bevor die Clients also nicht komplett gestartet sind, nehmen diese überhaupt keinen Kontakt mit den Druckern oder dem Terminalserver auf. Daher kann ich mir nicht erklären, wie die Startzeit der Thinclients mit dem Druckerproblem auf dem Terminalserver zusammen hängt.

    Die Thin-Clients sind von uns auch nicht mit in die Domäne aufgenommen worden, da dies bisher nicht benötigt wird. Die Clients werden ausschliesslich für die RDP-Verbindung benötigt, und haben ansonsten keinerlei Laufwerke, Drucker oder ähnliche Verbindungen. Ich kann ansonsten gerne einmal eine OU erstellen, in den ich die Thinclients aufnehme, und die entsprechenden, in der GPO-FAQ genannten Richtlinien setze.

    Beim Anmelden an den Terminalserver startet auch die Übername der sogenannten "Group Policy Printers", bei dieser treten dann die genannten Probleme auf. Das Loginscript für die Benutzer läuft aber erst danach los, daher wäre an dieser Stelle eine Warteschleife/Abfrage meiner Meinung nach eher nicht erfolgreich.

    Falls ich irgendwelche Denkfehler hier mache, bitte darauf hinweisen. Evtl stellt sich ja auch gerade heraus, dass unser System für die Drucker gar nicht funktionieren kann, und das wir das komplett umkrempeln müssen?!?

    Mit freundlichen Grüßen

    Steffen Timmermann

    Freitag, 1. Oktober 2010 11:12
  • Am 01.10.2010 schrieb STEX20:

    Vielleicht reden wir hier gerade aneinander vorbei. Folgendes nochmal zur erklärung unserer Umgebung:

    [Erklärung gesnippt...]

    Jetzt ist mir das klarer. ;)

    Beim Anmelden an den Terminalserver startet auch die Übername der sogenannten "Group Policy Printers", bei dieser treten dann die genannten Probleme auf. Das Loginscript für die Benutzer läuft aber erst danach los, daher wäre an dieser Stelle eine Warteschleife/Abfrage meiner Meinung nach eher nicht erfolgreich.

    Benutzt Du die pushrpinterconnections.exe? Oder machst Du die
    Druckerzuweisung über die neuen Group Policy Preferences?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 1. Oktober 2010 11:35
  • Wir benutzen die Group Policy Preferences, da ich gelesen habe, dass die pushprinterconnections.exe nur bei an Computer gebundene Zuweisung funktioniert, sprich, dass nicht verschiedene Benutzer auf dem gleichen Rechner verschiedene Druckerkonfigurationen haben können, was wir aber benötigen.

    Mit freundlichen Grüßen

    Steffen Timmermann

    Freitag, 1. Oktober 2010 11:50
  • Am 01.10.2010 schrieb STEX20:

    Wir benutzen die Group Policy Preferences, da ich gelesen habe, dass die pushprinterconnections.exe nur bei an Computer gebundene Zuweisung funktioniert, sprich, dass nicht verschiedene Benutzer auf dem gleichen Rechner verschiedene Druckerkonfigurationen haben können, was wir aber benötigen.

    OK, kannst Du exakten Einstellungen posten? Wenn möglich als
    Screenshots irgendow uploaden und den Link hier posten. So ähnlich wie
    hier: http://www.gruppenrichtlinien.de/Bilder/gpp_12.png

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 1. Oktober 2010 12:06
  • Die Einstellungen sind für alle Drucker wie auf dem Screenshot zu erkennen. (Es gibt natürlich nur 1 Standarddrucker)

    Screenshot

    Falls noch weitere Screenshots benötigt werden, ist dies kein Problem, bitte fragen.

    Mit freundlichen Grüßen

    Steffen Timmermann

    Freitag, 1. Oktober 2010 12:27
  • Am 01.10.2010 schrieb STEX20:

    Die Einstellungen sind für alle Drucker wie auf dem Screenshot zu erkennen. (Es gibt natürlich nur 1 Standarddrucker)

    Screenshot <http://nn-ftp.de/druckergpo.png>

    Hast Du es schon ohne den Haken beim Benutzerkontext probiert?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 1. Oktober 2010 13:45
  • Ja, hatte ich bereits, und habe ich soeben nochmal probiert, leider keine Veränderung in der Ereignisanzeige. Gleiche Fehlermeldung.

    Mit freundlichen Grüßen

    Steffen Timmermann

    Freitag, 1. Oktober 2010 15:02
  • Hi,

    Am 01.10.2010 13:12, schrieb STEX20:

    Beim Anmelden an den Terminalserver startet auch die Übername der
    sogenannten "Group Policy Printers", bei dieser treten dann die
    genannten Probleme auf.

    Point und Print Restrictions konfigurieren, in euren Fall am TS, da
    dieser ja der ausführende Computer ist.

    Point-and-Print-Einschränkungen
    Computerkonfiguration/Administrative Vorlagen/Drucker
    -> Point-and-Print nur mit folgenden Servern: FQDN Printserver
    -> Sicherheitshinweise:Warnung oder Anhebungsaufforderung nicht anzeigen

    ... und immer wieder Druckertreiber als Fehlerquelle gerne genommen.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Montag, 4. Oktober 2010 08:53
  • Hallo,

    ich habe gerade die entsprechenden Gruppenrichtlinien gesetzt, und werde heute abend den Server noch einmal neustarten. Danach probiere ich es noch einmal. Melde mich dann wieder.

    Mit freundlichen Grüßen

    Steffen Timmermann

    Montag, 4. Oktober 2010 11:55
  • Hallo,

    ich habe die empfohlenen Einstellungen gesetzt, und habe den Terminalserver nocheinmal neugestartet. Das Problem besteht weiterhin. Der verwendete Treiber ist der HP Universal Printing PCL 6 in der Version vom 31. August 2010. (Der neueste den es zur Zeit gibt). Mit den Original-Druckertreibern für die diversen Modelle hatten wir noch mehr Probleme, so dass wir auf die Universal Variante gewechselt sind. Ich habe auch versucht, die Drucker einmal über die IP des Druckservers und einmal über den FQDN des Druckservers zu mappen, es gibt jedoch keinen Unterschied. Fehler bleibt bestehen.

    Ist dies vielleicht ein Problem des Druckservers?

    Mit freundlichen Grüßen

    Steffen Timmermann

    Dienstag, 5. Oktober 2010 08:33
  • Hi Steffen,

    hab exakt genau die gleiche Problematik wie du! Fast genau die selbe Umgebung, nur dass es bei mir keine Thinclients sondern Laptop´s sind die RDP auf den TE gehen!

    Hast du schon eine Lösung?

    Schöne Grüße
    Michael

    Freitag, 8. Oktober 2010 09:30
  • Naja, erstmal noch nicht, das Problem besteht weiterhin, allerdings sind mir so langsam die Ideen ausgegangen. Anscheinend auch den Kollegen hier im Forum.

    Aber gut zu wissen, dass man nicht alleine mit so einem Problem dasteht.,

    Hast du auch den Druckserver auf 2008 x64 und den Terminalserver auf 2008 R2 Basis? Ist da das Problem begraben?

    Mit freundlichen Grüßen

    Steffen Timmermann

    Freitag, 8. Oktober 2010 15:14
  • Hallo,

    ich hänge genau an dem gleichen Problem. Wir haben auch zeitverzögerte Verbindungen mit Druckern.

    es fällt besonders bei Benzutzern auf, die viele Drucker verbinden.
    In den engl. Forum suche ich auch schon eine Lösung.
    Können wir uns vielleicht per Mail/Telefon kontaktieren?
    Vielleicht sehen wir gleiche Umgebungen und irgendow muss es doch ne Lösung geben...

    Grüße

    Dienstag, 12. Oktober 2010 11:04
  • Hallo,

     

    ich versuche gerade das Szenario in VMWare abzubilden, um mit einer "frischen" und noch nicht so "verspielten" Installation zu beginnen. Ich muss noch ein bisschen Probieren. Bisher ist das Problem dort aber noch nicht aufgetreten. Ich versuche den Fehler jetzt nachzustellen, um das Problem einzukreisen.

    Ich hoffe, dass ich bald eine Antwort auf das Problem habe.

    Mit freundlichen Grüßen

    Steffen Timmermann

    Dienstag, 12. Oktober 2010 12:56
  • Hallo,

    es scheint so, das auf windows 7 64bit Clients das Problem nicht auftritt.

    Ich habe dies mit einem Client getestet, der "holt sich seine Drucker" eigentlich fix.
    Nur bei einem Profil ohne Drucker dauert es einen Augenblick länger, aber keine Ewigkeit wie auf einem Win2008R2-Terminalserver.

    Es gibt im aktuellen HP UPD einen Registry Eintrag, der bei der Verbindung helfen soll, NoPointnPrintInstallHPOperation, der scheint aber auch nicht wirklich zu helfen.

    Klappt der bei ihnen? Haben sie den genutzt?

    Grüße

    Mittwoch, 13. Oktober 2010 08:51
  • Hallo,

    Sorry, dass ich mich erst so spät melde, aber ich hatte die letzten Tage eindeutig zu viele Sachen gleichzeitig zu erledigen.

    Den Registry-Key habe ich noch nicht Probiert, da ich dies noch nicht wusste. Unter welchem Key ist der denn zu finden? Den muss ich dann ja wahrscheinlich auf den Terminalservern setzen, oder?

    Mit freundlichen Grüßen

    Steffen Timmermann

    Samstag, 16. Oktober 2010 14:06
  • Hallo,

    der Key soll an dem Printserver zu setzen sein. Es gibt in der Registry einen Eintrag pro Print queue der dann auf 1 gesetzt wird.
    Geh mal auf http://www.hp.com/go/upd, dort dann auf Documentation, dort das HP Printer Administrator´s Resource Kit (PARK)(.zip, 15MB)
     downloaden. In dem ZIP ist ein Ordner mit einem VBS und einem Word Dokument.

    In den Release Notes steht:

    CR#5094/5782: Slow Install of UPD on WS2K8 x64 TS to Client: new registry flag setting made on the print server for each print queue forces clients to bypass installation operations normally associated with establishing a print queue. Modifying the key value on print servers should be considered for situations where new print connections are established at each login (i.e. Citrix, Windows Terminal Services).
    Reference the "Print Administrators Resource Kit, tool NoPointnPrintInstallHPOPeration" for details

    Der Effekt war bei uns aber eher schlecht. Das Verbinden dauert noch ne Ewigkeit, wenn mehr als 2-3 Drucker...

    Montag, 18. Oktober 2010 13:06
  • Hallo zusammen,

    Hat euch nun diese Key geholfen?

    Ich hab fast das gleiche Problem, in einer ähnlichen Umgebung:

    Wir haben eine Windows 2008 R2 TerminalServer Umgebung, die User arbeiten alle mit ThinClients (Igel). Über den ThinkClient öffnen sie eine RemoteDesktop Verbingung zum Server, bei der Anmeldung an den Server wird ein Login Skript ausgeführt, das Printer und Netzlaufwerke mappt.
    Das mappen der Printer funktioniert mal und mal nicht, wenn es nicht funktioniert ist es anschliessend auch nicht möglich die Drucker manuell zu mappen (über IP oder FQDN) jedoch nur für ein paar Minuten und anschliessend funktioniert es manuel (oder auch per Skript).

    Wie STEX20 hab ich auch das Gefühl das irgendwas noch nicht ganz gestartet ist, aber was.. Vorallem kann es sein das es nur für ein Drucker nicht funktioniert. Auch ich benutze den  HP Universal Printing PCL 6.

    Im EventLog habe ich den Fehler DCOM was unable to communicate with the computer "Printservername" using any of the configured protocols. ID 10009
    Ich habe aber soweit alle DCOM Einstellungen überprüft und keinen Fehler gefunden (wie z.b. der Key in der Registry für das DCOM Protocol).

    Hat jemand noch eine Idee?

    Grüsse

    Montag, 1. November 2010 14:38
  • Hallo,

    das Mappen der Drucker mit HP Treiber ist immer noch nicht sehr schnell, aber "erträglich".Hoffe auf neue Version des HP UPD.

    Denke, die 5.1.1 die momentan verfügbar ist, ist nur ein Zwischenrelease. Warten wir mal ab.
    Wenn das Druckermapping nicht geht, läuft dann trotzdem das Laufwerksmapping?

    Mapping der Laufwerke und Drucker auf verschiedene Server?

    Grüße

    Montag, 1. November 2010 18:25
  • Guten Morgen,

    Ja die Netzlaufwerke werden alle richtig gemappt. Jedoch sind die auch auf einem seperaten File Server.

    Beim Drucker mappen funktionieren einzelne Drucker nicht (aber nicht immer die selben...). Also das mappen im grossen und ganzen funktioniert eigendlich..

    Grüsse

     

    Dienstag, 2. November 2010 06:35
  • Hallo,

    wir hatten mal den Effekt, das bestimmtes Mapping zu Laufwerken nicht immer ging. Windows 2008R2 Hotfix hat dort geholfen (auf den Terminalservern).
    Da gibt es ein SMB Problem. Ich kann den Hotfix mal suchen.

    Grüße

    Dienstag, 2. November 2010 20:25
  • Hi

    Am 02.11.2010 21:25, schrieb Marc Moennikes:

    Da gibt es ein SMB Problem. Ich kann den Hotfix mal suchen.

    ... wenn es ein SMB Problem ist, dann ist es manuell falsch
    konfiguriert.
    Das ist das Armutszeugnis von MS, weil sie keine Lust mehr hatten
    das zu supporten. Der Patch sorgt für eine Kommunikation obwohl
    alle per Hand verbastelt ist und noch schlimmer, er "korrigiert"
    u.U. vom Admin gewollte einstellungen, da er die Situation ein
    wenig anders sieht.

    Ich deaktiviere SMB Signing, weil mir das zuviel Traffic verursacht
    und der Patch schaltet es ein (siehe Tabelle), das darf nicht sein.
    http://support.microsoft.com/kb/916846/en-us

    Konfiguriere SMB Signing auf Domänen-Ebene für alle Clients/Server
    und zusätzlich für die DCs in der DefDomConPol.
    Den Patch brauchst du nicht.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Dienstag, 2. November 2010 21:07
  • Hi

    Am 03.11.2010 22:46, schrieb Marc Moennikes:

    ich meinte eigentlich dies:

    oh, ok. Ich hatte nur SMB gelesen und den "Default" Fehler angenommen.

    Anstelle des Patches von:
    http://support.microsoft.com/kb/2194664/en-us
    hast du mal probiert ein "net use * /delete" anzugeben?

    Denn eigentlich ist der dergleiche Fehler, bzw. gleiches Verhalten,
    warum man sich zu ein und derselben Ressource nicht mir einer
    alternativen NUtzerkennung verbinden kann.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Mittwoch, 3. November 2010 23:42
  • Hallo,

    Danke für eure Antworten..
    Wollte eben den geposteten Patches installieren, jedoch gibt es ihn nur für x86 Systeme, somit funktioniert das leider nicht.

    wie meinst du das mit net use */delete? Einfach alle Ressourcen zuerst löschen bevor ich sie wieder anbinde? Das mache ich bereits einfach mit dem Befehl %Logonserver%\netlogon\CON2PRT.EXE /f
    Das das Problem am Befehl liegt kann ich aber ausschliessen, denn wenn ich nach dem Login einen Drucker manuell mappen will der nicht funktioniert hat, braucht es dazu meist zwei Anläufe, beim ersten mal erhalte ich die Meldung: Druckerverbindung kann nicht hergestellt werden. Es wurde kein Drucker gefunden. Im Hintergrund läuft noch das Fenster mit Verbindung wird hergestellt mir "Drucker", Treiber wird heruntergeladen. Wenn ich bei der Fehlermeldung ok drücke wird auch der andere Dialog abgebrochen. Versuche ich es dann gerade nochmal zu mappen funktioniert es (meistens, manchmal funktioniert es auch erst beim fünften mal..)

    grüsse

    Donnerstag, 4. November 2010 08:18
  • Hallo,

    wenn es dann auf einmal klappt, scheint es nicht an dem Fix zu liegen. Das ist ein anderes Problem.
    Welchen HP UPD nutzt du denn?
    Sind andere Treiber auf dem System, bzw. betrifft es nur HP Drucker?
    Ist der Printserver win2008r2? 64 oder 32bit? Cluster?

    Geht es als Admin schnell?
    Vielleicht hilft das ändern des "Printprocessors" beim HP auf "winprint".

    Grüße

    Donnerstag, 4. November 2010 16:04
  • Hi,

    Am 04.11.2010 09:18, schrieb Els:

    wie meinst du das mit net use */delete? Einfach alle Ressourcen
    zuerst löschen bevor ich sie wieder anbinde? Das mache ich bereits
    einfach mit dem Befehl %Logonserver%\netlogon\CON2PRT.EXE /f

    Nein. net use * /delete trennt nicht nur die Verbindung, sondern
    löscht auch die Anmelde Inforamtionen der Ressource.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Donnerstag, 4. November 2010 20:54
  • Hallo,

    Ich habe es mit dem UPD PCL 6 und PCL 5 verucht, immer das gleiche Probelem. Wir haben nur zwei ander Drucker wie HP, bei denen ist mir das Problem bis jetzt noch nicht aufgefallen. Printserver ist auch win2008 r2 64bit (genau wie die TS).

    Ich werde das mit dem Printprocessors probieren, danke.

     

    Grüsse

    Freitag, 5. November 2010 10:15
  • Hallo,

    das ist das vom Szenario her, genauso wie bei uns.
    Kommen auf den Terminalserver Installer-Fehlermeldungen im Log? Ist bei der Anmeldung ein MSIEXEC Prozess am rennen?
    Da gab es mal ein Prolem bei den HP UPD wo eine MSI installiert wurde, dies schlug dann fehl.

    Geholfen hatte eine Zero-Byte-MSI auf dem Printserver im Driver-Verzeichnis. Das sollte eigentlich bei den aktuellen Treiber (ab HP UPD 5.X weg sein).

    Aber vielleicht gibt es noch Altlasten durch upgedatete Treiber?

    Grüße

    Samstag, 6. November 2010 13:27
  • Hallo,

    Also es ist kein MSIEXEC Prozess am laufen und auch hab ich keine Fehler im EventLog. Das System wurde erst neu aufgebaut, somit sind noch keine Altlasten vorhanden.. Wir haben nur die HP Universal Treiber installiert.

    Kann es sein das es Timing Probleme beim Login mit dem NTUSER.DAT gibt. Meines Wissen speichert Windows die letzten Druckeinstellungen ins NTUSER.DAT (Registry) die werden dann beim Login dort geladen. Im Skript lösche ich zuerst die Drucker und stelle dann die Verbindung wieder her. Ist das möglich das sich die irgendwie in die quere kommen?

    Grüsse

    Montag, 8. November 2010 15:42
  • Hallo,

    ist es notwendig die Drucker neu zu verbinden, also trennen und wiederverbinden?

    Wir nutzen Group Policy Preferences, um die Drucker zu verbinden.
    Vielleicht eine Alternative, mglw. geht es damit besser.

    Wenn es Loginscript sein soll, Kixtart hat bei uns immer einen guten Eindruck gemacht.

    Grüße

    Montag, 8. November 2010 19:29
  • Hallo STEX20,

     

    leider hab ich aktuell immer noch die selben Probleme wie wir hier alle!


    Folgendes Konstrukt habe ich:

    3x Terminal Server 2008 X64 R2 --> auf diesen werden die Drucker verbunden, sprich die User gehen von ihren Thinclients (laptops) per RDP auf die Terminal server und auf den Terminalservern werden per GPP die Drucker zugewiesen!

    8x Lokale DC´s auf welchen die Lokalen Drucker des jeweiligen Standortes gemapped sind, sprich lokal eingerichtet Drucker auf den DC´s der DC ist hier der Druckerserver. (Server 2008 x64 R2)

    Ich habe das Problem auf allen Terminal Servern, mit allen Standortdruckern. (hauptsächlich canon und HP)

    Die Drucker werden Gruppenbezogen mit Zielgruppenadressierung verbunden (Aktion wurde auf "Ersetzten" gesetzt). (Im Sicherheitskontext des angemeldeten Benutzers, Element entfernen, wenn es nicht mehr angewendet wird.)

    Gibt es jetzt ansätze was man noch machen kann?

    Schöne Grüße
    Michael

    Freitag, 12. November 2010 10:39
  • Hallo MPinker,

    Hab leider noch keine Lösung gefunden. Wir haben unsere TS alle provisioniert, sind nun dort mal auf Problemsuche...

     

    Grüsse

    Montag, 15. November 2010 12:21
  • Hallo,

    vielleicht hat es was mit dem Loopbackverarbeitungsmodus für Benutzerrichtlinie zu tun ?
    Ich weiß das dieses per GPO bei uns geschaltet ist und wir haben eine ähnliche TS Konfiguration mit Win 2008 als Printserver und R2 als TS und diesen Fehler habe ich noch nie gesehen.

    Vielleicht hilft es euch weiter?

    Grüße

    Montag, 15. November 2010 16:04
  • Das wäre ne option, jedoch kann ich den LoopBack auf dem TS nicht ausschalten.
    Dienstag, 16. November 2010 09:17
  • Hallo zusammen,

    hier melde ich mich also nochmal zu Wort. Meine Tests haben leider keinerlei eindeutige Ergebnisse gezeigt, womit ich auf dem gleichen Stand wie wohl fast alle hier bin.

    Ich werde am Samstag mal den neuesten HP UPD-Treiber installieren, welcher ein Problem mit der PrintIsolationHost.exe beheben soll. Evtl. liegt hier auch schon ein grossteil meiner Probleme begraben.

    Ich melde mich nach Samstag nochmal, ob es jetzt mit der aktuellen Version (22.11.2010) besser funktioniert.

    Schöne Grüße

    Steffen Timmermann

    Freitag, 3. Dezember 2010 08:56
  • Hallo,

    für eine Rückmeldung wäre ich sehr dankbar. Momentan haben wir noch nicht upgedatet, die Version 5.1.1 war aber schon sehr hilfreich, viele Fehler sind da im Bereich Printisolationhost.exe verschwunden. Vielleicht hat HP aber nachgelegt und der UPD wird langsam mit Win2008r2 "rund" und stressfrei.

    Danke

    Grüße

    Marc

    Sonntag, 5. Dezember 2010 20:43
  • Was man allerdings nicht vergessen sollte, ich hab genau das selbe Problem mit Canon Druckern. Arbeite hier mit den neuesten nativen Treibern von Canon!

    Montag, 6. Dezember 2010 08:52
  • Hallo zusammen,

    also der neue Treiber hat bzgl. des Problems keinerlei Auswirkungen.

    Allerdings muss ich sagen, dass die Druckertreiber nun wesentlich stabiler laufen (Word und co.). Vorher war da immer die Printisolationhost.exe abgestürzt, das macht er jetzt nicht mehr.

    Das Problem mit der Fehlermeldung besteht aber weiterhin, wenn man nicht die Drucker komplett neu verbindet, was dann aber lange dauert.

    Mal sehen, ob es bald noch neuere Versionen der Treiber gibt.

    Schöne Grüße

    Steffen Timmermann

    Montag, 13. Dezember 2010 10:54
  • Hallo,

    gibt's denn zufällig schon was neues zu diesem Thema (sprich: eine Lösung)? Bei mir tritt dieses Problem nur sporadisch bei einzelnen Druckern auf und würfelt daher jedes Defaultprinter-Setting durcheinandern.

    LG

    Clemens

    Dienstag, 28. Dezember 2010 13:22
  • Salü,

    Wir umgehen das Problem wie folgt: Native Treiber der Drucker verwenden. Druckermapping und setzten das Standarddrucker über Citrix Richtlinien. Da wir je nach dem ob der User zuhause arbietet oder im Büro andere Drucker mappen wollen, bin ich nun noch an einem Logout Skript dran, das die Einstellungen nicht ins NTUSER.DAT gespeichert werden und somit noch Drucker von dort "geholt" werden.

     

    Grüsse

    Donnerstag, 6. Januar 2011 12:48
  • Moin,

     

    wir haben exkt dasselbe Problem und suchen auch immer noch verzwiefelt nach einer Lösung, da uns die Druckersteuerung permanent den Standarddrucker durcheinander bringt und auch keine HP Drucker mehr mappen will.

     

    VG

    Dienstag, 15. Februar 2011 15:24
  • Am 15.02.2011 schrieb Karsten Boldt:

    wir haben exkt dasselbe Problem und suchen auch immer noch verzwiefelt nach einer Lösung, da uns die Druckersteuerung permanent den Standarddrucker durcheinander bringt und auch keine HP Drucker mehr mappen will.

    Evtl. hilft ja dieser KB-Artikel:
    http://support.microsoft.com/kb/2492632
    http://support.microsoft.com/kb/2003646

    Spätestens nächste Woche ist das SP1 für 2008R2 und W7 für die
    Öffentlichkeit zu haben, möglicherweise löst es ja das Problem.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Dienstag, 15. Februar 2011 16:14
  • Hallo Karsten,

    kannst du deine Umgebung genauer beschreiben? Nur Drucker von einem Printserver verbunden? Auch lokale Printer redirected?
    Easy Print ja/nein? Welche Druckerhersteller?
    Wir haben hier mit den HPs gewaltig gekämpft, es aber jetzt ziemlich gut im Griff.

    Grüße

    Dienstag, 15. Februar 2011 19:24
  • Die Umgebung sieht folgendermaßen aus:

    Alle Server Windows2008R2; 3x WTS, Printserver; Fileserverver; Exchange

    Druckerverteilung via GPP, Zielgruppenadressierung über Benutzer

    jeder Benutzer hat mindestens 2 Sicherheitsgruppen: je Drucker eine Gruppe, und eine Gruppe für den Standarddrucker

    Es gibt 2 GPOs: eine für die Druckerzuweisung. In dieser GPO sind alle Drucker vorhanden

                           eine für den Standarddrucker. In dieser Gruppe sind auch alle Drucker vorhanden

                           zuerst werden alle Drucker zugewiesen und danach der Standarddrucker gesetzt.

    Die Druckertreiber sind zentral auf dem Printserver installiert und alle Drucker wurden initial einmal vom Admistrator auf den WTSen verbunden, damit sichergestellt ist, dass alle Treiber und Einstellungen identisch sind.

    Folgende Drucker sind im Einsatz: Brotzer, Toshiba, Ricoh, HP

    Bei HP ist aktuell folgender Treiber im Einsatz:HP Universal Printing PS v5.2

    Beispielhafte Fehlermeldung im Eventlog: Das Benutzer "PR71"-Einstellungselement im Gruppenrichtlinienobjekt "TS-Drucker-neu {59D9CF76-7C5A-4402-A38E-FCA79726ED79}" wurde nicht übernommen, da ein Fehler mit Fehlercode "0x80070bc4 Es wurden keine Drucker gefunden." Dieser Fehler wurde unterdrückt. aufgetreten ist.

    EasyPrint ist deaktiviert. Das war  eine Vorgabe von der DATEV

     

    VG

    Karsten

     

     

    Mittwoch, 16. Februar 2011 10:43
  • Evtl. hilft ja dieser KB-Artikel:

    http://support.microsoft.com/kb/2492632
    http://support.microsoft.com/kb/2003646

    Wenn ich das richtig verstehe, geht es hierbei nur um Clientdrucker. Diese nutzen wir gar nicht.

    VG Karsten

    Mittwoch, 16. Februar 2011 11:11
  • Hallo,

     

    das ist quasi unsere Umgebung, nur, wir machen das Targeting bzgl. der Printer auf den Clientname des Rechners. also ordnen dem Rechner immer die Drucker zu, die ihm am "nächsten" sind.

    Der 602 Error im Eventlog, wenn du ihn hast, ist momentan nicht "behebbar". Da soll es demnächst einen Hotfix geben.

    Ich schicke dir mal die Hotfixe, welche wir auf unseren WTS 2008R2 installiert haben. Schau mal, ob du die auch alle hast:

    KB2028965  , KB2194664   ,KB2383928   ,KB2384602   ,KB958488   , KB974431   ,KB975467   ,KB976398   ,KB976662   ,KB976759   ,KB977074   ,KB979306   ,KB979425   ,KB979530   ,KB979681 ,KB980182   ,  KB980408   ,KB981054   ,KB981070   ,KB981152   ,KB981156  ,KB982303   , KB982728   ,KB983224   ,KB983533  

    Das dürften sie sein. Sind nicht alle für Drucker interessant, aber die haben wir alle auf den WTS auch für die Policy und Laufwerksmappings.

    Dazu haben wir momentan den HP UPD 5.2.5 (der müsste ganz frisch sein).

    Dazu alle Treiber überall "isoliert". Das ClientSideRenedering ausgeschaltet.

    Bei den Druckern "Im Benutzerkontext ausführen" in den GPP aktiviert.

    Momentan ist bei uns Ruhe. Was die WTS nicht abkönnen, hohe Speicherauslastung (90 Prozent). Dann machen die GPP Stress.

    Grüße

    Mittwoch, 16. Februar 2011 11:47
  • ich schau mir mal den Patchstatus der Server an. Außerdem kommt ja das SP1 für den 2008R2 jetzt raus.

    Vielleicht wird es dann ja endlich besser!

     

    Viele Grüße

    Montag, 21. Februar 2011 13:08
  • Hallo,

     

    mglw. sind einige der Patche im SP1 enthalten. Es sind da auch Patche bei, die nicht fürs Drucken wichtig sind. Ist unser "Sammelsurium" mit Patchen für die Terminalserver, damit haben wir auch andere Probleme in den Griff bekommen:
    - Laufwerksmapping
    - Targeting "Terminalserversitzung" in GPP
    und Drucken

    Grüße

    Dienstag, 22. Februar 2011 12:05
  • Hallo,

    ich denke, alle Patche haben es nicht in SP 1 geschafft.

    Siehe: http://support.microsoft.com/kb/976932/de ; http://www.microsoft.com/downloads/en/details.aspx?FamilyID=61924cea-83fe-46e9-96d8-027ae59ddc11&displaylang=en

    Sehr interessant könnte noch folgender Patch sein (NICHT in SP1 enthalten, muss zusätzlich installiert werden):
    http://support.microsoft.com/kb/2457866/en-us

    Consider the following scenario in a domain environment:

    • You deploy a network printer by using a printer server.
    • You install the network printer on a computer that is running Windows 7 or Windows Server 2008 R2.
    • You log on to the computer.

    In this scenario, an event that resembles the following is logged in the Application and Services log:

    Event ID: 602
    Source: Microsoft-Windows-Printservice
    Level: Error
    Message: The print spooler failed to reopen an existing printer connection because it could not read the configuration information from the registry key %1\%2. This can occur if the key name or values are malformed or missing.

    Additionally, you experience a delay in seeing the network printer in the Devices and Printers item in Control Panel after you log on to the computer.

    Die Errors haben wir auf unseren Servern, die Zeitverzögerung bei der Druckerliste in der Systemsteuerung können wir auch beobachten...
    Wenn das mit dem Patch klappt, sind einige der Problme gelöst.

    Grüße

    Donnerstag, 24. Februar 2011 20:06
  • Moin,

    erst mal vielen Dank für die Hilfe. Ich habe mich durch den Jungle der ganzen KB Artikel gekämpft und (zumindest in meinem Testsystem) ein paar Erfolge erzielen können.
    Was nicht geholfen hat, war das aktuelle SP1 für Windows2008R2.

    Einen Fehler konnte ich erfolgreich mit dem o.a. Artikel zu KB2457866 beheben (EventID:602) http://support.microsoft.com/kb/2457866/en-us

    Den anderen Fehler (EventID 4098) bekomme ich anscheinend jetzt auch in den Griff:

    • Es scheint ein DNS Problem zu sein --> http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/4ca6e02b-0b07-49d5-9e7d-9238aa9099dc
      Ich hatte die Druckerfreigabe zu schlicht eingerichtet. Richtig ist: \\server.contoso.com\PR1 und natürlich auch im Verzeichnis freigeben
    • Einen weiteren Hinweis fand ich hier: http://www.eversity.nl/blog/?p=252
      Bei der Druckerauswahl im GPP die komplette Freigabe manuell eintragen hilft.
      Nutzt man auch die Zielgruppenadressierung, so sollte man aber die Gruppen über das AD suchen und nicht manuell eintragen.

    Was leider immer noch nicht sauber funktioniert, ist der HP Treiber. Hin und wieder spinnt dieser rum und es werden einzelne Dokumente verkleinert oder verzerrt dargestellt. Aktuell habe ich den UPD 5.2.6.9321 PCL6 im Einsatz

    Ich werde jetzt mal die gewonnenen Erkenntnisse im Produktivsystem abbilden. Vielleicht klappt es ja :-)

    Viel Gruß

    Freitag, 4. März 2011 14:53
  • Hi,

    Am 04.03.2011 15:53, schrieb Karsten Boldt:

    Richtig ist: \\server.contoso.com\PR1

    Nein, es geht auch mit NetBIOS Namen und/oder IP.
    Das ist nur ein simpler UNC, der vom System aufgelöst werden muss,
    danach triggert die gpprefcl.dll die die "rundll32" und verbindet den
    Drucker wie es auch "per Doppelklick" passieren würde.

    Ehrlich Preferences sind keine Zauberei, sonder nur eine GUI Umsetzung
    der im System vorhandenen Techniken. Die (DesktopStandard) haben das
    Rad nicht neu erfunden, als sie es entwickelt haben.

    Nutzt man auch die Zielgruppenadressierung, so sollte man aber die Gruppen über das AD suchen und nicht manuell eintragen

    Das ist an jeder Stelle der ILTs notwendig, da es nur mit der SID der
    Gruppe funktionert. Der Name ist nur für dein Reporting, die GPP
    arbeitet aber nur mit der SID. Der Name kann sich ändern, die SID nicht.
    Deswegen ignoriert ILT den reinen Namen.

    Ich persönlich bin sehr irritiert, daß Drucken und Druckerverteilung so
    ein Problem darstellt. Ich habe schon wirklich schäbige Drucker stehen
    gesehen und verteilt.

    Nur um es zum x-ten Male nachzufragen:
    - Ihr habt die Point and Print Restriction richtig konfiguriert?

    http://technet.microsoft.com/en-us/library/cc753269.aspx#BKMK_GPLimitServers
      Wichtig!
      Ab Win7 eine Computer Einstellung, war bei Vista eine Userkonfig.
    - Ihr verteilt die Drucker an USER?

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Freitag, 4. März 2011 15:35
  • Ja Point and Print ist konfiguriert.

    Ja die Drucker sollten an die User verzeilt werden.

    Dienstag, 8. März 2011 14:07
  • Hi,

    Am 08.03.2011 15:07, schrieb Els:

    Ja Point and Print ist konfiguriert.
    Ja die Drucker sollten an die User verzeilt werden.

    Sind es reine "Shared Printer"?
    kannst du den Drucker Fehlerfrei per "rundll32" übergeben?
    -> rundll32 printui.dll,PrintUIEntry /in /n /y \\SERVER1\PRITNER

    ... oder werden sie mit IP Anschluss, bzw. lokal installiert?

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Sonntag, 13. März 2011 11:47
  • Je es sind Shared Printer, welche ich unteranderem über rundll32 mappen kann.

    Nein Sie werden nur gemappt, nicht lokal installieret.

    Mittwoch, 16. März 2011 14:43
  • Hi,
    Fehlercode "0x80070bc4 Es wurden keine Drucker gefunden."

    Das ist kein Treiber Problem ... Du verwendest den in AD veröffentlichten Namen des Printer und der hat wahrscheinlich auch noch Leerzeichen.

    a) KEINE !!! Leerzeichen
    b) Immer den UNC Pfad hernehmen, per Hand eintippen, nicht den "Public im AD"

    Tschö
    Mark

    Donnerstag, 17. März 2011 15:52
  • Wir haben keine Leerzeichen im Druckername und auch nich im Servername.

    Auch benutzen wir den UNC Pfad.

    Freitag, 18. März 2011 10:30

  • - du hast alle anderen Vorschläge dieses Thread befolgt
    - du hast es mit einem anderen Drucker versucht
    - HP LJ5 nativ von MS ist ein prima Test Drucker, egal ob angeschlossen oder nicht, es geht ja nur um die Verteilung.

    Wenn der Drucker geht, dann ist die Fehlerquelle leicht identifiziert und sie ist weder bei MS noch in der GPO Struktur.

    Wenn man den LJ5 nict verteilen kann macht man grundsätzlich etwas falsch.

    Tschö
    Mark

    Freitag, 18. März 2011 10:48
  • Ich muss mich an dieser Stelle auch noch mal einschalten, da ich die Problematik aktuell noch immer habe.

    Ich verwende zum Verbinden der Drucker die FQDN namen, z.B. "\\test-server.dom-aene.dom\printername".
    Die Drucker sind bei mir im AD nicht Publiziert, d.h. ich lasse sie nicht im Verzeichniss anzeigen.

    Was sehr auffällig ist, dass ich ebenso manchmal eine Fehlermeldung bekommen, wenn ich Laufwerke über die GPP´s mappe?

    Evntlog Beispiele:

    "Das Benutzer "TEST-DR002"-Einstellungselement im Gruppenrichtlinienobjekt "TESTGPO{******************}" wurde nicht übernommen, da ein Fehler mit Fehlercode "0x80070bc4 Es wurden keine Drucker gefunden." Dieser Fehler wurde unterdrückt. aufgetreten ist."

    sowie,

    "Das Benutzer "TEST_Laufwerk (H:)"-Einstellungselement im Gruppenrichtlinienobjekt "TESTGPO{******************}" wurde nicht übernommen, da ein Fehler mit Fehlercode "0x80070035 Der Netzwerkpfad wurde nicht gefunden." Dieser Fehler wurde unterdrückt. aufgetreten ist.

    Laufwerke u. Printer sind aber nach einer gewissen seit dann ohne Probleme erreichbar?
    Weis aktuell nicht wo das Problem liegen könnte?

    Schonmal viele Dank für eure Hilfe!

    Donnerstag, 16. Juni 2011 15:24
  • Hallo zusammen,

    ich habe / hatte das gleiche Problem wie hier bereits beschrieben wurde. Mittlerweile konnte ich mein Problem lösen. Nach diversem Stöbern im Internet sowie im Eventlogs etc. kam ich irgendwann auf die richtige Spur.

    Ursache bei mir war eine Fehlkonfiguration des Printservers (auch W2k8R2-Server). Wir setzen neben 90% HP-Druckern in einer unserer Außenstellen auch 2 Xerox-System sowie 2 Kyocera-Drucker ein. Bei zwei HP-Druckern war im Druckserver warum auch immer als Anschlussart ein WSD-Anschluss mit krypsicher Nummer zugeordnet. Das Konfigurieren sowie Löschen des Anschlusses wurde vom Druckserver mit einer Fehlermeldung quittiert. Plötzlich ging mir ein Licht auf !!!!

    Bei uns traten die GPO-Fehler in unserer Citrix-Xenapp-Farm (4 Server) auf. Manche User bekamen Drucker über die GPO verbunden, andere nicht. Ein manuelles Verbinden über die Systemsteuerung war bei den Usern, bei denen die Drucker nicht verbunden wurde, nicht möglich. -> erzeugte die gleichen Fehler im Eventlog wie bei der Anmeldung.

    So ... was war passiert. Sobald ein User, welchem in der GPO einer der beiden HP-Drucker zugeordnet war, sich angemeldet hatte, kam der DruckSpooler auf einem der Citrix-Server ins trudeln und bei allen darauffolgenden Anmeldungen auf dem gleichen Xenapp-System konnten keine Drucker mehr verbunden werden. Alle anderen User auf den verbleibenden 3 Servern waren nicht betroffen.

    Damit erklärt sich das sehr komische und im ersten Moment nicht 100% nachvollziehbare Verhalten. Aber man muss ja erstmal das System welches dahinter steckt verstehen bzw. den Grund identifizieren.

    By the way: Bei unserem Druckserver waren div. Standard-TCP-IP-Port-Anschlüsse auch mehrfach vorhanden/installiert mit anderem Namen, da div. Drucker neben dem PCL-Treiber auch als PS-Treiber installiert waren. Diese Geschichte sollte man parallel, ebenfalls überprüfen und beide installierte Treibervarianten auf den gleichen Standard-TCP-IP-Port umstellen.

    So .... Ich hoffe ich konnte und kann einigen damit helfen, die das gleiche Problem haben bzw. hatten. War echt tricky die Ursache für diese Geschichte herauszufinden, da einem die diversen Event-LOG-IDs teilweise doch sehr in die Irre geführt haben.

    Gruß

    Alex

    Donnerstag, 15. Dezember 2011 20:47
  • Hallo STEX20!

    Dein Problem ist ja schon eine Weile her.

    Hast du mitlerweile eine Lösung gefunden?

    Wir bekommen auch immer diese Fehlermeldungen bei der Druckerzuweisung auf den RemoteDesktop-Servern.

    Danke für deine Info.

    Schöne Grüße

    florinho

    Donnerstag, 2. Februar 2012 11:07
  • Hallo!

    Mir ist gerade aufgefallen, dass meine Fehlermeldung doch etwas von der Ursprungsmeldung abweicht:

    Das Benutzer...-Einstellungselement im Gruppenrichtlinienobjekt ...wurde nicht übernommen, da ein Fehler mit Fehlercode "0x8007000a Die Umgebung stimmt nicht." Dieser Fehler wurde unterdrückt. aufgetreten ist.

    Hat jemand eine Idee dazu?

    Danke

    Donnerstag, 2. Februar 2012 13:17
  • > nicht übernommen, da ein Fehler mit Fehlercode "0x8007000a Die Umgebung
    > stimmt nicht." Dieser Fehler wurde unterdrückt. aufgetreten ist.
     
    Ist noch a bissele wenig Info - hört sich aber irgendwie nach 32/64 Bit
    Problem an...
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 2. Februar 2012 15:45
    Beantworter
  • Info:

    Druck-Server: Win2008r2
    Remote-Desktop-Server: Win2008r2
    Drucker: Canon, HP,...
    Drucker-Zuweisung: über GPO
    Clients: XP, Win7, Thin Clients...

    Bei jeder Anmeldung eines Clients am Remote-Desktop-Server kommt je zugewiesenen Drucker folgende Meldung:

    Das Benutzer...-Einstellungselement im Gruppenrichtlinienobjekt ...wurde nicht übernommen, da ein Fehler mit Fehlercode "0x8007000a Die Umgebung stimmt nicht." Dieser Fehler wurde unterdrückt. aufgetreten ist.

    Wobei die Drucker im Normalfall funktionieren.

    Hat jemand eine Idee dazu?

    Danke

     


    • Bearbeitet florinho Freitag, 3. Februar 2012 10:05
    Freitag, 3. Februar 2012 10:02
  • Aktiviere für die GPP mal das Debug Logging:
     
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Freitag, 3. Februar 2012 10:31
    Beantworter
  • Danke für den Hinweis. Dabei bin ich auf folgendes gestoßen:

    Da meine GPO nur Benutzerkonfiguration enthält, habe ich die Computerkonfiguratons-Einstellungen bei dieser GPO deaktiviert. Dadurch sollten die GPOs schlanker bleiben.

    Nachdem man das Debug Logging aber in der Computerkonfiguration einstellt, musste ich natürtlich die Computerkonfiguratons-Einstellungen bei dieser GPO aktivieren.

    Sobald die GPO komplett aktiviert ist, kommen diese Warnmeldungen nicht mehr.

    Sobald man Computerkonfiguratons-Einstellungen bei dieser GPO deaktiviert, sind die Warnmeldungen wieder da.

    Warum ist das so?

    Ich habe doch bei meiner GPO nur Einstellungen bei der Benutzerkonfiguration vorgenommen.

    Freitag, 3. Februar 2012 11:05
  • Am 03.02.2012 12:05, schrieb florinho:
    > Nachdem man das Debug Logging aber in der Computerkonfiguration
    > einstellt, musste ich natürtlich die
    > Computerkonfiguratons-Einstellungen bei dieser GPO aktivieren.
     
    Du hast das Debug-Logging in der gleichen GPO aktiviert? Ich hätte ne
    andere dafür gemacht... Wenn der Fehler jetzt weg ist, steht natürlich
    auch nix im Log.
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Freitag, 3. Februar 2012 11:19
    Beantworter
  • Hallo Martin!

    Ich habe nun eine eigene GPO nur für diese Log-Einstellungen erstellt. Leider werden keine Log-Datei geschrieben, obwohl die Fehler nun wieder auftretten:

    Meistens:
    Das Benutzer ""-Einstellungselement im Gruppenrichtlinienobjekt "" wurde nicht übernommen, da ein Fehler mit Fehlercode "0x80070bc4 Es wurden keine Drucker gefunden." Dieser Fehler wurde unterdrückt. aufgetreten ist.

    Manchmal:
    Das Benutzer ""-Einstellungselement im Gruppenrichtlinienobjekt "" wurde nicht übernommen, da ein Fehler mit Fehlercode "0x8007000a Die Umgebung stimmt nicht." Dieser Fehler wurde unterdrückt. aufgetreten ist.

    Der Ordernpfad für die Log-Dateien exisitiert bereits, jedoch enthält er keine Log-Files. Die Benutzer haben Ändern-Rechte auf diese Ordner.

    C:\ProgramData\GroupPolicy\Preference\Trace

    Mittwoch, 8. Februar 2012 08:18
  • Kannst Du mal nen Gruppenrichtlinien-Ergebnissatz erstellen? (GPMC.MSC,
    unterster Punkt) und die Logging-Settings hier posten? Da stimmt was
    nicht, ich hätte noch nie erlebt, dass die GPP-CSEs keine Logs
    schreiben, wenn man es ihnen sagt...
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Mittwoch, 8. Februar 2012 15:13
    Beantworter
  • Hier ein Auszug aus dem Gruppenrichtlinien-Ergebnissatz:

    Hier die GPO der Log-Files:

    Mittwoch, 8. Februar 2012 15:32
  • Am 08.02.2012 16:32, schrieb florinho:
    > Hier die GPO der Log-Files:
     
    Der zweite Screenshot fehlt leider...
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Mittwoch, 8. Februar 2012 15:37
    Beantworter
  • Am 08.02.2012 16:32, schrieb florinho:
    > Hier die GPO der Log-Files:
     
    Der zweite Screenshot fehlt leider...
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Wird dieser Screenshot bei dir im vorherigen Post nicht angezeigt?
    Mittwoch, 8. Februar 2012 15:40
  • Am 08.02.2012 16:40, schrieb florinho:
    > Wird dieser Screenshot bei dir im vorherigen Post nicht angezeigt?
     
    Nein, aber jetzt (: Nimm mal ein anderes - explizites - Verzeichnis
    statt dem %commonappdata%\.... Und bei "Ereignisprotokollierung" auch
    noch Informationen.
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Mittwoch, 8. Februar 2012 18:09
    Beantworter
  • Nimm mal ein anderes - explizites - Verzeichnis
    statt dem %commonappdata%\.... Und bei "Ereignisprotokollierung" auch
    noch Informationen.

    Ich habe den Pfad auf

    C:\temp\GroupPolicy\Preference\Trace\

    angepasst und auch die Informationen in der Protokollierung aktiviert. Benutzer haben Ändern-Rechte auf C:\temp.

    Leider werden noch immer keine Log-Dateien geschrieben - trotz gpupdate /force auf den betreffenden Servern.

    Was mache ich falsch?

    Donnerstag, 9. Februar 2012 12:32
  • Am 09.02.2012 13:32, schrieb florinho:
    > Leider werden noch immer keine Log-Dateien geschrieben - trotz
    > gpupdate /force auf den betreffenden Servern.
     
    Nichts erkennbares... ?!? Benutzer brauchen da keine Schreibrechte, das
    Log schreibt der GPSVC im System-Kontext. Hast mal im Ergebnissatz unter
    "Einstellungen" geprüft, ob nicht nur die GPO angwendet wird, sondern
    tatsächlich auch die Settings aktiv sind?
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 9. Februar 2012 14:06
    Beantworter
  • sollte eingentlich passen oder?

    Freitag, 10. Februar 2012 10:33
  • Ja, sieht gut aus. Ich versteh's auch nicht...
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Freitag, 10. Februar 2012 13:12
    Beantworter
  • Gibt's inzwischen eine Lösung für das Problem, da der letzte Beitrag 1 Jahr alt ist?
    Montag, 1. Juli 2013 11:30
  • Habe das Problem das der Terminal Server für ca. 2.4 Sekunden hängt wenn sich ein Benutzer anmeldet der Drucker über einen Druckserver gemappt hat (ausschließlich HP UPD und Ricoh UPD als PCL.). Das geht gar nicht, da dann alle anderen Sitzungen auch hängen (keine Eingaben).

    Alle Server in einer Testumgebung neu aufgesetzt aktuellen Patchstand (Windows 2008 R2) Druckserver wie auch Terminal Server.

    Hat denn keiner eine Lösung.

    Gruß


    st_fbg

    Donnerstag, 25. Juli 2013 06:58
  • Hallo,

    bitte mal den

    http://blogs.technet.com/b/askpfeplat/archive/2013/03/12/slow-boot-slow-login-sbsl-hotfix-rollup-for-windows-7-and-server-2008-r2-available-today.aspx

    und noch wichtiger : http://support.microsoft.com/kb/2778831/de

    installieren. Der KB2778831 hat bei uns geholfen. Dann regelmäßig im c:\windows\ Verzeichnis nach temp Dateien schauen, die wurden bei uns vom HP UPD erstellt.

    Donnerstag, 25. Juli 2013 07:17
  • Hallo,

    das KB 2778831 hatte ich schon probiert.

    Habe jetzt das Update-Rollup auf dem Server wie auch auf dem Test Client Installiert. Leider ohne Erfolg. Schade.

    Ich habe wirklich keine Idee mehr.

    Hier noch der Link zu einem Thread den ich am Montag gestartet habe.

    http://social.technet.microsoft.com/Forums/de-DE/7239460c-5d97-4157-9679-8da542b2064f/ts-stockt-beim-anmelden-von-benutzern-ricoh-pcl6-uni-treiber

    Bitte die auch die Ergänzungen am ende lesen.

    Danke und Gruß


    st_fbg

    Donnerstag, 25. Juli 2013 08:55
  • Hallo,

    ich kann mal die Hotfixliste schicken, die wir momentan auf unseren Terminalservern installiert haben.

    Wir hatten lange Ärger mit dem HP UPD, auch PCL6.

    KB2457866,KB2462317 KB2493115 KB2511290 KB2526028 KB2549657 KB2561285 KB2614136 KB2616332 KB2617858 KB2620656 KB2647753 KB2699817 KB2778831

    KB2775511 KB958488 KB976902 KB976932 KB981070

    Alle sind bestimmt nicht für das Drucken relevant, aber wir haben zumindest jetzt weniger Stress..

    Ricoh UPD haben wir nicht, nur den HP UPD. Auch eine ältere Version, die haben in der Zwischenzeit schon ein paar neue rausgebracht. Vielleicht gibt es da Verbesserungen. Was wir hatten waren diese komischen Dateien im Windows (oder System32) Verzeichniss. Die wurden jedesmal angelegt wenn ein Drucker sich beim Benutzer verbindet. Wenn es zu viele werden (tausende) gibt es irgendwann Fehlermeldungen bei dem Verbinden der Drucker. Die einzige Lösung die wir gefunden haben war ein Taskbasiertes Löschen dieser Dateien.

    Werden die Drucker über Policy oder Script verbunden? Wir nutzen hier Group Policy Prefernces, gerade bei Benutzern die viele Drucker haben (>10) hatten wir viel Ärger.

    Grüße

    Donnerstag, 25. Juli 2013 09:34
  • Hallo,

    habe jetzt mal alle Patche heruntergeladen und Installiert, soweit noch nicht vorhanden und geeignet.

    Leider hat es nichts genützt. Ich habe immer noch beim anmelden (ab dem zweiten Benutzer) mit HP oder Ricoh Druckern. Ein STOP von ca. 3 Sekunden. Um so mehr Drucker der Benutzer hat um so länger Dauert es.

    Da wir Gleitzeit haben und alle Kollegen zu Unterschiedlichen Zeiten kommen. Würden die Server immer mal wieder (auch wenn es nur für 3 Sek. ist) stehen. Bei 150 Benutzern nervt das dann einfach.

    Danke und Gruß


    st_fbg

    Donnerstag, 25. Juli 2013 12:39