s-dau

Hallo, wie sind hier auch grad am wechseln der Antivirensoftware. wir setzen momentan Avira ein. Wollen wohl, wie es bis jetzt aussieht zu Trendmicro wechseln. mal ne kleine "angestaute" Begrüngsliste, welche aus eigenen Erfahrungen resultiert. Die Erkennungsrate bei Avira ist zwar gut und wohl die mit beste, aber mit dem entfernen haperts. Viele false-Positive, die, sogar nachdem sie Avira rausgenommen hat, nach einiger Zeit und etliche Updates später wieder auftauchen. Keine Unterstützung für externe Devices. Avira wird das nach eigenen Aussagen durch den Vertrieb auch nicht so bald bringen. Es treten auch jedes Jahr Probleme beim einspielen des Lizenzkeys auf, da hier mehrere Domänen im Einsatz sind, die alle von einem Antivir-Server aus verwaltet werden. Auftretende Probleme mit Pro Activ, welches sich angeblich abschaltet aber noch an ist. Trotz durchgeführter Fixings bleibt das Problem bestehen. Einige Fixings funktionieren nicht über SMC, sondern belasten meine Turnschuhe. Avira ist an sich nicht schlecht und es wurden auch einige Sachen verbessert und hinzugefügt, aber es fehlt noch einiges. Trendmicro soll eingesetzt werden, um zusatzsachen wie Device-Controll zu realisieren. Erste Tests dahingehend sehen schon sehr gut aus, die Testumgebung, läuft stabil und fehlerfrei. Eine automatische Deinstallation von Avira durch TM ist mir allerdings nicht gelungen. Kann ich aber mit leben. Bei der Installation fliegt kurz das Netz weg, mach ich da ggf. was verkehrt?

So, mal wieder hochholen! Habs immer noch nicht gefunden! Entweder ich bin der einzige der so ein Problem hat, oder es ist so profan, dass man mir deswegen nicht antwortet!

auch ich bevorzuge Fehlersuche, da man ja nicht ausschliessen kann, dass der Fehler nicht wieder auftritt. Ja das mit den HP-Druckern ist ein guter hinweis, hab das allerdings auch schon getestet und jeweils die HP's rausgeschmissen. Fehler trat trotzdem auf. An anderen PS's haben die User jeweils keine Probleme, lässt sich auch relativ schlecht testen, da die Fehler nicht immer und dann auch nur bei einem Rechnerneustart auftreten. also wenn die Verbindung einmal steht, bleibt sie auch bestehen bis zum abschalten des Rechners.

Antworten stehen innerhalb des Zitats

schön das ich helfen konnte, nur hilft mir das eben nicht! Das Neustarten der Druckerwarteschlange hat erwartungsgemäß den gleichen Effekt, wie ein Rechnerneustart! könnte jetzt den Dienst stündlich neu starten via batch, halte das aber für ne bescheidene "Lösung" spiele jetzt mit dem Gedanken den Server neu aufzusetzen. Möchte aber nicht, das sich alle User dann wieder neu verbinden müssen. Sollte allerdings funktionieren, solange DNS und Druckerfreigabename identich der alten Konfiguration sind. allerdings hätt ich eigentlich schon gern gewußt wo der Fehler herkommt. Müsste ja auch ausschliessen, dass das nicht vielleicht ein netzproblem ist, obwohl ich da auch nichts entdecken kann.

beide Ereignislogs geben nichts her. das mit dem Dienst kann ich unabhängig davon trotzdem mal testen, obwohl ich da denke, dass es nicht daran liegt. Herr Page

der druckerspoolerdienst auf dem Server sollte laufen, da sich ja alle anderen Clients verbinden können.

Hallo, hab mal wieder ein Problem mit unserem Printserver, zu dem weis scheinbar selbst Herr Page keine Antwort!? In einer W2k3-Domäne existiert ein W2k3-Printserver. Jeder User darf und soll sich seine Drucker selbst verbinden. Das funktioniert auch sehr gut! Nur stellt sich jetzt bei einigen wenigen Clients das Problem, dass beim morgentlichen Rechnerstart die Drucker zwar erscheinen, jedoch im Status "Verbindung wird hergestellt" verharren. Erst ein Neustart des Servers löst die Verklemmung, dann funktioniert auch das herstellen der Verbindung ohne das beispielsweise der Client-PC neu gebootet werden muss. Der P-Server ist ein VMware-virtualisierter W2003 R2, die Clients sind komplett gepatchte WXP-SP3 Kisten. Im Ereignislog find ich nichts brauchbares.

Lieber Herr Betken, Ich habe im Vorfeld nicht an den Richtlinien rumgeschraubt. Der Printserver und das Verbinden funktionierte einwandfrei! Die im Thread angegebenen Änderungen sind die, die gemacht wurden. Es hat also ohne das Deaktivieren der Richtlinie funktioniert und sollte, wenn man sich die Beschreibung der Richtlinie durchliest auch im nicht konfigurierten Zustand funktionieren. und die Rechner befinden sich in der Gesamtstruktur. Das ist der Punkt den ich quasi bemängel! Es gibt noch die eine oder andere GPO, wo ähnliche Effekte auftreten... Gibt es eine halbwegs einfach zu konfigurierende Linux-Lösung für die Bereitstellung eines Printservers in einer Windows-Domäne? Ich kenn keine. Und deshalb nutzte ich eine Bill-Gates-Lösung für den Printserver. Mit dem klaren Vorteil, der mir aus dem richtigen Lesen entsteht, hast du allerdings recht.

So, Angeschaut ist! Und zu funktionieren scheints auch. Ich hab das mit den Richtlinien vorhin beim ersten überfliegen etwas falsch verstanden. so noch bissl testen, aber scheint so, als obs geht!!! Allerdings find ich das ganze mal wieder völlig dämlich...Mikrosoftmäßig danke 4077...

Mit den Unix-Druckdiensten hats nichts zu tun, soviel steht mal fest. Die Domänenrichtlinie schau ich mir jetzt an.

welchen Teil aus dem tread meinst du ? Den mit en Unix-druckdiensten oder den mit den lokalen Richtlinien? Das mit den lokalen Richtlinien halte ich für den falschen weg, da das ja schon seit SP1 existent ist, aber bei mir mit SP2 und SP3 ja schon funktioniert hat. Da muss es eine andere Lösung geben, wenn da das Problem liegen sollte, was ich allerdings nicht glaube. Die Unix-Druckdienste sind hier standardmäßig nicht installiert. Habe testweise an einem rechner diese Dienste hinzugefügt und das Drucker Hinzufügen scheint zu funktionieren, muss ich aber noch genauer checken. Als Problemlösung betrachte ich das ganze dann allerdings nicht, eher als primitiven workarround.

Natürlich habe ich diesen Client komplett neu aufgesetzt!

So, unter XP SP2 hab ich nach wie vor die gleichen Probleme. Also am SP3 scheint es nicht zu liegen. Bleibt imho noch noch die Sache mit dem gelöschten Adminkonto in der Domäne. Wenn dies das Problem darstellt, müßte ich doch irgendwo das Konto ändern können, welches für die Treiberinst verwendet werden soll?

Mit ohne Firewall verhält es sich genauso. was mich wirklich stutzig macht, ist der Umstand, dass ich Drucker als User verknüpfen kann, welche zuvor unter einem Domänenadmin-konto verknüpft wurden. dieses weist auf jeden Fall daraufhin, dass die Treiber unter einem User-Account nicht installiert werden. Aber warum ist ist das so. Bis letzte Woche war dieser Fehler nicht da. Auch bei SP3-Rechnern nicht.