W7Pro32-Client und W2K8-32-Printserver - Drucker werden nicht gefunden (0x00000bc4)
Nachdem eine Woche alles wunderbar lief, sind plötzlich keine (Netzwerk)-Drucker mehr auf dem W7-Client da. Die XP-Clients können aber die Drucker auif dem W2K8-Server weiterhin ohne Probleme benutzen
Hallo,
ich kämpfe gerade wieder gegen "Wind(ows)-Mühlen":
Vorhanden:
W2K8-32bit als Printserver in Hyper-V, frisch aufgesetzt (ca. 1 Woche), aktueller Patchstand.
W7Pro32bit als Client, von XPPro über Vista auf W7 upgedated (Seit vca. 2 Wochen), dient als Pilot für Migration von XP auf W7.
Einige Netzwerkdrucker, (WSD, jetdirect, lpd), die über den Printserver freigegeben sind.
Das setup lief die ganze Woche einwandfrei, bis heute morgen der User sich beschwerte, daß alle seine Netzwerkdrucker weg sind und er sie nicht wieder verbinden kann. Die XP-Pro-Maschine haben mit den Druckern keinerlei Probleme.
Fehlermeldung:
Das führte mich dann per google zu http://windows.microsoft.com/de-DE/windows7/Why-do-I-get-error-0x00000b ...
Das war aber keine wirkliche Hilfe, auch die anderen fundstellen nicht.
Aufgrund der obigen MS-Anleitung (edit: Entfernen der Druckertreiber) kam es dann zu eine Absturz der Druckerwarteschlange, die dann zu folgendem Fehlereintrag im Eventlog führte:
Daher meien Frage an euch Kollegen:
Habt Ihr einen Tipp, in welcher Richtung ich weitersuchen könnte?
Momentan kommt, wenn ich einen Drucker verbinden will, folgende Meldung:
Im Eventlog sind keinerlei Hinweise auf Drucker- oder andere Probleme (zumidest die letzten 24h).
Die GPO-Anpassung, die weiter unten erwähnt wqurde, hat wie erwartet keine Linderung gebracht.
Workaround:
ich habe inzwischen über google & Co einen Workaround gefunden:
Siehe auch http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/o ...
Wenn man mit dem Drucker \\server\drucker verbinden will, gibt man beim neuanlegen des Druckers "lokaler" Drucker an und erstellt dann einen localport mit dem Namen "\\server\drucker". Damit funktioniert es zumindest.
Ist zwar von hinten durch die brust ins Auge, aber imme rnoch besser, als daß jetzt jeder neue Win7-Rechner die Netzwerkdrucker direkt anspricht und man im Endeffekt zwei Dutzend verschiedene Namen für denselben Drucker hat, ganz zu schweigen, daß die Einstellugen bei jedem dann anders sind.
Ich lasse es immer noch offen, da das eigentliche Problem nicht gelöst ist.
Hallo,
ich kämpfe gerade wieder gegen "Wind(ows)-Mühlen":
Vorhanden:
W2K8-32bit als Printserver in Hyper-V, frisch aufgesetzt (ca. 1 Woche), aktueller Patchstand.
W7Pro32bit als Client, von XPPro über Vista auf W7 upgedated (Seit vca. 2 Wochen), dient als Pilot für Migration von XP auf W7.
Einige Netzwerkdrucker, (WSD, jetdirect, lpd), die über den Printserver freigegeben sind.
Das setup lief die ganze Woche einwandfrei, bis heute morgen der User sich beschwerte, daß alle seine Netzwerkdrucker weg sind und er sie nicht wieder verbinden kann. Die XP-Pro-Maschine haben mit den Druckern keinerlei Probleme.
Fehlermeldung:
Der Vorgang konnte nicht abgeschlossen werden (0x00000bc4).
Es wurden keine Drucker gefunden.
Das führte mich dann per google zu http://windows.microsoft.com/de-DE/windows7/Why-do-I-get-error-0x00000b ...
Das war aber keine wirkliche Hilfe, auch die anderen fundstellen nicht.
Aufgrund der obigen MS-Anleitung (edit: Entfernen der Druckertreiber) kam es dann zu eine Absturz der Druckerwarteschlange, die dann zu folgendem Fehlereintrag im Eventlog führte:
Ereignis ID 1000
Name der fehlerhaften Anwendung: spoolsv.exe, Version: 6.1.7600.16385, Zeitstempel: 0x4a5bced7
Name des fehlerhaften Moduls: localspl.dll, Version: 6.1.7600.16385, Zeitstempel: 0x4a5bda13
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0005fcf3
ID des fehlerhaften Prozesses: 0x594
Startzeit der fehlerhaften Anwendung: 0x01cc32370273925e
Pfad der fehlerhaften Anwendung: C:\Windows\System32\spoolsv.exe
Pfad des fehlerhaften Moduls: C:\Windows\System32\localspl.dll
Daher meien Frage an euch Kollegen:
Habt Ihr einen Tipp, in welcher Richtung ich weitersuchen könnte?
Update:
Momentan kommt, wenn ich einen Drucker verbinden will, folgende Meldung:
Druckerverbindung herstellen
Druckerverbindung kann nicht hergestellt werden.
Details:
Fehler bei Vorgang: 0x00000006
Update 2:
Im Eventlog sind keinerlei Hinweise auf Drucker- oder andere Probleme (zumidest die letzten 24h).
Die GPO-Anpassung, die weiter unten erwähnt wqurde, hat wie erwartet keine Linderung gebracht.
Update 3
Workaround:
ich habe inzwischen über google & Co einen Workaround gefunden:
Siehe auch http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/o ...
Wenn man mit dem Drucker \\server\drucker verbinden will, gibt man beim neuanlegen des Druckers "lokaler" Drucker an und erstellt dann einen localport mit dem Namen "\\server\drucker". Damit funktioniert es zumindest.
Ist zwar von hinten durch die brust ins Auge, aber imme rnoch besser, als daß jetzt jeder neue Win7-Rechner die Netzwerkdrucker direkt anspricht und man im Endeffekt zwei Dutzend verschiedene Namen für denselben Drucker hat, ganz zu schweigen, daß die Einstellugen bei jedem dann anders sind.
Ich lasse es immer noch offen, da das eigentliche Problem nicht gelöst ist.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 168553
Url: https://administrator.de/contentid/168553
Ausgedruckt am: 22.11.2024 um 21:11 Uhr
26 Kommentare
Neuester Kommentar
Es mag nicht direkt mit den Fehlermeldungen zu tun haben, aber wie werden die Drucker denn verbunden, per Loginskript?
Unter Windows 7 gibt es eine Änderung bzgl. der Point-and-Print-Beschränkungen, das hat mir auch erst mal Kopfzerbrechen bereitet:
http://www.faq-o-matic.net/2009/10/08/drucken-unter-windows-7-in-der-do ...
Worüber verbindest du denn die Drucker, über \\servername\printername oder \\domain.ads\printername?
Ich habe hier ein bisschen mit Druckerverbindungen auf Verzeichnisebene herumgespielt und hatte dann ein ähnliches Phänomen: Ein paar Tage lang hat das wunderbar funktioniert, von heute auf morgen aber nicht mehr; ich meine, mit der gleichen/einer ähnlichen Fehlermeldung.
Verbinde ich die Drucker _nicht!_ über die Freigabe im Verzeichnis (also \\domain.ads\...), sondern direkt über den Server, auf dem sie freigegeben sind (also \\servername\...) funktioniert es einwandfrei.
Dies nur mal als Denkanstoss, wie gesagt, es mag am "Fehlerbild" vorbei gedacht sein...
Cheers,
jsysde
Unter Windows 7 gibt es eine Änderung bzgl. der Point-and-Print-Beschränkungen, das hat mir auch erst mal Kopfzerbrechen bereitet:
http://www.faq-o-matic.net/2009/10/08/drucken-unter-windows-7-in-der-do ...
Worüber verbindest du denn die Drucker, über \\servername\printername oder \\domain.ads\printername?
Ich habe hier ein bisschen mit Druckerverbindungen auf Verzeichnisebene herumgespielt und hatte dann ein ähnliches Phänomen: Ein paar Tage lang hat das wunderbar funktioniert, von heute auf morgen aber nicht mehr; ich meine, mit der gleichen/einer ähnlichen Fehlermeldung.
Verbinde ich die Drucker _nicht!_ über die Freigabe im Verzeichnis (also \\domain.ads\...), sondern direkt über den Server, auf dem sie freigegeben sind (also \\servername\...) funktioniert es einwandfrei.
Dies nur mal als Denkanstoss, wie gesagt, es mag am "Fehlerbild" vorbei gedacht sein...
Cheers,
jsysde
Hi,
na das find ich wieder super bei MS. Irgendwelche Spielereien einstellen, um alle Admins noch mehr zu verwirren.
Bei den Client den Befehl "gpupdate /force /boot" eingegeben, damit er auch die GPO gleich mal zieht und dann "gpresult.exe".
Man kann ja auch am DC einstellen, wie oft die GPO neu gezogen werden sollen.
Bei MS-Support schon mal angerufen und gefragt wozu diese "Feature" gut sein soll?
Gruss
Holli
na das find ich wieder super bei MS. Irgendwelche Spielereien einstellen, um alle Admins noch mehr zu verwirren.
Bei den Client den Befehl "gpupdate /force /boot" eingegeben, damit er auch die GPO gleich mal zieht und dann "gpresult.exe".
Man kann ja auch am DC einstellen, wie oft die GPO neu gezogen werden sollen.
Bei MS-Support schon mal angerufen und gefragt wozu diese "Feature" gut sein soll?
Gruss
Holli
Hallo Lochkartenstanzer,
leider muss ich mich auch seit einiger Zeit mit dem Thema spoolsv und win7 auseinander setzen. Die Event ID 1000 und der spoolsv error habe ich bereits zu genüge gegoogelt.
Bei mir ließen sich die Printer nicht mehr einbinden da die spoolerdienste immer abgeraucht waren. ließen sich zwar immer neu starten sind jedoch nach wenigen Sekunden wieder abgeraucht. Das Löschen des gesamten Inhaltes folgendes Ordners hat Abhilfe geschaffen.
C:\windows\system32\spool\printers
Mit folgenden befehlen in der cmd geht das ganz schnell. Oder eifach ein Script draus erstellen.
net stop spooler
del /Q /F /S "%systemroot%\System32\Spool\Printers\*.*"
net start spooler
Gefunden bei MS Answers!!
Hoffe das hilft.
Gruß,
Petrus.
leider muss ich mich auch seit einiger Zeit mit dem Thema spoolsv und win7 auseinander setzen. Die Event ID 1000 und der spoolsv error habe ich bereits zu genüge gegoogelt.
Bei mir ließen sich die Printer nicht mehr einbinden da die spoolerdienste immer abgeraucht waren. ließen sich zwar immer neu starten sind jedoch nach wenigen Sekunden wieder abgeraucht. Das Löschen des gesamten Inhaltes folgendes Ordners hat Abhilfe geschaffen.
C:\windows\system32\spool\printers
Mit folgenden befehlen in der cmd geht das ganz schnell. Oder eifach ein Script draus erstellen.
net stop spooler
del /Q /F /S "%systemroot%\System32\Spool\Printers\*.*"
net start spooler
Gefunden bei MS Answers!!
Hoffe das hilft.
Gruß,
Petrus.
Hola,
ich stelle mich mal mit in die Schlange für die Lösung des Problems an. Bei uns ist es ähnlich: Wir haben mehrere 2008 64er Printserver und einen 2008 64er Terminalserver. Alle Drucker sind lokal auf dem TS installiert, für die Clients werden die über den Printserver verbunden.
Prinzipiell kann ich das Problem ignorieren, da die User eigentlich keine Druckerverbindungen am Terminalserver herstellen sollen (ausser für einen PDF Drucker der die Rechnungen an ein Factoring System überträgt, aber die FiBu arbeitet GsD auf einem anderen Server) - aber ich befürchte, dass das Problem auch mal wo anders auftreten könnte und dann wirds haarig.
Prinzipiell habe ich das selbe Problem: Auf einem der Terminalserver, nennen wir ihn WTS3, kommt auch direkt nach dem Verbinden des Druckers der 0x00000006 - Ich habe einen neustart gemacht, den Treiber mal über die Servereigenschaften deinstalliert und die lokalen Sicherheitseinstellungen mal direkt eingetragen (vgl. http://social.technet.microsoft.com/Forums/en/itprovistaprinting/thread ..) obwohl sie eigentlich so schon per GPO verteilt werden sollten.
Bei uns lief das bis Freitag letzte Woche "wie ne eins" - seit gestern Morgen/Mittag bekomme ich Beschwerden - weiter betrifft das Problem nur einen von mehreren identischen Servern und auch von den Client Rechnern liegen mir keine Beschwerden vor.
0x00000006 deutet meist auf Rechteprobleme - wobei das beim Dom-Admin nicht der Grund sein dürfte.
Dann finde ich im Eventlog nur mehrere ID 3 für SpoolerWin32SPL - dass er auf S-1-5-21-3799714410-1688419369-289437818-500\Printers\Connections\S-1-5-21-3799714410-1688419369-289437818-500\Printers\Connections nicht zugreifen kann - der Schlüssel existiert und ist auch mit den gleichen Rechten wie auf den anderen Servern bestückt. DAS kann ich mir nicht erklären ....
Das es am Treiber liegt kann man nicht ganz ausschließen - das herauszutesten gestaltet sich aber auf einem Server mit 45 verschiedenen Druckern (also das meiste Brother - aber man bekommt ja 3 Monate später nicht mehr die gleichen Modelle *grml) und 30 Leuten die produktiv da arbeiten und drucken müssen als schwierig. Und da es auf den anderen Servern/Rechnern läuft und auch von Fr. auf Mo. nix daran gemacht wurde .... nun, man könnte meinen der Server hätte Launen ;)
Noch was: Wenn ich den Server reboote, dann muss ich mind. 1 mal, manchmal auch 10 mal, den spoolerservice neustarten bis da endlich mal Drucker in der Liste erscheinen - sonst ist es leer. Das Problem habe wir übrigens auf ALLEN Terminalservern.
Falls es ne Rolle spielt: Die WTS* und der PRINT Server sind Hyper-V Guests. Wie gesagt - es trifft uns nicht so hart, da es nur einen Terminalserver betrifft und ich da alle nötigen Drucker jetzt lokal installiert habe - trotzdem ist das Problem zu ernst um es einfach zu ignorieren.
Denkanstoss:
Ich bin mehr der Linux-Mensch - wenn wir da ein Problem haben, dann parsen wir logfiles und schmeissen im größten Zweifel strace an um die Fehler zu finden (strace stellt sinngemäß ALLES was ein Programm macht auf dem Bildschirm da) und dann werden sie gefunden und beseitigt - kurz: man geht analytisch vor. Unter Windows habe ich den Eindruck, dass die Fehlerbeseitugung mehr nach dem Trial and Error Prinzip funktioniert - worauf ich hinaus will: Gibts keine analytische Methode dieses, oder andere Windowsprobleme zu lösen ? In vielen Fällen hilft ja auch das Eventlog - aber oft ist das völlig wertlos - für irgendwelchen Schwachsinn wirrft es 100 Fehler raus und wenn man wirklich ein Problem hat, dann steht da nix gescheites drin. kann man in diesem speziellen Fall dem Spooler ein logfile entlocken ? Irgendwo wird doch stehen, warum der 0x00000006 meldet und wie es dazu kommt ....
Gruss
Marcel Ebbrecht
ich stelle mich mal mit in die Schlange für die Lösung des Problems an. Bei uns ist es ähnlich: Wir haben mehrere 2008 64er Printserver und einen 2008 64er Terminalserver. Alle Drucker sind lokal auf dem TS installiert, für die Clients werden die über den Printserver verbunden.
Prinzipiell kann ich das Problem ignorieren, da die User eigentlich keine Druckerverbindungen am Terminalserver herstellen sollen (ausser für einen PDF Drucker der die Rechnungen an ein Factoring System überträgt, aber die FiBu arbeitet GsD auf einem anderen Server) - aber ich befürchte, dass das Problem auch mal wo anders auftreten könnte und dann wirds haarig.
Prinzipiell habe ich das selbe Problem: Auf einem der Terminalserver, nennen wir ihn WTS3, kommt auch direkt nach dem Verbinden des Druckers der 0x00000006 - Ich habe einen neustart gemacht, den Treiber mal über die Servereigenschaften deinstalliert und die lokalen Sicherheitseinstellungen mal direkt eingetragen (vgl. http://social.technet.microsoft.com/Forums/en/itprovistaprinting/thread ..) obwohl sie eigentlich so schon per GPO verteilt werden sollten.
Bei uns lief das bis Freitag letzte Woche "wie ne eins" - seit gestern Morgen/Mittag bekomme ich Beschwerden - weiter betrifft das Problem nur einen von mehreren identischen Servern und auch von den Client Rechnern liegen mir keine Beschwerden vor.
0x00000006 deutet meist auf Rechteprobleme - wobei das beim Dom-Admin nicht der Grund sein dürfte.
Dann finde ich im Eventlog nur mehrere ID 3 für SpoolerWin32SPL - dass er auf S-1-5-21-3799714410-1688419369-289437818-500\Printers\Connections\S-1-5-21-3799714410-1688419369-289437818-500\Printers\Connections nicht zugreifen kann - der Schlüssel existiert und ist auch mit den gleichen Rechten wie auf den anderen Servern bestückt. DAS kann ich mir nicht erklären ....
Das es am Treiber liegt kann man nicht ganz ausschließen - das herauszutesten gestaltet sich aber auf einem Server mit 45 verschiedenen Druckern (also das meiste Brother - aber man bekommt ja 3 Monate später nicht mehr die gleichen Modelle *grml) und 30 Leuten die produktiv da arbeiten und drucken müssen als schwierig. Und da es auf den anderen Servern/Rechnern läuft und auch von Fr. auf Mo. nix daran gemacht wurde .... nun, man könnte meinen der Server hätte Launen ;)
Noch was: Wenn ich den Server reboote, dann muss ich mind. 1 mal, manchmal auch 10 mal, den spoolerservice neustarten bis da endlich mal Drucker in der Liste erscheinen - sonst ist es leer. Das Problem habe wir übrigens auf ALLEN Terminalservern.
Falls es ne Rolle spielt: Die WTS* und der PRINT Server sind Hyper-V Guests. Wie gesagt - es trifft uns nicht so hart, da es nur einen Terminalserver betrifft und ich da alle nötigen Drucker jetzt lokal installiert habe - trotzdem ist das Problem zu ernst um es einfach zu ignorieren.
Denkanstoss:
Ich bin mehr der Linux-Mensch - wenn wir da ein Problem haben, dann parsen wir logfiles und schmeissen im größten Zweifel strace an um die Fehler zu finden (strace stellt sinngemäß ALLES was ein Programm macht auf dem Bildschirm da) und dann werden sie gefunden und beseitigt - kurz: man geht analytisch vor. Unter Windows habe ich den Eindruck, dass die Fehlerbeseitugung mehr nach dem Trial and Error Prinzip funktioniert - worauf ich hinaus will: Gibts keine analytische Methode dieses, oder andere Windowsprobleme zu lösen ? In vielen Fällen hilft ja auch das Eventlog - aber oft ist das völlig wertlos - für irgendwelchen Schwachsinn wirrft es 100 Fehler raus und wenn man wirklich ein Problem hat, dann steht da nix gescheites drin. kann man in diesem speziellen Fall dem Spooler ein logfile entlocken ? Irgendwo wird doch stehen, warum der 0x00000006 meldet und wie es dazu kommt ....
Gruss
Marcel Ebbrecht
@linux: Ja, so ist es - Allerdings hat auch das seine Tücken, wenn man Windows Clients bedienen will (ich rede da jetzt von größeren Setups) - Stichwort: Treiber verteilen.
@errlog: Du meinst das Eventlog (also die Ereignisanzeige), oder (hab ich da in all den Jahren was übersehen) ....
Auf http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/ ... hat sich jetzt auch MS Mensch eingeklinkt - vielleichts wirds ja was. Patchstand ist der 04.08.11 (ich war im Urlaub). Das einzige was in der Zeit gemacht wurde war die Installation eines Updates für ArcServe.
Was hast du denn sonst noch so auf dem Rechner ? Evtl. finden wir da Zusammenhänge...
Grobe Übersicht der Software: MS Office XP, OpenOffice 3, ArcServe, Daemon Tools, DymoLabel, Foxit Reader, Adobe Acrobat reader 9, FrontMotion Firefox, Ghostscript, NX Client, OrgPlus 8, NX Client, VNC Client, PVX, VLC, GVim, WinRAR, WinSCP, XMing, FreePDF
Gruss
@errlog: Du meinst das Eventlog (also die Ereignisanzeige), oder (hab ich da in all den Jahren was übersehen) ....
Auf http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/ ... hat sich jetzt auch MS Mensch eingeklinkt - vielleichts wirds ja was. Patchstand ist der 04.08.11 (ich war im Urlaub). Das einzige was in der Zeit gemacht wurde war die Installation eines Updates für ArcServe.
Was hast du denn sonst noch so auf dem Rechner ? Evtl. finden wir da Zusammenhänge...
Grobe Übersicht der Software: MS Office XP, OpenOffice 3, ArcServe, Daemon Tools, DymoLabel, Foxit Reader, Adobe Acrobat reader 9, FrontMotion Firefox, Ghostscript, NX Client, OrgPlus 8, NX Client, VNC Client, PVX, VLC, GVim, WinRAR, WinSCP, XMing, FreePDF
Gruss
PS: Wegen einer Macke des Warenwirtschaftssystems, läuft da auch ein linux-Printserver, mit dem solche Probleme nicht
auftauchen. Leider darf ich den nicht generell benutzen, weil der Kunde "Windows-Affin" ist.
auftauchen. Leider darf ich den nicht generell benutzen, weil der Kunde "Windows-Affin" ist.
Wenn du es richtig anstellst würde es er nur daran merken, dass es funktioniert. Da es i.A. niemanden interessiert wie etwas funktioniert wenn es funktioniert, wird er auch nicht fragen ;)
Noch was: Darf man fragen, in welcher Größenordnung du da werkelst ?
Hi, gibt es schon was neues ? Ich meine ich komm erstmal klar, aber wäre längerfristig an einer Lösung interessiert.
Gruss
Marcel
Gruss
Marcel
Ich habe eine Antwort unter http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/ ... bekommen. Allerdings kann ich damit nicht recht was anfangen.
Geht das nur mir so, oder kommt euch das auch so vor, als ob seine Antworten generell nutzlos sind ? Der letzte Hinweis bezog sich auf ein Win7 <-> 2003 Problem obwohl ich erwähnt hatte, dass wir nur 2008er einsetzen. Oder verstehe ich den Alan einfach nur falsch ?
Gruss
Gruss
It sounds like something is blocking the async RPC traffic between the remote print share and the TS server since local printing works. I would expect a reboot of the TS server to have placed the connectivity back into the correct state.
Heisst das, ich soll den TS mal neustarten ? .... 1000 mal probiert, 1000 mal hats nicht funktioniert ... *sing
\windows\system32\win32spl.dll is the spooler component that calls into RPC for remote connections. Can you verify the file is the same on the server that does not work as the servers that do?
Sind bei mir identisch - somit nicht das Problem.
You can run "sfc /scannow" in an elevated command prompt to detect any file system corruption.
Habe ich gemacht. Die gute Nachricht: Ich muss nach dem Neustart nun nicht mehr wild den Spooler neustarten; die lokalen (!) Drucker tauchen stehen sofort zur Verfügung (ich habe damit indirekt ein anderes Problem gelöst). Ich führe das auch mal auf den anderen Terminalservern durch - schaden kanns offensichtlich nicht wirklich - zur Not habe ich die Snapshots.
Nach dem Scan kam folgende Meldung:
sfc /SCANNOW
Systemsuche wird gestartet. Dieser Vorgang kann einige Zeit dauern.
Überprüfungsphase des Systemsuche wird gestartet.
Überprüfung 100% abgeschlossen.
Der Windows-Ressourcenschutz hat beschädigte Dateien gefunden und konnte einige des Dateien nicht reparieren.
Details finden Sie in der Datei "CBS.Log" (windir\Logs\CBS\CBS.log).
Beispielsweise "C:\Windows\Logs\CBS\CBS.log".
Ich habe kurz in das 10MB Logfile reingesehen - ist hier jemand unter uns, der sowas verstehen kann ? Da stehen hunderte Fehler drin - von denen 99% für mein Problem wahrscheinlich unerheblich sind.
Gruss
Leider tut sich in dem MS Thread nicht viel - gibt es bei euch irgendwelche Neuigkeiten bzgl. dieses Problems ?
Leider hat das in dem MS Forum auch nichts gebracht. Ich denke ich werde Dienstag ein Ticket bei MS aufmachen - ich melde mich wieder, wenn es Neuigkeiten gibt.
Hallo Leute,
ich habe mich auch mit dem 0x00000006 Fehler auf einem Terminalserver rumgequält, der die Drucker per Freigabe von einem
Druckserver holen sollte. Schlagartig funktionierte es nicht mehr. Jeder Verbindungsversuch endete in der o.g. Fehlermeldung.
Witziger weise konnte ich die Drucker aber über IP verbinden, nur nicht über den Servernamen. Klar Fehler im AD oder DNS. Aber nichts
in dieser Art. Ich hatte einen defekten Reg Key in:
HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Print \ Providers \ Client Side Rendering Print Provider \ Server \
Habe alles unter Server gesichert und dann gelöscht. Und siehe da, es funktioniert wieder mit dem verbinden! Wo der Fehler genau
liegt, und ob alles wieder 100% ist, das weiß ich aber erst nächste Woche.
Viele Grüße
Uwe
ich habe mich auch mit dem 0x00000006 Fehler auf einem Terminalserver rumgequält, der die Drucker per Freigabe von einem
Druckserver holen sollte. Schlagartig funktionierte es nicht mehr. Jeder Verbindungsversuch endete in der o.g. Fehlermeldung.
Witziger weise konnte ich die Drucker aber über IP verbinden, nur nicht über den Servernamen. Klar Fehler im AD oder DNS. Aber nichts
in dieser Art. Ich hatte einen defekten Reg Key in:
HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Print \ Providers \ Client Side Rendering Print Provider \ Server \
Habe alles unter Server gesichert und dann gelöscht. Und siehe da, es funktioniert wieder mit dem verbinden! Wo der Fehler genau
liegt, und ob alles wieder 100% ist, das weiß ich aber erst nächste Woche.
Viele Grüße
Uwe