Bullet

Ok, das ist zwar nicht die Antwort die ich mir erhofft hatte, aber zumindest schon mal eine Aussage. Danke.

Hallo zusammen. Wir haben hier bei uns ein Problem und ich wollte mal fragen ob eventuell jemand von euch eine Lösung dafür wüsste. Wir haben bei uns ein AD (Funktionsebene: Windows Server 2008 R2) mit 7 DC's (alle Windows Server 2008 R2) und einem Exchange 2010 Cluster. Im AD gibt es User für die ein "Unified Messaging Dienst" aktiviert ist. Diese User kann man daran erkennen, dass im "extensionAttribut2" ein Server eingetragen. Da die AD-User und der UMS-Dienst von unterschiedlichen Personen verwaltet werden, kann es vorkommen dass ein AD-User mit aktivierten UMS gelöscht wird, ohne im UMS-Dienst deaktiviert zu werden. Das führt folglich zu Problemen beim UMS-System. Meine Frage ist jetzt, ob die Möglichkeit besteht beim Löschen eines AD-Objekts eine Aktion auszuführen? Am besten wäre es wenn, falls das extensionAttribut2 nicht leer ist, eine E-Mail an die Person verschickt werden könnte die den UMS-Dienst verwaltet. Allerdings würde es auch schon reichen wenn man als Aktion ein PS-Skript oder eine Batch ausführen könnte, dann könnten wir den E-Mail-Versand darüber herbeiführen. Gruß Bullet

Das Problem ist gelöst. Es lag doch an der MTU. Im Netzwerkmonitor konnte man erkennen, dass alle Datenpakete ankommen, nur die die wesentlich größer als die anderen waren nicht. Ich habe die MTU zwar schon im Router runtergestellt, aber die Einstellung scheint nur für den Internetzugang beachtet zu werden. Ich habe jetzt bei dem Terminal Server die MTU kleiner eingestellt und es funktioniert. Trotzdem danke für die Hilfe, bis zum nächsten Problem. Gruß Bullet

Ich fahre heute noch mal zu dem Kunden hin, um der Sache weiter auf den Grund zu gehen. Falls es nicht klappen sollte, werde ich bei der Gelegenheit auch gleich mal ein Protokoll des Netzwerkmonitors speichern und hier posten.

@trenas: Ja, ich hatte weiter oben schon erwähnt, dass die Pakete vom Client auf Port 3389 zwar beim Terminal Server ankommen, aber die Antwort darauf kommt dann beim Client nicht mehr an.

Keiner mehr eine Idee?

So, ich habe folgendes herausgefunden. Der Windows 2003 Server hat schon SP2 drauf. Mit dem Netzwerkmonitor konnte ich erkennen, dass auf Port 3389 von dem TS-Client zwar Pakete eingehen, aber nachdem der Server versucht hat zu antwortendie Meldung kommt: Destination unreachable (<IP-Adresse des TS-Client>) Ich kann den TS-Client aber vom Server aus anpingen. Außerdem habe ich versucht die Firewalls dazwischen soweit wie möglich und vertretbar zu deaktivieren, aber auch das hat noch keine abhilfe geschafft. Das komische ist, dass es zwischenzeitlich mal kurz für eine halbe Stunde funktioniert hat. Deswegen kann weitestgehend ausgeschlossen werden, dass es an den Firewalls liegt. Es muss ja aber trotzdem einen Grund haben, dass der Server den Client nicht erreichen kann. Gruß Bullet

SP Status und Netzwerkmonitor kann ich gerade nicht machen, weil ich nicht bei dem Kunden bin. Da ich aber nachher hin fahre, werde ich das mal testen.

MTU habe ich schon auf 1250 gestellt. Habe ich auch per ping-Befehl ermittelt, daran kann es also nicht liegen. Trotzdem danke für die schnelle Antwort.

Hallo, ich habe folgendes Problem: An Standort A steht ein Windows 2003 Server der als Terminal Server arbeitet. Von Standort B sollen 4 Clients durch einen VPN-Tunnel auf den Terminal Server zugreifen. Der VPN-Tunnel wird über einen LinkSys RV082 (Standort A) und einen LinkSys RV042 (Standort B) aufgebaut. Jetzt mal ein paar Daten: Server (Standort A): - DSL 768 - Windows 2003 Server Standard Edition - Intel XEON Dual-Core - 4 x 400 GB (RAID 10) - Terminal Server (im Lizenzmodus) Clients (Standort B): - DSL 3000 - Windows XP SP2 - Terminal-Client 256 Farben, Vollbild LinkSys RV082 (Standort A): - Schlüsselaustausch durch IKE - Phase 1 Verschlüsselung AES 256 Bit - Phase 1 Hash MD5 - Phase 2 Verschlüsselung AES 256 Bit - Phase 2 Hash MD5 - Keep Alive (an) - Dead Peer Detection (an) - NetBIOS Broadcast (an) LinkSys RV042 (Standort B): - siehe LinkSys RV082 Bevor der RV042 verbaut wurde stand bei Standort B ein LinkSys BEFSX41 v2.1. Bei diesem gab es leider immer wieder Verbindungsabbrüche. Deswegen wurde er gegen den LinkSys RV042 getauscht. Seitdem der RV042 bei Standort B aufgebaut wurde bleibt zwar der Tunnel konstant bestehen, allerdings ist kein Aufbau der Terminalsitzung durch den Tunnel mehr möglich. Ich kann den Windows 2003 Server durch den Tunnel pingen und auch die Freigaben anzeigen lassen, aber nicht mehr die Terminalsitzung aufbauen. Wenn ich dir Terminalsitzung durch das Internet aufbaue, funktioniert es sofort, aber nicht durch den Tunnel. Ich habe schon probiert die Verschlüsselung ganz niedrig zu wählen und auch andere Optionen der Router an bzw. ausgeschaltet. Auch das Neustarten des Terminal Servers brachte nur einen kurzen Erfolg. Nach dem Neustart konnte man sich wieder für ein paar Minuten verbinden, danach nicht mehr. In der Ereignisanzeige des Servers und auch der Clients ist nichts über die Terminal-Dienste protokolliert. Hat jemand eine Idee? Gruß Bullet

Gute Idee, das werde ich mal testen. Ich werde das Ergebnis dann posten. Falls noch jemand eine Idee hat, immer her damit. Gruß Bullet

OK, dann weiß ich bescheid. Vielen Dank Bullet

Ich habe mich natürlich auch mal wieder nicht richtig ausgedückt. Ich meinte, dass sich alle fünf Personen zur gleichen Zeit mit dem gleichen Domänen-Benutzer anmelden. Oder ist auch bei dem gleichen Benutzernamen für jede Instanz davon eine Lizenz nötig? Gruß Bullet

Hallo, ich habe mal zu den Lizenzen eine Frage. Wenn ich auf dem Domänen-Controller einen Benutzer anlege und sich 5 Benutzer gleichzeitig auf dem Terminal Server anmelden, brauche ich dann dafür nur 1 User-Lizenz? Gruß Bullet

Ja, das englische Layout wurde bei der Installation sogar gelöscht.