druckerheini

Virenscanner ist Avira Free 2012, allerdings nur on-demand. Den habe ich jedoch nicht im Verdacht, da ich denselben Scanner auch auf einem anderen PC laufen habe (sogar on-access) und dort das Problem nicht auftritt. Auch im Avira-Forum habe ich nichts Entsprechendes gefunden, was sicherlich der Fall gewesen wäre, wenn Avira da ein Problem hätte. Daher mein Verdacht auf irgendwelche Programme, die sich in den Explorer reinhängen und das Verzeichnis offenhalten. Ist es denn möglich, z.B. herauszufinden, welcher Bestandteil des Explorers (evtl. eine DLL) das Verzeichnis offenhält? Das wäre ggfs. ein erster Anhaltspunkt - doch wie kriegt man das raus?

Hallo, an einem PC habe ich das Phänomen, dass sich nach einiger Herumklickerei in einer Verzeichnisstruktur im Explorer ein leeres Verzeichnis nicht mehr löschen lässt, auch nicht von der Kommandozeile. Dies tritt insbesondere nach Verschiebeoperationen im Explorer auf (Windows XP SP3, voll gepatcht). Ich habe es noch nicht geschafft, das Phänomen durch eine Folge von Schritten zuverlässig zu reproduzieren, doch es tritt immer irgendwann auf, wenn ich heftig im Explorer herumhantiere. Sysinternals Process Explorer zeigt mir, dass in diesen Fällen das betreffende Verzeichnis von explorer.exe in Beschlag genommen ist (auch bei geschlossenem Explorer-Fenster, wenn nur noch die explorer.exe des Desktops läuft) und tatsächlich kann ich das Verzeichnis löschen, wenn ich mich neu anmelde oder explorer.exe per Taskmanager abschieße. Mein Verdacht liegt bei einer Shell Extension (einige Anwendungen hängen sich ja in das Kontextmenü des Explorers rein), und das würde ich gerne mal genauer untersuchen, da das Phänomen doch recht lästig ist, ich andererseits den ansonsten sehr gut funktionierenden PC nicht mit allen Anwendungen neu installieren möchte. Hat jemand eine Idee, wie man den Fehler einkreisen kann? Danke.

:D Das geht derzeit leider nicht... gibt es noch andere Lösungsansätze, entweder diesen Registry-Key zu setzen oder auch auf eine ganz andere Art und Weise die Laufwerke unsichtbar zu machen?

Danke für die Hinweise. Das Problem ist, dass ich anhand der Benutzernamen nicht sagen kann, welcher Benutzer eben diese Anwendung nutzt, da der Windows-Benutzer bei anonymen Citrix-Anwendungen dynamisch aus einem Pool von Benutzern (Anon000, Anon001, ...) ausgewählt wird - der nächste, der frei ist, wird genommen. (Der Server bedient auch andere Anwendungen, für die diese Einstellungen nicht gelten sollen, die Benutzer, die diese Anwendungen aufrufen, bedienen sich aus dem selben Pool lokaler Windows-Benutzer!) Die Anwendung, um die es hier geht, wird über eine .cmd gestartet. In dieser setze ich schon einige andere Einstellungen (u.a. diverse andere HKCU-Registry-Keys), die damit nur für die Benutzer dieser Anwendung gelten, und das funktioniert auch prima, nur eben nicht für diejenigen Einstellungen, die nach HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies geschrieben werden müssen. (Schreibe ich den Key "NoDrives" nach HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer, was auch in dem von Dir erwähnten Artikel erwähnt wird, werden die Laufwerke leider nicht ausgeblendet.) Noch Ideen?

Hallo, für eine Anwendung sollen fast alle Laufwerksbuchstaben auf einem Windows 2003-Terminalserver versteckt werden, so dass sie im Explorer und in Anwendungen bei "Datei speichern" usw. nicht erscheinen. Am liebsten wäre mir eine Lösung über einen Registry-Key, den ich per reg add im Startscript der Anwendung setzen kann (siehe z.B. hier). Leider hat der Benutzer keine Berechtigung in den Key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer zu schreiben. Hat jemand eine Idee, wie man dies dennoch umsetzen kann? Der Server ist nicht Teil Domäne, zudem handelt es sich um anonyme Citrix-Benutzer, deren Profile nach Beendigung der Anwendung immer wieder verschwinden. Danke.

Hallo, im Windows-Explorer kann man ja (z.B. per Rechtsklick auf die Titelzeile) zusätzliche Spalten hinzufügen. An manchen PCs funktioniert dies, bei anderen ist die Liste der Spalten jedoch sehr kurz und reicht nur von "Name" bis "Besitzer", die weiteren Spalten (Autor, Titel, Kommentare usw.) werden gar nicht erst zur Auswahl angezeigt. Es scheint vom PC und nicht vom Benutzer abzuhängen, jedenfalls werden die Spalten auch bei neu angelegten Benutzern nicht angezeigt. (Die PCs befinden sich nicht in einer Domäne.) Hat jemand eine Idee, woran das liegen könnte? Danke.

Denke nicht, dass das mit Windows-Bordmitteln geht, aber versuche mal AutoIt, dort gibt es eine Funktion "WinMove", mit der sollte es lösbar sein.

Das habe ich schon verstanden, es gibt mir jedoch nicht genau die Information, die ich brauche (ich sehe daran ja nur, welcher Benutzer wo druckt, was zwar nützlich ist, jedoch nicht das, wonach ich gesucht habe, da wir zum einen Drucker haben, auf denen selten gedruckt wird und zum anderen Benutzer, die sich tagelang nicht abmelden). Danke jedenfalls für die Informationen.

Offensichtlich hatte ich das. Jetzt nicht mehr :) Ok, dann geht es natürlich nicht. Ich bin davon ausgegangen, dass eine ständige Verbindung besteht. Dann jedoch sollten auch Versuche mit dem erwähnten tcpview nicht wirklich weiterhelfen, richtig?

Hatte ich oben definiert: Zum Zeitpunkt der Abfrage verbundene Clients. Die Historie interessiert mich hier nicht, und genausowenig, ob jemand aktuell auf dem Drucker druckt. Es geht mir einzig und allein darum, herauszufinden, welche Drucker aktuell von (mindestens) einem Client verbunden sind. Kann man auch einstellen, dass dort protokolliert wird, wenn sich ein Client mit einem Drucker verbindet bzw. wenn diese Verbindung wieder getrennt wird? Dann würde mir das reichen. Derzeit werden dort jedoch nur die einzelnen Druckjobs eingetragen, was für meinen Zweck zuwenig ist, da es ja auch Drucker geben kann, die zwar verbunden sind, auf denen jedoch nur selten gedruckt wird. Und die möchte ich nicht einfach vom alten Printserver löschen, da sie dann ja auf den Clients ebenfalls verschwinden.

Er müsste doch mindestens mitbekommen, wenn sich ein Client mit einer Freigabe verbindet, oder nicht? Ich möchte ja nicht die "Karteileichen" (= die Drucker, die NIE genutzt werden, weil sie z.B. längst abgebaut wurden) umziehen, sondern diejenigen Drucker, die eben nur momentan nicht genutzt werden (z.B. weil die Benutzer im Urlaub sind, später kommen, früher gehen o.ä.). Und wenn wieder ein Benutzer den Drucker verbindet, bekommt er ihn anschließend vom neuen Printserver.

Hat der Printserver selbst keinen Überblick, welche seiner Druckerfreigaben von wem genutzt werden? Einige Drucker sollen auf einen anderen Printserver umziehen (die Verbindung passiert per Script beim Anmelden, die Benutzer bekommen daher von dem Umzug nichts mit), und da möchte ich zunächst nur diejenigen Drucker umziehen, die momentan von niemandem verbunden sind. Zudem würde ich bei dieser Gelegenheit gerne Karteileichen löschen.

"Genutzt" soll hier heißen: "Ein Client hat sich mit diesem Drucker verbunden (z.B. über "Drucker hinzufügen"), so dass der Drucker in Anwendungen zur Verfügung steht". Ob gerade tatsächlich auf den Drucker gedruckt wird, ist irrelevant, wichtig ist die Information, dass die Freigabe genutzt wird. In der Systemsteuerung des Printservers sehe ich unter Computerverwaltung - Freigegebene Ordner - Sitzungen offenbar die IP-Adressen der Clients, doch leider nicht die Namen der Drucker...

Hallo, kennt jemand eine Möglichkeit, an einem Printserver mit freigegebenen Druckern eine Liste all derjenigen Drucker zu erzeugen, deren Freigabe im Moment von einem Client-PC genutzt wird (idealerweise mit den zugehörigen Clientnamen)? Danke. :)

Schon klar, aber wenn man die weitergehenden Funktionen nicht nutzt und nur per LPR druckt, sollte eigentlich der "LPR Port" ausreichen. So dachte ich jedenfalls bisher, doch gibt es einzelne Drucker, die mit dem "LPR Port" nicht funktionieren, sondern nur mit dem "Standard TCP/IP-Port" (im LPR-Modus). Also muss es irgendwo einen Unterschied geben... Wenn ich sicher wüsste, dass der "Standard TCP/IP-Port" in allen Belangen dem "LPR Port" überlegen wäre, hätte ich kein Problem damit, zukünftig nur ersteren zu verwenden, ich möchte mir eben nur keine Nachteile einhandeln, die mir bisher nicht bekannt sind.

Das Microsoft-Tool printmig.exe bietet immerhin an, Drucker von "LPR Port" auf "Standard TCP/IP Port" zu migrieren, das deutet doch darauf hin, dass "Standard TCP/IP Port" irgendwelche Vorteile hat, auch wenn man nur LPR verwendet...

Gibt es hierfür eine technische Erklärung (z.B. eine generelle Schwäche des LPR-Protokolls)? Hat sich der Druck über Port 9100 mittlerweile flächendeckend bei Netzwerkdruckern durchgesetzt? LPD kann ja immerhin so gut wie jeder Netzwerkdrucker...

Hallo! Wenn man einen Drucker von Windows aus per LPR ansprechen möchte, kann man dies ja über zwei Anschlussarten tun: "LPR Port" und "Standard TCP/IP Port". Ersterer kann ja nur LPR, letzterer auch Raw und bietet darüberhinaus noch die Einstellung "LPR-Bytezählung aktiviert". Was ist der Unterschied zwischen beiden Anschlussarten, wenn es um das Drucken per LPR geht? Meistens funktionieren beide gleichermaßen, doch hatte ich schon Fälle, in denen nur "Standard TCP/IP Port" (mal mit, mal ohne "LPR-Bytezählung aktiviert") zuverlässig funktionierte, während über "LPR Port" nicht korrekt gedruckt wurde. Ist es generell empfehlenswert, nur noch "Standard TCP/IP Port" zu verwenden (ist also "LPR-Port" obsolet), oder gibt es Situationen, in denen "LPR-Port" tatsächlich besser ist? (Konkret geht es um einen Windows 2003-Printserver.) Danke.

Klar, es ist Gebastel, und zuerst dachte ich ja auch, es würde über Sicherheitsrichtlinien o.ä. auf "normalem" Wege gehen, aber das war wohl ein Irrtum. Jetzt funktioniert die Steel Runas-Lösung, allerdings eben mit dem Nachteil, dass immer noch Druckertreiber installiert werden können. Vielleicht kann ich ja dem Admin-Benutzer, unter dem das Script ausgeführt wird, Schreibrechte auf %SYSTEMROOT%\system32\spool\drivers entziehen (oder ähnliches) - auch nicht richtig schön. Die Alternative zu all dem wäre eben, der Serviceabteilung gleich Admin-Rechte auf dem Server zu geben, und das wollen wir nicht.

Die Serviceabteilung soll Drucker anlegen bzw. ändern können, ohne sich jedoch selbst als Admin auf dem Druckserver anzumelden. Das kriege ich mit einem Script hin, das mittels Steel Runas diverse rundll32.exe-Befehle als Administrator aufruft. Muss ich noch genauer testen, funktioniert bisher jedoch gut. Nur möchte ich nicht, dass dabei neue Druckertreiber installiert werden, sondern nur aus den schon vorhandenen ausgewählt werden kann. (Die Installation neuer Druckertreiber möchte ich mir selbst vorbehalten, ggfs. vorher einem Test unterziehen oder auch den einen oder anderen ablehnen.) Das befürchte ich auch, dennoch habe ich die Hoffnung, dass es einen Trick gibt...

Hallo! Kennt jemand eine Möglichkeit, einem Hauptbenutzer die Berechtigung zu verwehren, neue Druckertreiber zu installieren? Es sollen neue Drucker installiert, neue (LPR-, also "lokale") Anschlüsse angelegt, Drucker freigegeben, Druckereigenschaften geändert, und aus den schon installierten Treibern einer ausgewählt werden dürfen, es sollte eben nur keine neuen Treiber installiert werden, die die Stabilität des Druckservers beeinträchtigen könnten. Hat jemand eine Idee? Danke. :)

Ich meine das Anlegen neuer Drucker und Anschlüssen, nicht jedoch neuer Druckertreiber! Es soll möglich sein, über "Neuer Drucker" eben neue Drucker anzulegen, dabei bei Bedarf neue Anschlüsse einzurichten, und diesen Druckern schon installierte Druckertreiber zuzuweisen. Neue Treiber sollen jedoch nicht installiert werden dürfen (da haben wir eine ziemlich restriktive Politik).

Hallo Robert, Vielleicht bin ich heute mittag auch nur blind, aber ich finde diese Richtlinie nicht. Es gibt eine Richtlinie "Geräte: Anwendern das Installieren von Druckertreibern nicht erlauben", die ist auch aktiviert, denn das sollen wirklich nur die Admins tun. Aber eine Richtlinie, die das Anlegen neuer Drucker steuert, habe ich nicht gefunden... wo ist die? Danke.

Leider auch nicht. Ich habe die Berechtigung testweise auch mal eine Ebene höher (also auf HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print) gesetzt, ebenfalls ohne Erfolg. Kann es sein, dass Nicht-Admins tatsächlich keine neuen lokalen Drucker anlegen können?

Das reicht leider nicht, um neue lokale Drucker anlegen zu dürfen (und LPR-Drucker sind eben lokale Drucker...)