8
Druck Win7 auf Server 2008 aus DOS - Zugriff verweigert
Hallo z'samm,
ich kämpfe bei einigen Kunden mit einem seltsamen Phänomen. Gegeben ist ein Windows-2008-Server (R2) und ein Client mit Windows 7 Professional (32 bit) [Nachtrag: Oder Vista]. Beide aktuell gepatcht, es läuft alles im Grunde ganz gut, incl. dem Zugriff auf die freigegebenen Drucker unter Windows. Nun setzen die Kunden aber eine DOS-basierte Warenwirtschaft ein. Diese setzt Druckaufträge ab, indem einfach auf den UNC-Pfad eine Ausgabe generiert wird. Also im Grunde das gleiche, als wenn man in der Kommandozeile z.B. DIR > \\SERVER\DRUCKER eingibt. Und eben dies funktioniert in der obigen Konstellation nicht, weder das eine noch das andere. Auf ein DIR > \\SERVER\DRUCKER erhalte ich lapidare Meldung "Zugriff verweigert". Keine Einträge im Ereignisprotokoll.
Natürlich habe ich schon ein wenig geforscht. Der Benutzer hat Rechte auf den Drucker und kann unter Windows darauf auch normal drucken. Im Web wurde ein ähnliches Phänomen beschrieben, wenn man bestimmte Druckertreiber einsetzt - dann sollte es helfen, die Freigabe mit NET USE auf einen LPT-Port umzubiegen und den Windows-Treiber auf den LPT drucken zu lassen. Das hilft aber nicht, denn wenn ich mit NET USE LPT1 \\SERVER\DRUCKER und dann DIR > LPT1 mache, erhalte ich wieder kurz und knapp: "Zugriff verweigert". Auch das testweise Abschalten der Benutzerkontensteuerung auf dem Client half nichts.
Interessant ist noch, dass dieses Problem NUR auftritt, wenn sowohl Windows 2008 Server als auch Windows 7 [bzw. Vista] beteiligt sind. Windows-7-Client am Windows-2003-Server: druckt! Windows-XP-Client an 2008-Server: druckt! WinXP an 2003 sowieso. Nach meinem Verständnis muss es daher etwas mit neuen Funktionen Win7/2008 zu tun haben, die dann nicht zum Tragen kommen, wenn eine Seite noch "älter" ist.
Interessant ferner: Sobald der Benutzer Mitglied der Domänen-Admins wird, klappt der Druck ebenfalls. Also ja wohl doch in irgendeiner Form ein Rechteproblem. Aber wo nur?
Hat da jemand eine Idee? Derzeit behelfen wir uns mit dem XP-Mode, aber das ist schon ziemlich mit Kanonen auf Spatzen geschossen, da das Programm an sich auch unter Win7 gut läuft.
Besten Gruß
Gunnar
ich kämpfe bei einigen Kunden mit einem seltsamen Phänomen. Gegeben ist ein Windows-2008-Server (R2) und ein Client mit Windows 7 Professional (32 bit) [Nachtrag: Oder Vista]. Beide aktuell gepatcht, es läuft alles im Grunde ganz gut, incl. dem Zugriff auf die freigegebenen Drucker unter Windows. Nun setzen die Kunden aber eine DOS-basierte Warenwirtschaft ein. Diese setzt Druckaufträge ab, indem einfach auf den UNC-Pfad eine Ausgabe generiert wird. Also im Grunde das gleiche, als wenn man in der Kommandozeile z.B. DIR > \\SERVER\DRUCKER eingibt. Und eben dies funktioniert in der obigen Konstellation nicht, weder das eine noch das andere. Auf ein DIR > \\SERVER\DRUCKER erhalte ich lapidare Meldung "Zugriff verweigert". Keine Einträge im Ereignisprotokoll.
Natürlich habe ich schon ein wenig geforscht. Der Benutzer hat Rechte auf den Drucker und kann unter Windows darauf auch normal drucken. Im Web wurde ein ähnliches Phänomen beschrieben, wenn man bestimmte Druckertreiber einsetzt - dann sollte es helfen, die Freigabe mit NET USE auf einen LPT-Port umzubiegen und den Windows-Treiber auf den LPT drucken zu lassen. Das hilft aber nicht, denn wenn ich mit NET USE LPT1 \\SERVER\DRUCKER und dann DIR > LPT1 mache, erhalte ich wieder kurz und knapp: "Zugriff verweigert". Auch das testweise Abschalten der Benutzerkontensteuerung auf dem Client half nichts.
Interessant ist noch, dass dieses Problem NUR auftritt, wenn sowohl Windows 2008 Server als auch Windows 7 [bzw. Vista] beteiligt sind. Windows-7-Client am Windows-2003-Server: druckt! Windows-XP-Client an 2008-Server: druckt! WinXP an 2003 sowieso. Nach meinem Verständnis muss es daher etwas mit neuen Funktionen Win7/2008 zu tun haben, die dann nicht zum Tragen kommen, wenn eine Seite noch "älter" ist.
Interessant ferner: Sobald der Benutzer Mitglied der Domänen-Admins wird, klappt der Druck ebenfalls. Also ja wohl doch in irgendeiner Form ein Rechteproblem. Aber wo nur?
Hat da jemand eine Idee? Derzeit behelfen wir uns mit dem XP-Mode, aber das ist schon ziemlich mit Kanonen auf Spatzen geschossen, da das Programm an sich auch unter Win7 gut läuft.
Besten Gruß
Gunnar
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 135469
Url: https://administrator.de/contentid/135469
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
8 Kommentare
Neuester Kommentar
Hallo Gunnar!
Probiers mal damit:
<Start><Programme><Zubehör><Rechte Maustaste><Eingabeaufforderung Als Administrator ausführen>
Eingabe auf der Konsole: net user Administrator /active
Zum Deaktivieren: net user Administrator /active:no
Gruß Dieter
Probiers mal damit:
<Start><Programme><Zubehör><Rechte Maustaste><Eingabeaufforderung Als Administrator ausführen>
Eingabe auf der Konsole: net user Administrator /active
Zum Deaktivieren: net user Administrator /active:no
Gruß Dieter
Hallo!
Hat leider auch nicht geholfen. Meldung nach wie vor: "Zugriff verweigert".
Hat leider auch nicht geholfen. Meldung nach wie vor: "Zugriff verweigert".
Hallo zusammen,
wir haben dieses Problem ebenfalls und zwar im speziellen zwischen Windows 7 Prof und Windows SBS 2008 Premium. Nach einigem testen habe ich festgestellt, dass der Benutzer nicht unbedingt Domänen-Admin sein muss. Druck-Operator reicht offenbar auch aus. Dies ist bei dem momentanen Kunden kein Problem da alle 5 Mitarbeiter eh das Admin Kennwort kennen, aber beim nächsten Kunden könnte das schwierig zu erklären sein..
Hast da jemand schon etwas neues herausfinden können?
wir haben dieses Problem ebenfalls und zwar im speziellen zwischen Windows 7 Prof und Windows SBS 2008 Premium. Nach einigem testen habe ich festgestellt, dass der Benutzer nicht unbedingt Domänen-Admin sein muss. Druck-Operator reicht offenbar auch aus. Dies ist bei dem momentanen Kunden kein Problem da alle 5 Mitarbeiter eh das Admin Kennwort kennen, aber beim nächsten Kunden könnte das schwierig zu erklären sein..
Hast da jemand schon etwas neues herausfinden können?
Hallo Gunnar,
als ich Deine Frage las, dachte ich Du beschreibst unser Problem. Dieses haben wir jedoch nach langem Suchen in den Griff bekommen.
Hoffe es ist noch nicht zu spät.
Ab XP gibt es das Problem, das mit normalen Benutzerrechten die LPT-Umleitung mit dem "net use"-Befehl nicht mehr funktioniert. Wir haben unseren clients lokal immer Adminrechte vergeben und das hat daher nie zu Problemen geführt. Ab Win7 kommt es wg. UAC zu Deinem/unserem Problem. Also....
Auf dem Client den LPT1 deaktivieren.
Gruß Achim
als ich Deine Frage las, dachte ich Du beschreibst unser Problem. Dieses haben wir jedoch nach langem Suchen in den Griff bekommen.
Hoffe es ist noch nicht zu spät.
Ab XP gibt es das Problem, das mit normalen Benutzerrechten die LPT-Umleitung mit dem "net use"-Befehl nicht mehr funktioniert. Wir haben unseren clients lokal immer Adminrechte vergeben und das hat daher nie zu Problemen geführt. Ab Win7 kommt es wg. UAC zu Deinem/unserem Problem. Also....
Auf dem Client den LPT1 deaktivieren.
Gruß Achim
Das Problem hat sich letztlich als eines mit SMB-Versionen herausgestellt. Aktiviert man auch in Win7 wieder das alte SMB-Protokoll (wie es automatisch geschieht, wenn einer der Beteiligten "alt" ist, also 2003 Server oder WinXP), dann druckt's wunderbar.
Am Client dazu ausführen:
sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled
Am Client dazu ausführen:
sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled
Ist zwar schon eine Weile her, aber Du bist mein Held!!
danke ! danke ! du hast mir viel leid erspart!! 
Vielen, Dank!
solche Infos sind auch noch nach Jahren unbezahlbar. In naher Zukunft hat sich das 2003 Server - Problem ja überholt, aber solange sollten sie allen leidgeprüften Administratoren zur Verfügung stehen.
Grüße
Klaus
solche Infos sind auch noch nach Jahren unbezahlbar. In naher Zukunft hat sich das 2003 Server - Problem ja überholt, aber solange sollten sie allen leidgeprüften Administratoren zur Verfügung stehen.
Grüße
Klaus
