Alle Aktivitäten

Wie soll denn der Client Udp mit dem Server sprechen, wenn der gar nicht auf dem Protokoll/Port antwortet? Auf dem Server bewirkt der Befehl nur, dass seine rdp Client Verbindungen kein Udp nutzen. So wie die Clients eben auch. Also ist er auf dem Server ziemlich sinnlos.

Ja, das hatte ich gemacht aber es hat nicht funktioniert. Erst als ich es auch am Client deaktiviert hatte funktionierte es. Also auf dem RDPServer und auf dem Client den Befehl abgesetzt und es hat funktioniert. reg add "HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP /d 1 /t REG_DWORD

Moin, Ja, ich wusste auch, dass Martin sich nicht zurückhalten kann. Und dass wir ihn (bzw. alle anderen Lesenden dieses Threads) dann darauf hinweisen müssen, dass seine AD-Umgebung mit weitem Abstand ein Ausreißer ist. Martin weiß so gut wie wir, dass jemand, dessen Umgebung so groß ist, die hier diskutierten Fragen gar nicht stellen würde, weil er über Personal und Prozesse verfügt, die das unnötig machen. Anderen hier ist das möglicherweise nicht bewusst, daher weisen wir gern erneut darauf hin. Und natürlich weiß Martin auch, dass ein DC mit 16 GB auch in so einer großen Umgebung nicht derart langsam sein würde wie beschrieben, sodass der Kern meiner Aussage eben doch zutrifft. Auch hier sei das aber für alle anderen noch mal erwähnt. Gruß, Nils

Warum willst du das denn clientseitig deaktivieren? Mach’s doch einfach am Server aus.

GPO erstellt "UDP bei RDP deaktivieren" Zu “Computer Configuration > Administration Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client” navigieren. Die Option "Turn Off UDP On Client" aktivieren. Und dann noch unter Administrative Vorlagen Remotedesktopdienste RDP Host Verbindungen Transportprotokoll auswählen und aktivieren und auf "Nur TCP verwenden" stellen. Eventuell per Befehl per CMD mit Adminrechnten auf jedem Server & PC absetzen der nicht aktuelle an der Domain / Firma verbunden ist. reg add "HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP /d 1 /t REG_DWORD

Ich habe auf diesen Kommentar gewartet @daabm

Ehm... https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services Unsere größte Domäne hat knapp 200.000 User -> direkt mal 16 GB RAM als unteres Limit.

Danke dir.... Dann werde ich das morgen einmal bei 3 Benutzern testen....

Peter, Peter… das hat nichts mit dem VPN Tunnel zu tun…

Kann mir einer hierzu noch etwas sagen? Gibt das nicht auch Probleme mit dem SSL-VPN-Tunnel der über den UDP Port 1194 läuft? Oder hat das damit nichts zutun?

Im hcu wär auch nicht soviel besser ;)

Ok 😆

Ja

Danke dir mir das einmal anschauen. Bevor ich das aktiviere. Kannst du mir noch dabei helfen? Gibt das nicht auch Probleme mit dem SSL-VPN-Tunnel der über den UDP Port 1194 läuft? Oder hat das damit nichts zutun? Danke dir. Ja

Die User dürfen also in HKLM in den Policies Zweig schreiben? Wenn du es pro Client verwalten willst: GPS: Turn Off UDP On Client (gpsearch.azurewebsites.net) Wenn du es an den RDSHs zentral verwalten willst: GPS: Select RDP transport protocols (gpsearch.azurewebsites.net)

Doch, kann ich. Aber bis dahin, nutzt man einfach Schattendomänen und Kontakte.

#### Viele Homeoffice Benutzer sind aber per SSL-VPN-Tunnel mittels UDP-Port verbunden. Ist das dann nicht kontraproduktiv?

👍 naja wenn „neue maildomain = sofort = bereits in Nutzung“, dann kannst du so schnell gar nicht migrieren, dass du den workaround nicht zumindest einführen müsstest.

Danke für deinen Input. Ich werde das testen. Danke habe ich gemacht. Musste es aber auf dem Client und dem RDP-Server machen. Nur auf dem RDP-Server hat nicht funktioniert. Wir kann ich ich denn jetzt am besten auf allen PCs diesen Befehl absetzen? Per Loginscript? Ja, aber dann müsste ich bei jedem Benutzer das Benutzerprofil anpassen und dann dort den Befehl mit geben. Oder per GPO. Wie kann ich das per GPO machen? Was ist die bessere Variante? Oder gibt es noch eine bessere?

deswegen schrieb ich ja "schnell" - im Sinne von, so schnell, dass man sich mit kruden Workarounds gar nicht erst aufhalten muss

Ich dachte, das wäre sowieso das Ziel. Deswegen schrieb ich ja von „während der Migration“. Je kürzer der Migrationszeitraum, umso besser.

Moin, ich werfe mal ein anderes Konzept ins Rennen: Ihr migriert die zwei Umgebungen schnell zu euch rüber und betreibt nur eine Exchange-Organisation. Die anderen Sites können gern wieder einen lokalen Exchange kriegen, falls die WAN-Performance ein Problem ist. Die AD-Forests der neuen Häuser können ja bis zur endgültigen Migration da bleiben, ihr betreibt euren Exchange also für die anderen beiden Häuser als Ressourcen-Forest. Mit dem im OP skizzierten Konzept werdet ihr des Lebens nicht froh. Und auch mit dem Gateway ist es so eine Sache - die wenigsten von ihnen können den Recipient Type sauber auswerten. Spätestens wenn das Thema MailUser auf den Tisch kommt, wird es wieder spannend.

Sind das physische Maschinen oder VM‘s? Wie viele Kerne sind zugewiesen (wenn VM) - einer ist d..f Bin bei Nils, 16G braucht ein DC nicht, und wenn der ständig bei 30% Last ist stimmt was anderes nicht Was für ein AV ist installiert, die Ausnahmen korrekt gesetzt? und danke an Martin, mache Dinge vergisst man im Laufe der Zeit

Moin, Ein DC braucht weder viel RAM noch viel CPU. Wenn das also was lahm ist, dann ist das ein deutliches Zeichen, dass irgendwas aus dem Lot ist. Gruß, Nils

Hi, ich blicke nicht 100 % durch. Kann dir aber erstmal nur dazu raten, dass Gateway davor zu betreiben und von dort direkt an den jeweils richtigen Exchange zustellen zu lassen. Gruß Jan