nobex

Evtl. hilft Dir dieser Artikel weiter: How to create a Group Policy object to cause Outlook 2003 to use plain text for e-mail messages (Das ganze dann natürlich etspr. auf Rich Text schalten)

Gibst Du denn einen korrekten Speicherort mit den entspr. INF-Treibern an?

Ein paar Frgaen: In welchem Subnetz steht der DHCP? Wer routet ins Servernetz? Ist ein Relay-Agent im Einsatz? Evtl. hilft Dir ja dieser Artikel schon weiter: PXE Clients do not receive an IP address from a DHCP server across a router

Wie bist Du denn bisher vorgegangen und woran scheitert es?

:suspect: Auf welchem Server wird Port 25 dicht gemacht?

Sprichst Du die Backup-Ordner über UNC-Pfade an?

Evtl. hilft Dir dieser Artikel weiter MSXFAQ.DE - Recovery Storage Group

Keine Warnungen oder Fehler im Jobprotokoll? Wie ist die Konfliktbehebung für den Job konfiguriert (gewesen)?

M.E. ist Dein beschriebenes Vorhaben ohne eine zus. Filterebene nicht möglich. Ich würde für die Gäste ein 2. Netz aufspannen.

Werde leider aus Deiner Problembeschreibung nicht ganz schlau :( Lt. Windows-Hilfe for /L {%% | %}Variable in (Anfang#,Schritt#,Ende#) do Befehl [befehlszeilenoptionen] sieht mir allerdings Deine 'Bereichsdefinition' (125,1,125) nicht ganz schlüssig aus.

Dein Vorhaben sollte problemlos machbar sein.

Steht dazu etwas in der Ereignisanzeige? Stimmen die Zugriffsrechte?

Ein serverseitiger Timeout sollte nicht zuschlagen, da dieser nur bei Inaktivität abläuft. Ich würde noch mal einen anderen Client testen (z.B. den windowseigenen). Dann erneut die Frage zu Ereigneisanzeige der Server ...

Wenn das Mapping nicht neu verbunden wird, sollte doch keine erneute Anmeldung stattfinden ... :suspect:

Sind irgendwelche einschränkenden GPOs aktiv? Ist der Rechner virenfrei?

Ein testweises Stoppen des Programms bringt Aufschluss.

Kannst Du den kompletten Inhalt des/der Events hier reinkopieren? Von wo kommen die Anmeldungen des Admins an den TS?

Genau die Log-Datei meinte ich, dass nix zum Thema drin steht ist allerdings nicht schön ... Die Ereignisanzeige sagt auch nichts? Gehst Du über einen Proxy? Beim SBS sicherlich nicht ... Sind evtl. Kontingente für den FTP-User gesetzt?

Dann muss sich m.E. in den Dokumenten etwas verändert haben wenn am Treiber und/oder in den Druckersettings nicht verstellt wurde. Rede mit'm Cheffe und schick eine Mail an Alle: Aufgrund eines Sicherheitsupdates ... bla blub Danach kannst Du Dich ja noch mal in Ruhe des Problems annehmen.

Die Log-Datei für den FTP-Server ist in der IIS-Verwaltung konfiguriert.

Hat der Benutzer 'radius.ad/Radius Benutzer/xxx' auch ein Zertifikat gezogen bzw. vertraut er der Zert-Stelle?

Kannst Du in den IIS-Logs die Anforderung des Problem-Clients mit den normalen Zugriffen vergleichen?

Um welchen Drucker handelt es sich denn und welche Schacht-Optionen lassen sich im Drucker selbst und im Treiber definieren? Beim Word spielen halt auch die im Dokument gesetzten Werte (bei Dir Auto) bei der Entscheidung für einen Schacht eine Rolle. Den anderen Anwendungen ist dies 'nicht so wichtig'. Ich würde versuchen, so viele Auto-Schachteinstellungen wie möglich (in Word, im Treiber, im Drucker) durch explizite Zuweisungen zu ersetzen.

Kannst Du im Druckdialog auch die Papierart wählen? Evtl. entscheidet sich ja der Drucker für den falschen Schacht.

Was ist denn im Dokument selbst unter Datei -> Seite einrichten -> Papier -> Zufuhr eigestellt?