s.bozek

Hmmm, niemandem das Problem bekannt? Könnte es an dem TFT Bildschirm liegen?

Naja in diesem Fall ist ja der Client PC gleichzeitig auch der printserver sozusagen und die VPN-Verbindung kann nur vom client zum VPN-Server/Router erfolgen.

Niemand eine Idee???

Hallo, ich möchte einen HP Deskjet-Drucker (Kein Windows XP Standardtreiber) über eine Remotedesktop-Verbindung nutzen. Connectet wird von einem Windows XP Platz auf einen anderen XP PC. Zuvor wird eine VPN-Verbindung von dem Rechner mit dem Drucker auf einen Router im Firmennetz X hergestellt (ich kann mich also nicht an der Domäne anmelden). Wenn ich versuche den Drucker über die vom Router vergebene IP anzusteuern, wird der Netzwerkpfad nicht gefunden (anpingen geht). Auch bei Verwendung eines Druckers, der die Windows Stadardtreiber verwendet, wird dieser sofort in der Remote-Sitzung angezeigt. Warum findet er den Drucker auf der gegenseite nicht??? :mad: PS. die IP des clients, die er beim connecten auf den Router bekommt bleibt immer gleich, die IP des PCs im Firmennetz natürlich auch.

Also die Clients befanden sich vor der Installation des W2k3 Servers in einer Win2k Server Domäne und konnten sich anmelden. Ohne das Anmelden an die Domäne ist der Zugriff auf Netzwerklaufwerke auch im Moment möglich.

achso, dachte wegen der Beschreibung, dass das so ist :) Allerdings müsste er sich doch anmelden können sobald ich das smb-signing auf dem server deaktiviere oder? scheint aber nicht der fall zu sein :( unmöglich sich an die domäne anzumelden.

Sagtmal greift die Richtlinie, die man beim W2k3 Server einstellt bei den Windows 98 Clients dann sofort, wenn das SMB-Signing angebpasst wurde? (Wie im Artikel auf Gruppenrichlinien . de)

Hmm... ich meine das es irgendwas damit zu tun haben muss, dass keine Daten gesendet werden, wenn der client zu lange idle ist. lässt sich das beim TS irgendwie ausstellen? Ich kann ja auch nen supertollen ping ständig nebenher senden, damit das nicht passiert .... :D

Die Software wurde bereits auf WTS Servern getestet und läuft. Sicher wirst du einsehen, dass der Kunde mit Sicherheit nicht bereit ist für Zigtausende eine neue Software entwickeln zu lassen oder? Denn dann wäre es logischer die Thinclient durch "normale" PCs zu ersetzen. Das geschehene lässt sich nunmal nicht rückgängig machen.

Hmm ich weiß schon was du willst. Das Problem ist, dass nur die Exe-Dateien in Anhängen gelöscht bzw verschoben werden. Außerdem bleibt dann ja immer noch der Weg das man die EXE packen kann. Das ausstellen des parsen von HTML verhindert dann auch, dass EXE dateien von "Entfernten" Standorten ausgeführt werden. Und wie schon gesagt, mit einer gut konfigurierten Firewall/Virenscanner lässt sich das ebenfalls lösen, denn dann wird alles gefiltert/geblockt.

Hehe ja richtig :) Bei FlashFXP zB lässt sich der PC nach der übertragung runterfahren. Allerdings könntest auch einen shutdown-Befehl via Batch nach dem übertragen ausführen. Findest darüber sicher ne Menge im Board.

Schon klar :suspect: aber lässt sich numal nicht vermeiden, dass da laufen zu lassen. Außerdem wüsste ich im Moment keinen Grund warum das nicht laufen sollte, wo es doch schonmal bedienbar ist. Übrigens scheint das olle Ding nach gewisser Zeit wiederzukommen d.h. das man es dann auch wieder bedienen kann. :eek: Naja muss mir das ganze noch selbst anschauen, es lässt sich halt schlecht simulieren...

Bei Windows 2003 solltest die Benutzer in die Freigabe + die Sicherheit nehmen damit es funktioniert.

Wenn du zB 2 Std. nach Start des Backups die Daten via FTP überträgst kann man wohl davon ausgehen, dass das Backup fertig ist, lass es 3 Std. sein... :suspect:

Hi, ich glaub da solltest einfach HTML ausstellen und im Filter EXE Dateien verbieten, dann kann auch nichts ausgeführt, da die Dateien normalerweise mit iframes oder kleinen scripts ausgeführt werden, die nur in Zusammenhang mit HTML funktionieren. Also entweder HTML aus oder Antiviren-Programm seines Vertrauens benutzen, dass die Viren entdecken sollte (evtl Heuristik anschalten). :D

Hi, habe mal wieder ein kleines Problemchen :D Und zwar melden sich einige Benutzer über einen Client am Terminalserver an und führen ein DOS-Program aus, welches auf dem PDC läuft aus (Das Laufwerk wird vorher gemapped). Diese Anwendung scheint im etwa 2 Std Takt einzufrieren, jedoch nur auf den Terminalserver Clients. Das Problem dabei ist, dass eine Datei aufm dem PDC geöffnet bleibt und somit gesperrt ist, bis man die Sitzung manuell beim PDC aus dem Dateizugriff entfernt. Woran kann das liegen? Könnte es an irgend einer Idle-Funktion liegen oder wird die Sitzung standartmäßig zwischendurch unterbrochen, da der WTS Server denkt, dass die Sitzung nichtmehr gebraucht wird (Die Clients laufen die ganze Woche), wenn nur selten etwas im Programm eingegeben wird. gruß Simp

Au ja danke, hatte die Regeln garnicht für den TS angewendet, sondern nur für die user die sich nicht am TS anmelden.

Hallo, mein Problem ist folgendes: Habe für einen Anzahl von Benutzern eine Policy erstellt, die jegliche Änderungen am Desktop etc verhindern soll. Die Benutzer befinden sich in einer Gruppe, nennen wir sie Firmenuser. Alle Benutzer befinden sich samt der globalen Gruppe Firmenuser in einer eigenen OU. Nun hat die Gruppe Firmenuser das Recht bekommen die Policy X zu übernehmen, nur wenn ich mich dann mit einem der User anmelde übernimmt dieser nur die Default Policy. Aber warum??? Weiß jmd Rat? (Benutzer melden sich an einem Terminal-Server an, der Mitgliedsserver ist - Liegt es daran?) Gruß Simon

Ah, ich habs schon. hatte vergessen die von mir angelegte ts gruppe im Ad zur lokalen gruppe der remotedesktopbenutzer auf dem ts hinzuzufügen.

Ah Danke Klausk, werde ich mal so machen :)

Hi, ich bins mal wieder. Habe in folgendem Scenario ein Problem: Windows 2003 PDC mit Lizenzserver und Windows 2003 Terminalserver der nur Mitgliedsserver ist. Habe dem Administrator in den Terminaldiensten das recht gegeben sich über die Terminaldienste anzumelden. KLappt auch wunderbar. Nur wenn ich jetzt einen X-Beliebigen User aus dem Active Directory nehme klappt es nicht und er gibt den fehler das ich mich nicht interaktiv anmelden darf. Habe die gruppe in der sich der benutzer befinden sogar direkt in der Terminaldienstekonfiguration angebeben. Habe ich was falsch gemacht?

Da wird das Problem liegen, die Benutzer befinden sich nicht auf dem Terminalserver sondern im AD in eigenen OUs.... der Terminalserver ist Mitgliedsserver. Sollte ich da etwas ändern? :shock:

Hi, sagtmal ist es möglich 2 userkonfigurationen über die Gruppenrichtlinien für den selben benutzer zu regelen die sich zum einen lokal an einen client mit dem server verbinden zum anderen über einen Thin Client an den Terminalserver anmelden, der Mitgliedsserver der Domäne ist. Dabei ist es mir wichtig zum Beispiel bei dem einen die Desktopeigenschaften zu sperren bei dem anderen nicht. Denke nicht wirklich das man da unterscheiden kann aber wer weiß :) Hätte mir es dann irgendwie so vorgestellt für den TS eine eigene OU anzulegen mit verschiedenen Untergruppen mit den Usern mit verschiedenen Rechten. Super wäre es ja wenn man der einen OU zB sagen könnte, dass sie aktiv werden soll wenn sich der normale client anmeldet und ..... ach schwafel :D

Leider besteht das Problem immer noch, gibt es eine möglichkeit das ganze irgendwie zurückzusetzen? An der default policy wurde ja eh nichts geändert, man kann sie ja nur nichtmehr bearbeiten :D

Danke für die schnelle Antwort, ich werde mal fix nachschauen.