robobob
Goto Top

Windows 2008R2 - Printserver - XP-Clients

Hallo Zusammen,

folgende Problemstellung ergibt sich mir seit Tagen.

Leider lässt es mein Arbeitsfeld nicht zu mich "intensiv" mit solchen Problemen zu beschäftigen.


Unzwar:

Zur Zeit hat unser Unternehmen noch einen alten Printserver unter W2K3 laufen.

Die dort angelegten Drucker werden über ein Skript an die Clients verteilt (WinXP / Win7).

Dies funktionierte auch immer wunderbar.

Nun habe ich einen neuen Server erstellt W2K8R2 um dort einen neuen Printserver bereitzustellen.

Neuer Printserver: Windows Server 2008 R2, 4 GB RAM, 1 Core, 100GB HDD (VMware-Umgebung!)


Im Prinizip nun das übliche Spiel, Drucker hinzufügen (via IP)
Treiber auf dem neuen Druckserver einbinden (x86/x64).
Via GPO bereitstellen. DONE

Windows 7 Clients wunderbar. Alle Drucker da, in dem Fall doppelt durch das noch vorhandene Skript, welches ja auf den
alten Printserver zeigt.

Windows XP Clients zeigen nur die Drucker auf dem alten Printserver an!

JA klar, ganz logisch, man muss ja noch eine GPO erstellen die die PUSHPrinterConnections.exe enthält.

Erledigt. Nun auf meinem TestPC (XP-client) gpupdate /force. Neustart.

Als normaler User folgende Meldung der Spoolsv.exe


"The instruction at "0x7c910a19" referenced memory at "0x00000000". The memory could not be "read"."


Melde ich mich als Administrator an dem Testsystem an kommt diese Meldung:


"szAppName : spoolsv.exe szAppVer : 5.1.2600.6024 szModName : ntdll.dll
szModVer : 5.1.2600.5755 offset : 00010a19 "

Dann seh ich unter den Drucker-Optionen das hier kein einziges Gerät gelistet ist.

Nun, wenn ich den Print Spooler Service aufrufe sehe ich das dieser nicht mehr gestartet ist.
Wenn ich diesen nun Neustarte tauchen die Geräte wieder allesamt auf! (alter Printserver und neuer Printserver).

Ich habe schon einiges gegoogelt und hin und her.
Folgendes habe ich auch installiert: Group Policy Preference Client Side Extensions for Windows XP (KB943729)
ohne Erfolg!

Ich habe das Skript der alten Drucker komplett entfernt und dennoch nichts.
Die GPOs der neue Printer habe ich auch disabled, keine Hilfe.

Trotz aller Änderungen etc. taucht der Fehler weiterhin auf, dazu kommt: Wenn ich den Print Spooler Dienst neustarte werden wieder ALLE Drucker gelistet, auch diese, die eig. garnicht mehr verteilt werden sollten.


Ich entschuldige mich für vorrangegange Textmasse und das Durcheinander.

Mit freundlichen Grüßen

Content-ID: 187005

Url: https://administrator.de/contentid/187005

Ausgedruckt am: 07.11.2024 um 22:11 Uhr

Robobob
Robobob 26.06.2012 um 07:13:08 Uhr
Goto Top
/push

Keiner auch nur eine kleine Idee?
Ich weiß das ihr gerne noch mehr Informationen habt, aber bevor ich hier
alles dar lege wollte ich doch wenigstens wissen ob sich einer mit mir
Unterhält ;)

Gruß
kontext
kontext 26.06.2012 um 07:51:18 Uhr
Goto Top
Moin,

was passiert wenn du die Drucker per Script verbindest ...
... kommt da der gleiche Fehler, oder werden da alle Drucker verbunden?

Das Problem ist schwer zu identifizieren, da ja die Drucker alle verbunden werden (wenn der Spooler neugestartet wird)
Daher würde ich in erster Linie auf die GPO tippen ...

Greetz
fabian (zanko)
Robobob
Robobob 26.06.2012 um 09:18:29 Uhr
Goto Top
Hallo Zanko,

die druckerbezogenen GPOs sind ALLE komplett "disabled".
Ich kann dir zu 100% versichern das hier keine GPOs mehr greifen.

Ich habe das Skript nun auf den alten stand zurückgestellt und
die "neuen" Drucker-Verbindungen auf meinem Test-Client gelöscht.

Hier läuft jetzt alles wie vorher, natürlich nur notdürftig auf den alten Printserver.
Heißt meine Leute können wieder von ihren XP-Kisten aus drucken.

Damit ist meine Aufgabe aber keines Falls erledigt.

Also Stand: Alle Clients (XP/7) bekommen ihre Druckgeräte wieder über das alte Skript eingebunden.

Gruß face-sad
kontext
kontext 26.06.2012 aktualisiert um 09:25:20 Uhr
Goto Top
HeyHo,

eigentlich war meine Frage, was passiert wenn du das Script auf den neuen Printserver umbiegst.
Testweise kopierst du das Script und ersetzt den alten PS durch den neuen Printserver ...
... wenn du natürlich die Druckerbezeichnung auch geändert hast musst du diese im Script auch anpassen ;)

Auf das worauf ich hinaus will:
Funktioniert das Druckermapping auf allen PC's ohne Probleme mittels Script
Sollte dies ohne Probleme funktionieren dann müssen wir uns evtl. die GPO anschauen ...
Oder bringt der Druckerspooler jetzt immer noch die Fehlermeldungen?
... Evtl. schmeißt du mal alle Druckertreiber vom System ...

Greetz
Robobob
Robobob 26.06.2012 um 09:32:29 Uhr
Goto Top
Hey,

kuzes Update.
Selbst nach dem ich das alte Skript wieder eingestellt habe hängt sich der SpoolerService noch auf.
Ebenso tauchen die Mappings der Drucker auf dem "neuen" Printserver wieder auf.

Ich boote jetzt mal den TestPc ohne Skript.
Danach probiere ich nochmal die Umstellung des Skripts auf den neuen Printserver.

Gruß
kontext
kontext 26.06.2012 um 09:35:29 Uhr
Goto Top
Hey,

okay - ansonsten mach zur Sicherheit auch den TEST-PC mal Platt ...
... sollte eig. bei einem TEST-PC möglich sein, oder?

Evtl. ist da ein Druckertreiber dabei der sich nicht verträgt ...
... oder wo einfach nicht "richtig" installiert wurde und darum die Probleme verursacht werden

Greetz
Robobob
Robobob 26.06.2012 um 09:53:57 Uhr
Goto Top
Ohne Skript tauchen die alten Drucker wieder nach kurzer Zeit auf.
Obwohl ich die "neuen" Printer alle auf dem neuen Printserver gelöscht habe.
Immerhin taucht die Fehlermeldung zur Zeit nicht mehr auf.

Ich bin dennoch sprachlos.
kontext
kontext 26.06.2012 um 10:05:42 Uhr
Goto Top
Zitat von @Robobob:
Ohne Skript tauchen die alten Drucker wieder nach kurzer Zeit auf.
Obwohl ich die "neuen" Printer alle auf dem neuen Printserver gelöscht habe.
Immerhin taucht die Fehlermeldung zur Zeit nicht mehr auf.

Ich bin dennoch sprachlos.

Ich bin verwirrt face-smile
Wenn ich das richtig verstanden habe:
Kein Script / Keine GPO Drucker vom alten PS erscheinen trotzdem

Wie gesagt - mach mal die Maschine platt und versuch es dann nochmals ...
Dann dürfen keine Drucker gemappt werden - und dann können wir nochmals von 0 starten ...

Greetz
Robobob
Robobob 26.06.2012 um 10:19:44 Uhr
Goto Top
Ich "darf" die Maschine leider nicht platt machen. Sonst wäre es wohl schon gestern passiert.

Das ist ein Mitarbeiter-PC der durch "Zufall" zur Zeit frei ist. Und aus diversen Gründen darf ich nun mal nicht einfach so platt machen, auch wenn ich wollte.

Also ohne Skript ohne aktive GPO, tauchen die Drucker auf dem "neuen" Printserver wieder auf,
obwohl dieser mittlerweile ausgeschaltet ist.

Gott sei dank laufen die Drucker auf dem alten Printserver mit dem Skript wieder normal.

Ob das Problem die Ports auf dem Printserver sind? Welche man nicht einfach so wieder löschen kann, da es heißt diese wären in Gebrauch.

Oder sind i-welche GPOs doch noch aktiv? Vll. durch eine fehlerhafte Replikation der DCs.

Mir ist ja danach den Neuen Printserver als erstes mal zu killen.
Aber ich glaube kaum das dies groß helfen würde.
kontext
kontext 26.06.2012 um 10:26:36 Uhr
Goto Top
Zitat von @Robobob:
Ich "darf" die Maschine leider nicht platt machen. Sonst wäre es wohl schon gestern passiert.

Das ist ein Mitarbeiter-PC der durch "Zufall" zur Zeit frei ist. Und aus diversen Gründen darf ich nun mal nicht
einfach so platt machen, auch wenn ich wollte.

Alles klar - in diesem Fall ist es kein richtiger Test-PC ..
.. dann ist die Geschichte wieder was anderes ...

Also ohne Skript ohne aktive GPO, tauchen die Drucker auf dem "neuen" Printserver wieder auf,
obwohl dieser mittlerweile ausgeschaltet ist.

Sie tauchen auf dem Client auf, oder? Auf dem Printserver sind sie ja installiert ...
... diese Aussage verwirrt mich enorm ...
... Sprich: Drucker auf neuem Printserver, oder?

Gott sei dank laufen die Drucker auf dem alten Printserver mit dem Skript wieder normal.

Ob das Problem die Ports auf dem Printserver sind? Welche man nicht einfach so wieder löschen kann, da es heißt diese
wären in Gebrauch.

Ich denke du hast den Printserver ausgeschaltet?

Oder sind i-welche GPOs doch noch aktiv? Vll. durch eine fehlerhafte Replikation der DCs.

Kann sein - was sagt gpresult / was sagt das Eventlog?

Alles ganz verwirrend und verwunderlich die Geschichte
Greetz
Robobob
Robobob 26.06.2012 um 10:35:09 Uhr
Goto Top
Ok nochmal. Du hast ja Recht, ich dachte ich habs noch einigermaßen beschrieben.

NEUER printserver ist AUS. (Alle Drucker auf dem neuen Printserver wurden gelöscht!)
ALTER printserver ist AN.

Alte Drucker via Skript zu den Clients. Funktioniert.

Boot XP-Client --> Skript läuft bei Anmeldung.
--> Drucker des alten Printservers werden gemappt.
nach wenigen Sekunden tauchen alle Drucker die auf dem NEUEN Printserver installiert waren
auf der XP-maschine auf, aber als "nicht verfügbar" angezeigt!

Daher wohl auch keine Fehlermeldung mehr.
kontext
kontext 26.06.2012 um 10:44:00 Uhr
Goto Top
Alles klar face-smile
Jetzt kommt wieder ein wenig Klarheit in die ganze Geschichte ...

Das Script hast du geprüft - nicht das der neue Printserver im Script steht ...
... würde erklären warum die Drucker dann auch gemappt werden
... das die Drucker nicht verfügbar sind würde passen - da Printserver DOWN ist

Aber so wie es für mich aussieht, zieht da immer noch entweder die GPO oder ein anderes Script
Was sagt gpresult oder das eventlog - kannst du da etwas brauchbares entnehmen?

Gruß
Robobob
Robobob 26.06.2012 um 10:58:49 Uhr
Goto Top
Ich habe wie gesagt das alte skript genommen, in diesem steht wirklich NUR der alte Printserver.

Ich habe aber etwas bei google vorhin gelesen.
Unzwar hab ich einen Fehler gemacht und die Printer auf dem "neuen" Printserver nicht so gelöscht wie man das tut, bzw. die GPOs auch nicht.

Denn beim Verteilen der Printer wird ein Registry-Eintrag angelegt, welcher diese "Falschen" Drucker wieder einbindet.
Man soll dann die Drucker nochmal neu auf dem Printserver anlegen, mit gleichem Namen versteht sich, und im Anschluss diese ordentlich entfernen, so das sie auch im Netzwerk gekillt werden.

Ich teste das mal.
Robobob
Robobob 26.06.2012 um 11:46:43 Uhr
Goto Top
Es hilft alles nichts.

Es gibt nun Clients bei denen nur die Printer vom alten Server gemappt sind
und es gibt Clients bei denen die Printer des alten und des NEUEN Printservers gemappt sind.

Aber die Leute können und Drucken und ich mache hier mal einen CUT
und versuche mir etwas mehr Zeit die nächsten Tage einzuräumen um mich damit zu beschäftigen.

Oder es gibt Überstunden..mal wieder ;)

so on...danke für die rege Beteiligung Zanko
kontext
kontext 26.06.2012 um 11:49:42 Uhr
Goto Top
Alles klar - kurios und dubios face-smile
In meinen Augen zieht da irgend eine GPO ...
... wie gesagt - mal schauen was eventlog und gpresult sagt
... Fehleranalyse und Fehlersuche *hurra* ;)

OK - halt uns / mich Up2Date ...
... evtl. lokalisieren wir ja dann den Fehler

Kein Thema & Greetz
Robobob
Robobob 26.06.2012 aktualisiert um 15:53:22 Uhr
Goto Top
Also es ist bisher alles unverändert,

ich habe zwischendurch mal die Drucker vom "neuen" Printserver aus der Registry des Test-Clients gelöscht.
Warum auch immer gibt es unter dem HKEY_Users_%username" bei jedem user der ein Profil lokal gespeichert hat
den Pfad der "neuen" Drucker unter HKEY_Users_Robobob_Printers

Ich habe nun von Hand alle "neuen" Drucker bei sämtlichen Usern wie auch dem "DefaultUser" die Schlüssel dieser
Drucker gelöscht.

Da die GPOs für die Printer eigentlich nur die Geräte per Computer verteilen sollten, man muss ja "nur" das Häkchen setzen.

Was passiert? --> Nach einem Neustart sind alle Schlüssel wieder da!

Das zeigt mir das deine Vermutungen in Bezug auf die GPOs richtig sein könnten.

Dennoch lässt sich keine GPO mehr finden die etwas mit meinen Druckern zu tun hat.

Gruß
kontext
kontext 27.06.2012 aktualisiert um 09:49:38 Uhr
Goto Top
HeyHo,

Wie sieht deine GPO genau aus?
Wie hast du die GPO vom Client entzogen oder hast du die GPO gelöscht?

Was sagt Start - Ausführen - CMD - gpresult auf dem Client-PC?

Greetz
Robobob
Robobob 27.06.2012 um 10:06:10 Uhr
Goto Top
Update: Ich habe den Test-PC ohne Netzwerkverbindung gestartet und die Drucker des "neuen" Printservers tauchen dennoch nach wenigen Sekunden auf.

Jetzt habe ich unter HKEY_LOCAL_MACHINE - System - ControlSet - Control - Print - Connections
die falschen Geräte gefunden und dort gelöscht!

Siehe da, sie tauchen nicht mehr auf. Obwohl die Geräte noch mehrfach in der Registry stehen.
Wie oben genannt unter den HKEY_USERS sind die falschen Drucker immernoch.

Gruß
kontext
kontext 27.06.2012 um 10:13:19 Uhr
Goto Top
Meiner Meinung nach wäre es gut wenn wir hier einen Schnitt machen und auf einem sauberen System weiter machen können ...
... da eine Neuinstallation nicht möglich ist, würde ich wie folgt vorgehen:
... Reinigung der Registry
... Reinigung des lokalen Printservers (auf dem Client alle Treiber / Port's / Drucker löschen)
... evtl. noch Reinigung auf Explorer Ebene

Dann haben wir wieder ein "halbwegs" sauberes System und können dann nochmals los starten ...
... Mittlerweile haben wir schon so viele Faktoren das wir nicht mehr wissen oder mit 100%iger Genauigkeit sagen können was nun, im Falle ein Änderung, passiert bzw. ob diese Änderungen wirklich durch uns erfolgt ist oder dadurch, dass das System "verhunzt" ist. Und daher drehen wir uns im Kreis ...

Greetz
Robobob
Robobob 27.06.2012 um 10:19:57 Uhr
Goto Top
Da hast du vollkommen recht.

Ich werde im Verlauf des Tages den "neuen" Printserver killen und eine neue Maschine anlegen.
Dann ist dieses System immerhin wieder jungfräulich.

GPResult ergab übrigens nicht "abnormales" die üblichen GPOs die in unserer Domäne arbeiten.

Vielen Dank nochmals für deine rege Beteiligung
Robobob
Robobob 30.06.2012 um 13:44:44 Uhr
Goto Top
Hallo,

also folgende Lösung habe ich "erarbeitet".

Ich hol nochmal kurz aus:

Anmelden an Test-XP, Skript mappt Drucker des alten Printservers. Drucker des neuen Printservers kommen via GPO, testweise nur zwei verschiedene Drucker aus dem Netzwerk.
Auf dem XP-Test PC wurden alle Updates installiert. Manuell habe ich XML-Lite und Group Policy Preference Client Side Extensions for Windows XP (KB943729) installiert. Ohne Erfolg, Printer Spool Dienst hängt sich auf.

Anmelden ohne Skript im Hintergrund schafft keine Abhilfe. Anmelden ohne GPO bringt die Fehlermeldung ebenso.

Lösung:

Anmelden ohne Skript.
Registry aufrufen, Treiber-Schlüssel der Drucker suchen und löschen!
Schritt 3 und 4 im folgenden Link
http://support.microsoft.com/kb/810894

Danach darf sich an dem PC natürlich kein Nutzer mehr anmelden der das Skript in seinem Profil hat.
Das bedeutet jetzt für mich einiges an Turnschuh-Arbeit bei ca. 40 XP Clients.

Leider scheint es nicht anders zu gehen. Ich muss diese alten Treiber rauswerfen und dann kann der neue Printserver seine Geräte/Treiber verteilen.
Traurig.

Gruß
kontext
kontext 02.07.2012 um 07:39:29 Uhr
Goto Top
HeyHo,

danke für die Rückmeldung.
Dann hast du ja jetzt einige Abende was zu tun - ist eh keine EM mehr ;)

Greetz
fabian (zanko)
Robobob
Robobob 02.07.2012 um 09:18:53 Uhr
Goto Top
Hi,

ja ganz großes Damentennis das Ganze ;)

Ich hab ja mehr gehofft du hast noch eine Idee wie ich den Aufwand kleiner halten könnte.

Ach Mensch.

Und der Praktikant den ich habe ist natürlich in der zweiten Woche schon krank.

Das Ganze wird sich aber wohl über 2 Wochen hinziehen, wenn das reicht.
Hier gibts ständig Dinge die "ganz ganz" wichtig sind und die IT betreffen.

Nunja einen schönen Start in die Woche wünsche ich!

Gruß Max
kontext
kontext 02.07.2012 um 09:31:59 Uhr
Goto Top
Naja das Problem ist der abgesicherte Modus.
Ansonsten könntest du das ja alles per Remote-Tools erledigen àla VNC oder Dameware ...

So musst du natürlich an jede Maschine ...
... und das mit dem Praktikant ist so eine Sache ;)

Danke ebenfalls einen guten Start und Wie kann ich einen Beitrag als gelöst markieren? nicht vergessen ;)

Greetz